JSON Questions

[I_Iz_Shahid]

Hey guys,

 

I was tampering around with my mod in progress and figured out that JSON files wont be read if they contain blocks that are too tall/high. I was wondering what are the limits to the dimensions a JSON can contain?

 

Thanks!

 

[I_Iz_Shahid]

well thanks for that info I guess, but the original question remains unanswered. It doesn't matter anyways, I got my issue solved and this was only for help for future projects. I think through experimenting that a json can contain blocks up to 32 spaces up and -32 down. This is only a guess judging from previous attempts

[DreadKyller]

What JSON are you referring to? there are several places in the code that use JSON. If you're referring to custom block models, I'd be interested to see why you're using JSON instead of a custom block renderer? Since the JSON needs to be parsed, it's be better optimized to do it with a custom renderer.

[Choonster]

What JSON are you referring to? there are several places in the code that use JSON. If you're referring to custom block models, I'd be interested to see why you're using JSON instead of a custom block renderer? Since the JSON needs to be parsed, it's be better optimized to do it with a custom renderer.

 

Are you not aware that 1.8 uses JSON models for most blocks and items?

[DreadKyller]

Many complex blocks still use hard-coded renderers unless a model is found simply because it's always more efficient to have it code-level rather than interpreted. If the code in Minecraft for 1.8 really uses JSON for every block model by default then Mojang understands nothing about optimization. Even if blocks in 1.8 typically use JSON, if you want your block to look a specific way it's still more efficient to hard-code it. You can add support via a simple if statement if you wish that the model can be modified and have it use the JSON if it exists, but by default using the JSON for everything seems like a really inefficient way of making custom blocks.

[delpi]

Is there something about the minacraft source code the leads you to think they are skilled java programmers?

[DreadKyller]

What are you even talking about? The models are parsed once and then baked in an immutable format (IBakedModel in the code) which can be easily uploaded to the GPU in bulk. This is at least just as efficient as the "Tessellator-based", ISBRH-style rendering from pre 1.8.

Then I'm extremely confused about how updating an old mod of mine from 1.7 to 1.8 using the JSON format the new models (which were fairly complex) would decrease my framerate to 15 fps when over 100 of them were rendered. In 1.7 they dropped my frame rate down by 20 (from 110 average). If they were just as efficient then something else is completely messed up.

 

This is getting off the topic of this post, the person asked a question, I answered with what I know from my experience using both, if my experience with the JSON formatted blocks is atypical then I'm sorry, but this feels like it's becoming an argument, which is not what this topic is about.

[Failender]

If youre framerate drops that has NOTHING to do with "damn json parsing sux and is slow" because they arent parsing while you are playing to figure out "how do i render this"

[DreadKyller]

I didn't say anything about the parsing of the JSON being the thing that slows it down, why are you putting words in my mouth?

 

I stated a fact that the same exact model in two different versions of Minecraft, giving massive differences in performance, I didn't blame the JSON parsing, but something isn't as fast when dealing with complex models. I understand that the JSOn is only parsed at the creation of the object and then cached for use later when being rendered, and I havn't modded much with 1.8 so I don't understand exactly how the new system works, as in how the data is physically stored (my guess would be some form of list storing a primitive type that defines the corners texture and vertex UV's of each box) and how that data is then used when rendering (I'm guessing iterating through the list and calling the GL11.glVertex3f and GL11.glTexCoords2f with the data on the current cuboid). Those are only my guesses, having never actually viewed the code. In my experience, every time I've used the 1.8 object format the performance was far worse than the same model in 1.7, you can discuss the efficiency of the method as much as is possible, it won't change the fact that I personally have had issues with it.

 

I said this conversation is getting off topic, I will not reply to this again because it's becoming a stupid argument over different peoples experience with a feature.