[Suggestion] Fast item render option

[jaquadro]

(Cross-posting from Bibliocraft thread)

I'd like to suggest a config option to switch item rendering to a flat polygon (render as inventory). Possibly on a per-block-type basis.

The motivation for that is a potion shelf full of potions takes two orders of magnitude longer to render than an average TESR. That's almost entirely from the insane costs of rendering a 3-pass potion bottle 12 times. Someone stuck 12 of these blocks on a wall and dropped FPS on a good machine down to about 15.

You're welcome to swipe any code from here, though I can't claim to have a perfect implementation. There's some trickery surrounding glint that requires part of the default RenderItem to be reimplemented. The difference on my mod between rendering 4 potion labels as 3D vs flat is 900us and 70us, respectively.

[Nuchaz]

Thanks for the link to some code so I can see how something like this would be done. I have actually been interested in doing a fast-graphics type option on a per-block-type basis, but I hadn't really been sure on how to do it. I'll try to spend some time on this when I get a chance. Likely after I get the atlas finished, that has been my goal now for awhile.

[Gwani]

Having just tracked down the source of a significant framerate drop within a town on our server to an alchemist's shop full of potion shelves i like to express my strong support for such an option.

The shop contains ~35 completely filled shelves. On my GTX560M GPU i see the framerate decrease from ~40fps to ~8fps whenever i look into the direction of this shop.

Having these shelves in a closed building doesn't help either - i thought there might be some sort of occlusion culling going on when their view is completely obstructed - but that doesn't seem to be the case.

This performance hit is somewhat frustrating, since it effectively limits the acceptable number of decorative shelves and similar objects within any view frustum overlooking the town to quite a small number (so we have to enforce limits on the usage of those blocks to keep the area playable for others).

Ahh... yes, and i'm also in support of issue #216... with any luck, such performance tweaks might come down to just accepting a pull request by a fan of your great mod ;-)

[jaquadro]

I went into more detail on this topic in November. It's equally relevant to Bibliocraft, and for something like a filled potion shelf, multiply the numbers by 3 - 4.

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/2198533-storage-drawers-v1-2-3-updated-feb-20-15?comment=174

[Gwani]

Thats a nice overview you have compiled there, and it tells a sad story on how inefficient a lot of rendering in Minecraft is. When i even look at your fast rendering and see the timing difference between the oak and the spruce drawers (~1.3µs vs ~23µs) it really makes me wonder what's happening there behind the scenes. From what i see visually, i'd expect the spruce drawer to have to render 4 additional textured quads (which is virtually nothing for a modern GPU), but instead it takes additional time which would be sufficient to render 16 extra oak drawers.

Modded Minecraft has a lot of potential for performance optimization, but unfortunately this will be hard to achieve, since a lot of mods do their own rendering with many state changes for each object and rebuilding/uploading a lot of geometry each frame (instead of just keeping it in GPU memory).

Well, however, 23µs is still much better than over 800, so having an option to render the items in 2D would definitely help - and besides - for non-block items it doesn't look much different than the fancy pseudo-3D version ;-)

[jaquadro]

Well you need to remember that the empty oak drawers are technically rendering "nothing", because what's being measured is the TESR component of the block (the part that has to re-render every single frame, as opposed to the ISBRH component which gets compiled once in a chunk render update, and then it's just static data on the GPU).

So the 1.3µs is really the time to check a few data structures and quit.

Minecraft rendering is quite inefficient though, and the rendering being done is all immediate-mode (or something not far from it) rendering which is the worst possible thing you could be doing. It's a miracle it works as well as it does.

[Nuchaz]

This is definitely something on my back-log of TODO. I haven't decided if I am going to try to work it into my 1.10 update I am working on now, I would like to, but it depends on how much time it takes to do the other things I am working on. I am certainly considering it though for this update.

Originally I really wanted to use the in-game GUI support forge started adding, but they never finished. I think CPW was working on that before he turded out on us because of the Microsoft thing. That would have been the ideal location for these options I think. I'll have to come up with something else I suppose.

That is a really great breakdown on how the different items affect rendering speeds jaquadro. Thanks for that. It is true, minecraft is not that great at how it renders stuff. I really wish I could use ISBRH for my stuff, but there just isn't any way to do what I want with them. I never could even get a model rendered from the AdvancedModelLoader in an ISBRH, let alone try to update it when players make inventory changes. So I do my best my cache as much as I can for my TESR. Most variables are calculated and saved on the TEs only when the player interacts with the blocks. I think that helps a little, but as was noted in that breakdown it is the item rendering that is the real killer, esp items with glint.

[jaquadro]

Are you referring to the GUI-based mod configuration in Forge? Because that was completed and a bunch of mods are using it. If you're referring to something else, then I guess I never heard of it.

My opinion is that if you swipe the ItemRenderer class and GLUtil (to save/restore the right attribs) from what I linked above, it would probably be minimal work to integrate.

You're right that most of your blocks are very hard to render as an ISBRH. Most people use TESRs just because it's easier to work with. Make your model in Techne and plug it in. Your shelves would be reasonable to render an ISBRH component for. A block can support both at the same time.

[Nuchaz]

I'm referring to the in game "Mod Options" menu. When your in game and his esc, right beside the "Options..." menu is a "Mod Options..." menu, but it just opens a page that says "Test 1 TEST2 DISABLED". I am guessing you are referring to the Config menu in the Mod list page. I do need to figure out whatever I need to do to make that workable, that is true. The in game menu just seemed ideal, if it was actually usable.

I'm actually dropping support for my techne models. I started using techne and some of the models are still techne models (printing press, typesetting table, desk, and the bookcase books, which will all have to be converted at some point for MC 1.8), but I couldn't easily UV map models so I can use vanilla wood textures. Mainly it was the advanced UV mapping support that drove me to use mostly .obj models. Most of those were done in 3dsmax, but as of january now I've switched to Modo Indie. (I really enjoy Modo compared to other 3d packages I've used). Now they are obsolete in Minecraft v1.8. Models will have to be converted to json or forges new .b3d model support (which I am quite intrigued about because they include animation support). There was also a note that an .obj model loader is coming too. Currently I mostly rely on .obj models and could very easily re-export them as .b3d. So I pretty much want to stick with these kinds of models to minimize updating work.

[Nuchaz]

Just an update on this, per-block force fast render options are going into the config file for my next update. I am going to force fast render on potion shelves, labels, and fancy signs by default. Thanks again jaquadro for an example on how to make this work.