Hi Jens,
On Wed, 2003-11-12 at 13:02, Jens Freisen wrote:
> Hello Everyone!
>
> We are currently developing a visualization for a complex geographical
> model. To visualize the different forms of landusage we use some VRML
> models like industrial buildings, different kinds of trees and so on. To
> get a good visual quality in combination with high performance we wanted
> to use the Level-of-Detail feature of OpenSG.
>
> But we get a serious performance breakdown when using our VRML models,
> and I don't think it hat to do with the polygon count of the models.
> When zooming far out so that you can see the whole scene, there are
> exactly 816 (LOD-)objects and they all switch correctly to the lowest
> resolution, which means about 60 polygons per object. So there are
> 816x60=48.960 polygons, which is not that much considering that we are
> using quite a powerful machine. But switching on the objects decreases
> the framerate from about 100fps to 11fps! We also have a iso-surface
> visualization to visualize weather data. It's got about 60.000 polygons
> and decreases the framerate only about 5 fps.
in many cases the number of objects is more of alimitation than the
number of polygons nowadays. There is some overhead involved in setting
up the rendering of an object, and the graphics cards are so fast that
this becomes the limitation instead of the actual polygon rendering. For
D3D nVidia has a rule that you cannot render more than (AFAIR) 10k
objects/buffers per second, for OpenGL it usually is not quite as bad.
> I already tried not to use the LOD-Node but to load only the low-res
> models (see below) and use them directly. Same effect: A significant
> performance breakdown that can not be explained be the polygon count.
> Here is the code fragment showing the loading of the VRMLs and the
> creation of the LODs:
>
> NodePtr ntree[DetailLevels];
> ntree[1] = SceneFileHandler::the().read(ntreefilename1);
> ntree[2] = SceneFileHandler::the().read(ntreefilename2);
> ntree[3] = SceneFileHandler::the().read(ntreefilename3);
>
> [...]
>
> for (i=0;i<DataStore::dataWidth;i++) {
> for (j=0;j<DataStore::dataWidth;j++) {
> if (trees[i*DataStore::dataWidth+j]!=0) {
>
> ttrans[l]=Node::create();
> ttrans_core[l]=Transform::create();
> treelodNode[l]=Node::create();
> treelodNodeCore[l]=DistanceLOD::create();
>
> // create the nodes for the LOD-Geometry
> // 1st
> treeGeoNode1[l] = ntree[1]->clone();
> // 2nd
> treeGeoNode2[l] = ntree[2]->clone();
> // 3rd
> treeGeoNode3[l] = ntree[3]->clone();
>
> // Create a LOD-Node...
> beginEditCP(treelodNode[l], Node::CoreFieldMask |
> Node::ChildrenFieldMask); {
> {
> treelodNode[l]->setCore(treelodNodeCore[l]);
> treelodNode[l]->addChild(treeGeoNode1[l]);
> treelodNode[l]->addChild(treeGeoNode2[l]);
> treelodNode[l]->addChild(treeGeoNode3[l]);
> }
> endEditCP(treelodNode[l], Node::CoreFieldMask |
> Node::ChildrenFieldMask);
>
> // Set the LOD-Node-properties
> beginEditCP(treelodNodeCore[l], DistanceLOD::CenterFieldMask
> | DistanceLOD::RangeFieldMask);
> {
> treelodNodeCore[l]->getSFCenter()->setValue( Pnt3f(0, 0,
> 0) );
> treelodNodeCore[l]->getMFRange()->push_back( 5.0 );
> treelodNodeCore[l]->getMFRange()->push_back( 20.0 );
> treelodNodeCore[l]->getMFRange()->push_back( 40.0 );
> }
> endEditCP(treelodNodeCore[l], DistanceLOD::CenterFieldMask |
> DistanceLOD::RangeFieldMask);
>
> // Matrix for translation
>
> m.setTransform(Vec3f(j,punkte[i*DataStore::dataWidth+j].y()+diff,i));
>
> // multiplicate with Scale-Matrix
> m.mult(scale_matrix);
>
> beginEditCP(ttrans_core[l]); {
> ttrans_core[l]->setMatrix(m);
> } endEditCP(ttrans_core[l]);
>
> beginEditCP(ttrans[l]); {
> ttrans[l]->setCore(ttrans_core[l]);
> ttrans[l]->addChild(treelodNode[l]);
> } endEditCP(ttrans[l]);
>
> beginEditCP(tree_root); {
> tree_root->addChild(ttrans[l]);
> } endEditCP(tree_root);
> l++;
> }
> }
> }
>
> In the ttrans[l]-EditCP section I replaced the
> addChild(treelodNode[l])with addChild(treeGeoNode1[l]) to test the
> performance when using only the low-res object without the LOD-feature.
>
> Are there any known problems when using many loaded 3D-objects? Or
> should we try to somehow use a kind of 'shared geometry'? If not what
> could be the reason for the performance breakdown?
> Any hint will be greatly appreciated!
One question would be which version you're using. I did add some things
that significantly sped up large numbers of objects, especially when
they're all visible, after 1.2. Maybe you can try using a dailybuild, if
you're using the 1.2 release.
Hope it helps
Dirk
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
