Performance and drawtype = mesh

Post Reply
User avatar
sirrobzeroone
Member
Posts: 593
Joined: Mon Jul 16, 2018 07:56
GitHub: sirrobzeroone
Contact:

Performance and drawtype = mesh

by sirrobzeroone » Post

I've been playing around with using meshnodes to generate a whole map ie all nodes created from an .obj or .b3d mesh. However I'm noticing a significant performance hit when doing this, I can switch the few test nodes between types pretty easily.

when nodes are created from obj/b3d "mesh" - eventually after exploring enough of the map (a chunk about 300x300) the client will go non-responsive, I can make the situation worse by flying and fast walking. There is significant delay when placing and digging and perceptual micro load stops.

Change the nodes to normal type and it runs smooth as, no matter what I do.

Nominally texture size and complexity is identical and I change no code, so it definitely appears to be a performance hit from using mesh nodes to generate the whole map. Understand I'm probably pushing the engine (and maybe my pc) beyond its design limits but I wondered has anyone else tried this and noticed something similar?

Is this expected? I was under the impression the engine converts everything to mesh's before we play, the only thing I can think of is that my 2kb b3d meshes are significantly larger than the engine generated ones...but its just a guess.

I'm mostly just curious if there is a technical reason for this - thanks

User avatar
Krock
Developer
Posts: 4649
Joined: Thu Oct 03, 2013 07:48
GitHub: SmallJoker
Location: Switzerland
Contact:

Re: Performance and drawtype = mesh

by Krock » Post

Minetest performs some optimizations on normal nodes:
1) Mapblocks that cannot be seen are skipped from drawing (in 5.0.1 that's all solid nodes)
2) Faces are combined to draw less triangles. See F5 wire grid mode.
3) Faces that are enclosed between nodes aren't drawn. See noclip + free_move inside nodes

Your mesh might also have a little bit more than 12 triangles, and maybe even with backface culling disabled. This quickly sums up in a few thousand triangles to draw.
Look, I programmed a bug for you. >> Mod Search Engine << - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>

User avatar
sirrobzeroone
Member
Posts: 593
Joined: Mon Jul 16, 2018 07:56
GitHub: sirrobzeroone
Contact:

Re: Performance and drawtype = mesh

by sirrobzeroone » Post

Thanks Krock, really appreciate the info

I checked out wire mode and noticed what you said about the combining when viewing a "default" node eg dirt, thats a pretty cool feature. When viewing an .obj/b3d or even a nodebox node I can see the engine dosen't do the same kind of optimizing even if the nodes next to each other are identical...like you said that is heaps more to draw/process when viewing a whole map- even visually the contrast is significant.

I'd imagine a beefer pc with video card would work around this issue...my old surface3 isn't exactly gaming quality :).

Thanks again for the insights.

ZAAo
Member
Posts: 47
Joined: Tue Jul 27, 2021 16:15

Re: Performance and drawtype = mesh

by ZAAo » Post

Krock wrote:
Sat Sep 07, 2019 11:59
Minetest performs some optimizations on normal nodes:
1) Mapblocks that cannot be seen are skipped from drawing (in 5.0.1 that's all solid nodes)
2) Faces are combined to draw less triangles. See F5 wire grid mode.
3) Faces that are enclosed between nodes aren't drawn. See noclip + free_move inside nodes

Your mesh might also have a little bit more than 12 triangles, and maybe even with backface culling disabled. This quickly sums up in a few thousand triangles to draw.
Thanks for the explanation, Krock. Very interesting, and makes sense...
How about when using drawtype = "nodebox" - how does that affect performance (and resource usage.. RAM, CPU...) compared to plain (simple) nodes, vs mesh models?

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 5 guests