Hi guys
I’m using Roaming Ralph sample and just added the panda model scaled by 10. Then used base.oobeCull() and the screenshot shows result.
The problem is that the camera is not looking at the panda model, but is still visible(renderable).Not all of model is visible, but just parts of it, which hides/shows with rotating the camera. Is this normal and how this can be optimized.
That’s normal. A model is rendered if any part of its bounding volume intersects the viewing frustum. The automatic bounding volume is not a tight bounding volume, so it may extend beyond the model itself.
It also depends on how flat your model hierarchy is. If lots of geometry from different parts of the scene are combined into a single node, you will tend to have very large bounding volumes that don’t lead to efficient culling. You can reveal the bounding volumes with model.showBounds().
Usually, this lack of tight bounds is not a problem. Your graphics card can handle rendering many things that are not onscreen. It’s usually not worth the computational effort it would be required to compute more precise bounding volumes. However, if you find that a tighter bounding volume really would help performance in a particular situation, you can compute it yourself and apply it with model.node().setBounds().
David
So, how is calculated bounding volume of model with a lot of small pieces. I have model with complex parts(in blender). Exported model have extremely big bounding volume.
Small gray thing in the center is building and is directly reparented to render. Is problem in blender exports or in panda?
Seems like a perfectly reasonable bounding volume to me. It has to be a sphere, of course, which means it’s going to be very tall around a mostly-flat model, but you couldn’t make a very much smaller sphere that still encloses that geometry.
If you don’t like the sphere, you can put an explicit BoundingBox around it yourself.
Edit: or, you can add the following line to your Config.prc file to make Panda compute BoundingBoxes automatically instead of spheres:
bounds-type box
Boxes are a bit more expensive than spheres, though, so it’s usually not worth the trouble.
David
But this is bounding volume only of gray building. This isnt sphere of terrain. Building isnt reparented to terrain.
Are you sure?
Yes, if you want I can send to you blend/egg or something else.
This is model only in pview.
Might there be some invisible collision geometry or some such?
If you can’t find anything to account for the bounding volume, then yes, send me the egg file. There must be something.
David
Of course. This is model without textures …
http://rapidshare.com/files/374761499/building.egg.pz.html
Ah, it’s caused by all of the unusual scales in your model. You have some pieces with very extreme non-uniform scales. These scales cause bounding spheres of sub-pieces to end up very wide and flat, and so when the bounding sphere of the parent node is computed to surround the bounding spheres of the child nodes, it has to be very big.
You can see this by showing the bounding volumes of the child nodes of your model (or, by walking through the hiearchy in pview with the arrow keys).
You can avoid this by flattening out the scales, unless there is some reason they are really important to you at runtime.
David
What is normal cull time in pstats? My scene is really huge and cull time is 1:1 with draw time(about 17~24ms). May problem be models like above with similar bounding volume?
Is the fixing of models will decrease the draw and cull time?
1:1 is not unusual. The process called “cull” is misleadingly named; it is far more than simply culling geometry to the viewing frustum. It also does all the work of traversing the scene graph, accumulating state, collecting geometry into renderable pieces, computing animations, and generally doing everything on the CPU that can be done before starting to issue the actual graphics commands.
That said, the most important way to reduce cull time is to reduce the number of nodes. Your building has quite a few nodes in it, which is surprising if you will be viewing the building from a distance so that it will be relatively small in the field of view. Generally, you want only one node per cullable object, and you want as few cullable objects as you need for rendering efficiency (based on the capabilities of your targeted hardware).
David
Thanks a lot for information and spent time for solving this “problem”. 