Remove vertices/nodes not in sight

[LunaRebirth]

Hello, again.
My game is nearly complete with many tasks, objectives, online-play, and tons of objects with many vertices.
Obviously one would expect this program to lag quite a bit in larger areas (esp with trees), but it really seems to decrease FPS moving from a low-poly region to a high-poly region.
For example, walking in a town with no trees will get great and smooth FPS. Walking from the town to the forest will majorly decrease FPS and create a very bad experience playing.

I was wondering if there is any way to do something like remove (or set visible to false) any objects you cannot see in sight I.E if a tree is behind another tree, or maybe if half a building is behind another building, then the other half of the building is set to invisible, thus removing lag.

Is there any way to accomplish this through Irrlicht? I'm sure it'll be a pain and a long process but I'd really like this game to run at it's best capabilities possible.

Please Note:
I'm currently separating trees from other objects. All objects (nodes) will be visible at all times (I am, however, using a nearval) except trees. Trees within a far distance are tree->setVisible(false); which does remove lag and increase FPS in the forest, but it's still lower FPS than I should be getting.

[thanhle]

Can you try doing that with a separate thread? That would remove one distance check loop in your rendering loop. I don't know, It might increase FPS.

Regards

[hendu]

1. Profile. Is this a GPU or a CPU bottleneck.
2. If GPU, optimize your tree model. Less transparency, none if possible (alpha_ref).
If CPU, move to instancing, with one instancing node per forest.

[CuteAlien]

Irrlicht already does what you request to some point. Per node there is ISceneNode::setAutomaticCulling which has different options for removing nodes based on camera view. This does not remove polygons hidden behind other polygons - that kind of stuff is rarely done on the CPU as the graphic-card is usually doing it faster (that's what the z-buffer is doing).

If you have large static (non animated) scenes in a single model you can also start culling per polygon by creating an octreescenenode. But in reality it's often better to let the CPU handle this. So instead you can try using IMesh::setHardwareMappingHint. That way you can tell that a model geometry is static and the graphic card will then try to keep it in it's memory. Means the geometry is no longer uploaded to the card every frame as might happen otherwise (it's called hint because cards could still do what they want, but it will work generally).

Another typical optimization is that you can merge many static nodes into a single scenenode which is faster. There are 2 algorithms in irrExt (https://sourceforge.net/p/irrext/code/H ... ene/IMesh/) which can help you with that: CBatchingMesh and CMeshCombiner. They work well in different situations, just try if one of them does the trick in your scene.

Lastly a nice tool for profiling. Try out Very Sleepy on http://www.codersnotes.com/sleepy - it's one of the coolest and easiest to use tools for profiling I've found on Windows.

[LunaRebirth]

Can you try doing that with a separate thread? That would remove one distance check loop in your rendering loop. I don't know, It might increase FPS.

Regards

Last I tried using threads with Irrlicht, everything would bug and/or crash. Dont see why it's be any different with removing vertices

1. Profile. Is this a GPU or a CPU bottleneck.
2. If GPU, optimize your tree model. Less transparency, none if possible (alpha_ref).
If CPU, move to instancing, with one instancing node per forest.

1. CPU (I'm pretty sure but not entirely).
2. --
What do you mean instancing? What I do know is that Irrlicht only loads the object once into a mesh (states so from the console program only showing it's added a tree once). But there are multiple.

Irrlicht already does what you request to some point. Per node there is ISceneNode::setAutomaticCulling which has different options for removing nodes based on camera view. This does not remove polygons hidden behind other polygons - that kind of stuff is rarely done on the CPU as the graphic-card is usually doing it faster (that's what the z-buffer is doing).

If you have large static (non animated) scenes in a single model you can also start culling per polygon by creating an octreescenenode. But in reality it's often better to let the CPU handle this. So instead you can try using IMesh::setHardwareMappingHint. That way you can tell that a model geometry is static and the graphic card will then try to keep it in it's memory. Means the geometry is no longer uploaded to the card every frame as might happen otherwise (it's called hint because cards could still do what they want, but it will work generally).

Another typical optimization is that you can merge many static nodes into a single scenenode which is faster. There are 2 algorithms in irrExt (https://sourceforge.net/p/irrext/code/H ... ene/IMesh/) which can help you with that: CBatchingMesh and CMeshCombiner. They work well in different situations, just try if one of them does the trick in your scene.

Lastly a nice tool for profiling. Try out Very Sleepy on http://www.codersnotes.com/sleepy - it's one of the coolest and easiest to use tools for profiling I've found on Windows.

Thank you for the suggestions, I'll check them out!

[Mel]

I'd render the forests packing the trees into large batches, say 20 or so trees per batch, and use alpha testing instead of alpha blending for the leaves. Most applications render trees this way, or combine them so the trees look nice close, but may benefit of the alpha testing when far.

[thanhle]

Last I tried using threads with Irrlicht, everything would bug and/or crash. Dont see why it's be any different with removing vertices

It depend on how you use thread. You would not use thread to remove node or something like that directly. In place where irrlicht doesn't like cross thread operation, you would schedule event or something like that for irrlicht rendering loop to do in future time. In some operations you can use external thread without a problem (agent path planning etc...).
I think setting a node (or a group of node) visible property on a different thread will not crash irrlicht as you are not changing any pointer.
Unless I'm missing something, the different with thread is you are removing one distance check loop inside a rendering loop.

Anyway, great to hear that you have progress far, from not knowing much about network programming to a complete a MMORPG. Wow! cool. You need to show us how to solve all the problems you have with all those questions. That would be useful for newbie like us.

I think Mel and Hendu have giving you some good options to speed it up. You might need to search the forum for those codes.

Goodluck mate.