Octree to render only objects to a certain distance

I recently read the https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:statsview wiki doc and in there it says:

“Triangle Counts. If your game is sluggish and triangle (polygon) count is high, then you are rendering too many, too detailed meshes. Tell your graphic designers to create models with lower polygon counts. The limit is around 100’000 vertices for a scene, considering that the slowest currently used graphic cards cannot handle anything beyond that.”

So I have some questions:
is there an container for spatials which only renders objects in a certain distance to the camera? i’m thinking of something like the octree class, but i think its used only for occlusion in jme and can’t be used for such a scenario. Is that right?

I believe objects are already culled by the near and far clipping plane.

Any slowdown you have might not be related to triangle count at all, but object count instead. If you provide some more info about your game we can better help pin down the issue.
You can pull in the camera’s view frustum far plane to not render the far away objects. LOD is also another technique to lower poly count. But videocards nowadays can render a million polys without breaking a sweat.

Those numbers should probably be updated actually. They look fairly low, although I guess it is triangle count not vertex count. A section about object count should be there as well…

@zarch said: Those numbers should probably be updated actually. They look fairly low, although I guess it is triangle count not vertex count. A section about object count should be there as well...

Though I can’t help but notice the OPs avatar is the Android mascot… and those numbers probably do still hold for smartphones… but I don’t know for sure.

@Sploreg said: Any slowdown you have might not be related to triangle count at all, but object count instead. If you provide some more info about your game we can better help pin down the issue. You can pull in the camera's view frustum far plane to not render the far away objects. LOD is also another technique to lower poly count. But videocards nowadays can render a million polys without breaking a sweat.

I dont have a performance issue :wink: I just want different render distances for different types of objects. A layer system where layer 1 renders objects to the distance of 10 meter and layer b to a distance of 100 meter.

How does JME optimize the scene graph to not have to check for any object if its in the field of view for example? When you add one 1 million objects to the scene but most of them are way to faar away to even been considered rendering this octree concept would be useful.

I think if you are adding 1 million objects to a scene without any kind of paging then you are going to have problems no matter what. And paging works much better with regular grids.

@pspeed said: I think if you are adding 1 million objects to a scene without any kind of paging then you are going to have problems no matter what. And paging works much better with regular grids.

Ok i would get a memory problem if i would keep the 1m objects in memory all the time but the performance shouldn’t be affected that much since getting the objects close to the camera in a octree only needs log(n) to look up the elements in the bounding box, right? Can the vegetation or tree system be used to display specific objects? Or is it only possible to define some geomentries which are then randomly picked and positioned?

But if you would already be paging… then that already takes care of a bunch of things and you get infinite scalability.

And just to be clear:

Octree: access in O(logn) time. Inserts in??? I guess it depends on if your octree should be rebalanced.

Regular grid: access in O(1) time. Inserts in O(1) time. Does not need to be balanced. Can be sparse… can be infinite… easily adapts to paging, etc.

1 Like
@pspeed said: But if you would already be paging... then that already takes care of a bunch of things and you get infinite scalability.

And just to be clear:

Octree: access in O(logn) time. Inserts in??? I guess it depends on if your octree should be rebalanced.

Regular grid: access in O(1) time. Inserts in O(1) time. Does not need to be balanced. Can be sparse… can be infinite… easily adapts to paging, etc.

Hm very good point there, in what scenario would it be a good idea to use structures like Octrees then? ^^

ok so what if I want to create a 3d space shooter and do the paging for 3d asteroid fields, can I extend some jme concepts or should i write my own paging mechanism?

@simon.heinen said:
@pspeed said: But if you would already be paging... then that already takes care of a bunch of things and you get infinite scalability.

And just to be clear:

Octree: access in O(logn) time. Inserts in??? I guess it depends on if your octree should be rebalanced.

Regular grid: access in O(1) time. Inserts in O(1) time. Does not need to be balanced. Can be sparse… can be infinite… easily adapts to paging, etc.

Hm very good point there, in what scenario would it be a good idea to use structures like Octrees then? ^^

I don’t know. I’ve never been able to figure that out. And I say this from the perspective of having implemented numerous quad trees because it was “the right way” only to rip them out later when I felt stupid. :slight_smile: I think as soon as you have object overlap and/or minimum split sizes then a regular grid always makes more sense. I’m still not convinced that octrees or quadtrees ever make sense, though.