Hi Albino, why don't you //Update camera //Update speedtree forest //Draw forest
??? Greetings, Richard Hi, I have implemented SpeedTree4.1 as a custom drawable in OSG2.2. While the camera is stationary the trees appear to draw correctly. However once the camera moves, the trees rendering (translations?) appears to lag in relation to the rest of the scene. Once the camera stops, they "catch up". In my test application, I integrate a speedtree forest into a custom drawable and have a simple terrain model loaded into a osg::Node. The scenegraph has a Group node as the root with the custom drawable and terrain as children. Screenshot of the scene with a stationary camera: The trees are rendering where they were placed. (feel free to admire the programmer art :) http://img293.imageshack.us/img293/5408/stationaryrv8.jpg Screenshot of the camera being moved down: Once the camera stops, the trees will "catch up" and the scene will render correctly like in the above screenshot. http://img242.imageshack.us/img242/764/lagmq5.jpg Implementation details: I've adapted my implementation using the reference application that comes with speedtree as it suits my needs pretty well. I'm happy to leave LODding and culling to speedtree. The drawImplementation of my custom drawable: (speed tree code is commented out in case it violates the license agreement. It's just a line of code.) glGetFloatv(GL_PROJECTION_MATRIX, projMat); glGetFloatv(GL_MODELVIEW_MATRIX, modelViewMat); glPushAttrib(GL_ALL_ATTRIB_BITS); //Draw speedtree forest //Update speedtree camera with the camera's position, projMat, modelViewMat and false as the final parameter. //Update wind glPopAttrib(); renderInfo.getState()->apply(); //needed? I set the boundingbox to be osg::BoundingBox bbox(0,0,0, 9999999, 9999999, 9999999); My rationale behind this is to make a HUGE box so that OSG doesn't try culling it. I leave that upto speedtree. Is there a better way? Finally, I set this drawable not to use display lists, so that the speedtree code called from drawImplementation always gets called. I haven't found a good strategy to solve this yet. - I've moved around API calls. - Look into forcing draw calls. - Forced OSG to not use multithreading - Prayed to some deity My next plan of attack will be to throw in the osgteapot custom drawable example and see if the same issue occurs but with teapots. Any ideas or thoughts are greatly appreciated. Bino _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
