Ok, I'm going to have a look into occluders later, the rendering speed seems
to have significantly improved given the use of small feature culling (pixel
size is throttled as you move around the scene to maintain an interactive
framerate).
My next big issue is memory usage. I am finding the OSG app as it stands is
using approximately 50% more memory than a legacy app we are replacing,
which is just coded in standard OpenGL.
Objects are imported in a legacy file format, which have previously been
created in a CAD package. The object format is not optimal but can be
optimised once loaded.
For each object in the scene (of which there may be up to 1.5m objects), I
am creating the following OSG constructs:
1. 1x PositionAttitudeTransform
2. 1x Geode (parent is PAT)
3. 1x Stateset per Geode containing material data (objects are a single
colour, no textures).
4. 1x Geometry (added to Geode)
- 1x Vec3Array containing vertices
- N PrimitiveSets as Currently osg::DrawArrays(POLYGON)
- Smoothing visitor is run over the geometry to create Normals
Now we have 1 Geometry per Geode, which may or may not be efficient. The
Geometry is defined as our "Object". Each object in the scene is pickable
and movable so if it is more efficient to group multiple Geometry's per
Geode then I need a way to move these around using
pick/translate/rotate/scale.
Secondly the use of DrawArrays(POLYGON) results in a horrendous amount of
primitivesets, however I am subsequently running the osgUtil::Optimizer over
the geometry to clean it up - which does a great job. So far I've
experimented with MERGE_GEOMETRY and TRI_STRIPS of which MERGE seems to give
the same memory results but is much quicker to run. TRISTRIPS appears to
drop the number of vertices requred per object by about 60% but curiously in
task manager memory doesn't drop.
I am considering the following options to reduce memory overhead.
1. Get rid of PATs. Instead store position/attitude/scale as Vec3f in our
object (PAT uses Vec3d) and compute a matrix transform on creation of the
object. When an object is picked, insert a PAT above it in the tree and move
it around, after remove the PAT and flatten the transform onto the vertices
- I guess I have to do a forward/reverse transform on the vertices to go
from global to local space and vice versa for this?
2. Group multiple geometries per geode. Not keen on this but if it will help
I'll work around it.
3. Experiment more with osgUtil::Optimizer flags to reduce vertex count.
4. When loading the legacy file format, import object by object, use
osgUtil::Simplifier to create medium/low detail versions, serialize all
three into our custom file format and use PagedLODs for each object.
Then for performance
5. Tile the database, grouping objects by location to assist the cull phase
6. Removal of PATs as per 1. should help the cull phase
7. Look into the use of shadow occlusion to remove objects.
Please let me know what you think - any feedback is much appreciated,
Andrew
--------------------------
Off topic - I replied to "[email protected]" with the
subject line "Re: Rendering Performance and Proper Way to have millions of
moveable objects" so I hope this has now gone to the right thread. If I'm
still doing something wrong fee free to let me know.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
