Time Nick Message 09:54 jin_xi sofar: check how single rotating inventory cube is rendered... uses the exact same code as rendering an entire mapblock for every node. idk if this is really wasteful but it sure looks that way 12:10 Sailor6249 Hello there! I'm planing to organize a meeting where could learn how to translate a software. I'm from South France so I speak Occitan. I'm here to ask if it would be possible to add the Occitan language to the list. Gràcias ! 12:32 twoelk Sailor6249_: of course :) just provide content 12:34 Sailor6249_ Sure! I was asking so that it could be added to weblate :) Then we will make our cooking :) 13:11 Sailor6249 twoelk: Sure! I was asking so that it could be added to weblate :) Then we will make our cooking :) 18:22 nerzhul hi, merging #6253 in ~ 5 mins 18:22 ShadowBot https://github.com/minetest/minetest/issues/6253 -- Rewrite rendering engine by numberZero 18:23 sofar nice 18:23 nerzhul sofar, yeah 18:23 sofar nerzhul: did you see my comments yesterday on frameretrace? 18:23 sofar maybe numberzero is interested in playing with that as well 18:24 nerzhul sofar, no i was at the hospital to release a new children version 18:24 sofar so, a colleague of mine has been working on an extension of apitrace 18:24 sofar apitrace allows you to collect all openGL calls an application makes 18:25 sofar the new extension called frameretrace allows you to virtually step through, and profile, every openGL call 18:25 sofar so you can see which ones are expensive 18:25 sofar turns out I think the inventory meshes are likely really expensive 18:25 sofar I posted some links, too 18:26 sofar https://i.imgur.com/1QlqclU.gif 18:27 sofar that's a gif of the render steps (the expensive steps) 18:27 ThomasMonroe that would make sense, the inv meshes 18:27 nerzhul sofar, as we are using irrlicht not opengl directly i don't see why we should use it for MT 18:27 nerzhul the lag is due to rendering on client event loop 18:28 sofar this has nothing to do with lag 18:28 sofar this has to do with spending a lot of time rendering stuff that shouldn't be rendered every frame 18:29 sofar we could just render the entire inventory hud to a texture if it doesn't change, and reuse it 18:29 sofar I'm sure there are smart ways of doing that 18:30 rubenwardy that's essentially what the older code did 18:30 rubenwardy before RBA's changes 18:30 sofar as for irrlicht, it's a really thin API 18:30 sofar rubenwardy: yeah, I realize that, too 18:31 rubenwardy he seemed to think - and assert - that rendering the meshes was less expensive than rendering to the texture, then rendering those textures (which would be mapped to a polygon to be drawn) 18:31 rubenwardy but there was no benchmarking at all 18:32 sofar this tool essentially gives everyone the tool to benchmark it 18:32 rubenwardy nice 18:32 rubenwardy how does it compare to rendering the world? 18:32 sofar you can replay an entire minetest session that you previously have recorded 18:32 sofar and it measures the FPS/time needed to render 18:33 sofar so you can create a specialized scene if you need (e.g. with transparency) 18:33 sofar and then run `apitrace trace minetest --go --wordname demo` etc 18:33 sofar run it for a few seconds, alt-f4 18:33 rubenwardy that gif looks odd - it seems to be rendering internal faces with the cube drawtype 18:33 sofar then load the trace in frameretrace 18:34 sofar the gif doesn't show the bottom of the frame unfortunately 18:34 sofar but yes it renders stuff that's not visible in the first frame 18:34 sofar occlusion culling not entirely effective 18:36 sofar anyway, maybe if I have some time I'll profile the before/after effect of the inventory mesh patch 18:36 rubenwardy I've not really looked into Minetest's rendering yet. I do know that generally the bottleneck tends to be opengl calls rather than vertices on better GPUs, which could explain why a few item stacks takes more than the mapblocks. Unless I'm reading it wrong 18:37 rubenwardy sounds good 18:37 sofar I get the idea that the mapblocks take the same time as inventory meshes 18:37 sofar but there's only like 4-5 mapblocks rendered and 3 inventory meshes with 3 faces each 18:37 sofar so we end up with 12-14 expensive render steps instead of 4-5 18:38 sofar that's a total waste, of course 18:38 sofar but, like I said, need more data 18:38 sofar maybe we can make a single mesh for all the inventory items or something 18:39 rubenwardy yeah. Batch the calls 18:56 basicer` I had been using BuGLe to debug minetest rendering, worked fairly well. 19:14 Fixer sofar: can you look into minimap rendering? It is slow as hell on my hardware compared to minecraft beta minimap from year 2011 19:22 Fixer sofar: also, that tool may be useful for implemeting alpha textures z-sorting of some sort 22:00 paramat sofar i suspect the inventory rendering may be intensive to support to the unnecessary rotating selected item feature, better to remove that feature to have better performance i feel 22:01 VanessaE um, no. 22:01 VanessaE removing the feature just avoids fixing the real problem. 22:02 VanessaE (why is everyone so against eye candy? it's a game engine for crying out loud) 22:06 nerzhul the item rotation in inventory is very lightweight 22:18 sofar I need to redo the profile and confirm that it's not something else 22:18 sofar until then, nobody knows anything of value 22:18 sofar (except there's this cool tool that gives you reliable and concrete data!) 22:19 paramat yeah hopefully it is lightweight, i just mentioned it in case it requires an implementation that is intensive, in which case the feature would be the real problem 22:20 paramat also, there is a lot of support for eye candy in MT, i'm in a small minority so don't worry =) 22:27 Fixer when i tested it last time I had literally same fps 22:27 Fixer except rotating thing 22:27 Fixer it is not even enabled by default 22:29 Fixer *did not test rotating thing, but did test new inventory at the time* 22:57 numzero1 er? inventory meshes? they *are* expensive. perhaps due to using *a lot* of materials 23:01 numzero1 or... believe it or not, it seems to clear Z-buffer for each stack drawn 23:07 numzero1 > profile, every openGL call 23:07 Fixer it was ok at least on my ATI card, experience may vary 23:07 numzero1 is it really possible? OpenGL calls often defer actions 23:10 numzero1 well, I feel I missed something. reading the chat log now 23:11 sofar numzero1: did you see my comments on the FrameRetrace tool? 23:12 numzero1 the comments you mentioned today? no 23:12 sofar numzero1: http://irc.minetest.ru/minetest-dev/2017-10-30#i_5123833 23:19 * numzero1 installs apitrace 23:19 sofar numzero1: you want this fork and build qapitrace as well 23:20 sofar sec finding url 23:20 sofar https://github.com/janesma/apitrace 23:20 sofar branch frameretrace 23:22 numzero1 okay 23:23 numzero1 thanks 23:25 numzero1 actually compiling MT right now 23:35 numzero1 well, after commenting out hud.cpp:655 (clearZBuffer), inventory works considerably faster 23:36 numzero1 I don't even notice any glitches; perhaps it was cleared somewhere else 23:40 paramat interesting