BoundingVolume and Efficiency

I was recently reading through the wiki and reread the section on BoundingVolume (http://www.jmonkeyengine.com/wiki/doku.php?id=boundingvolume). I don't know why I had this misconception, but I thought that Bounding Volumes only had to do with picking/collisions – apparently they are using for culling as well? Makes sense, but here's the question – if I make a Sphere, for example and don't give it a bounding volume, what happens with culling? Is it always more efficient to give an object a bounding region? I'm also confused about updateWorldBound – when should I run this to be more efficient and should this replace my updateModelBound calls at times?



On a different note, I also ran into some problems with BoundingSphere – if I am creating a very detailed sphere and then setting the modelbound to a sphere as well, will this slow down things? What I mean by this is, does the bounding volume use the geometric object such that by setting a boundingsphere to my sphere, I am essentially creating two very detailed spheres and slowing down everything?

Bounding volumes don't have geometry on their own, they are logical, and are used for efficient computation of culling and picking, as you noted. In other words, if you create a high poly model, this will in no way affect your performance on bounds. Bounds only have geometry in DebugState or SimpleGame, and is for visualization purposes only (oh, and in physics is somewhat the same… physics objects don't have geometry on their own).



You should always updateModelBounds whenever you explicitly change them/create them. After that, updateGeometricState will take care of keeping them up to date  :wink:



If you don't create a bound for an object, strange things will happen with culling (like objects not being rendered even when they should be visible), so I recommend always creating them.

duenez said:

Bounding volumes don't have geometry on their own, they are logical, and are used for efficient computation of culling and picking, as you noted. In other words, if you create a high poly model, this will in no way affect your performance on bounds. Bounds only have geometry in DebugState or SimpleGame, and is for visualization purposes only (oh, and in physics is somewhat the same... physics objects don't have geometry on their own).

You should always updateModelBounds whenever you explicitly change them/create them. After that, updateGeometricState will take care of keeping them up to date  :wink:

If you don't create a bound for an object, strange things will happen with culling (like objects not being rendered even when they should be visible), so I recommend always creating them.


Ah thank you. :)
duenez said:

Bounding volumes don't have geometry on their own, they are logical, and are used for efficient computation of culling and picking, as you noted. In other words, if you create a high poly model, this will in no way affect your performance on bounds. Bounds only have geometry in DebugState or SimpleGame, and is for visualization purposes only (oh, and in physics is somewhat the same... physics objects don't have geometry on their own).

You should always updateModelBounds whenever you explicitly change them/create them. After that, updateGeometricState will take care of keeping them up to date  :wink:

If you don't create a bound for an object, strange things will happen with culling (like objects not being rendered even when they should be visible), so I recommend always creating them.


So does SimpleGame decrease performance by creating geometry for bounds?

if you press 'b' and visualize them, yes.