[Question] Why not JsonDestroyer?

[Speiger]

I find this project quite funny but also cool. First of all this looks like a good project, no hating here, I just have a few questions. You don't have to answer and can just close this if you feel like it.

But I kinda want to ask a few questions.

• 1: Why are you moving JsonFiles to javaFiles? I mean the whole idea of this concept is not to write JsonFiles, yet you are just moving the goal post?
• 2: Json Destroyers exist that allow you to auto generate all these files in runtime with implementing 1 single interface and providing a block texture with extra interfaces to configure extra things as needed, or give full access to model baking process (where you return a BakedModel directly) so why moving file generation itself to the developer?
• 3: What made you decide to go your route? its kinda interesting.
• 4: How much work have you saved with your implementation? How many JStates have you written etc?
• 5: How many extra lines do you need to circumvent simple blocks with 6 different textures?
• 6: How does it deal with Fully Dynamic Models that are to memory hungry (i have a 16GB example) to generate them via json?

Anyhow, now that my Questions are asked. Sorry if they were rude. Anyhow I wish you a great rest of your weekend :3

Edit: Removed answers, mainly because thought lead to only yelling match and I wasn't fond of that (including answers that I posted after your last comment)

[Devan-Kerman]

• I always design my APIs with extensibility/configurability first, which means you should be able to generate any json file you want
• A single interface that provides a texture doesn't allow for complex models. Using pure baked models may not work with resource packs (not sure). You can (and I have) simply implement something like that ontop of ARRP itself
• Extensibility, I can always use my existing code to generate a more complex model, or use methods and normal code to create templates
• Just use a method to create a JState template, then u don't need to write the entire thing yourself every time
• None, if you have a template method
• how do you have a 16gb model, that probably should be a BER and not a baked model

[Devan-Kerman]

idk if just returning a BakedModel will work with other resource packs, ARRP works with resource packs

A block of that complexity should definitely be a BlockEntity, building a BlockState table of that size will freeze the game for several seconds on game start, let alone baking that entire model. Also since the states are so varied they wont compress well in the packed data format.

Yeah ok, but you are still writing json files from hand, its nothing different then a DataGenerator.

Yeah, it is a data generator, but java in the IDE with the reusability of code is considerably easier to write than json

[Devan-Kerman]

Block models should definitely be compatible with resource packs, that's why resource packs exist, ARRP is compatible

There is the new VertexConsumerProvider which can batch rendering, it is very fast, and definitely performs better than millions of blockstates

[Devan-Kerman]

There is more to rendering & performance than just that, creating millions of permanent objects introduces GC pressure, prevents PalettedContainer from compressing which further increases GC pressure. If the model is simple (which pipes are), a batched draw call will certainly perform better. When dealing with millions of blockstates, it will take millions more BlockEntityRenderers for it to perform worse. And the bottleneck is not matrix multiplication anyways, it's the number of draw calls, or vertex count usually

[Devan-Kerman]

I am not telling you to use one over another, there is very obviously a use for custom baked models (though you should be using the fabric api for that and not a home-made api, because your solution will be incompatible with sodium & resource packs, or another mod that wants to override your model)

Remember, the Tesselator(BlockEntity) creates every single frame hundreds of new Matrix instances, Vector4fs and a lot of other things.... just to perform matrix calculations to then throw in a mesh that is drawn once and then throw it out.

This is not true, nor is it a significant portion of block entity render time.

[Devan-Kerman]

Even if you don't place a particular blockstate, the object will still exist in memory because the blockstate table is pre-computed

[Speiger]

Yeah and you missunderstood me, 5million blockstates would be required if i used json. My system compresses it more then you could ever do it, down to 600 which is only a few kilobytes of data at worst. And TSR rendering is just a garbage bin.

[Devan-Kerman]

for cases that should be done with a BakedModel, you should be using the fabric rendering api for that, because otherwise your mod will be incompatible with sodium, canvas, iris (maybe)

[Speiger]

Forge Only FYI. And no its compatible already tested.