>Hi Albino, >why don't you >//Update camera >//Update speedtree forest >//Draw forest
Richard, you're a legend that worked! This might be hard to believe, but that was one of the ways I moved the API calls around (it makes sense afterall). I've just realized that Visual Studio, although compiling changes to my custom drawable... doesn't seem to do anything. I just noticed this by chance as a console debug statement wasn't reflecting my changes. A full rebuild has rectified that. Very strange. Very annoying. I think the lesson is to not follow the examples too blindly... The reference application probably has this issue but isn't noticeable since there isn't a terrain reference point. >Hi Bino, >I have no ideas why you trees are floating, too little code available to really have a go at what might be up. Sorry about that and thanks for the culling tip. Bino -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmidt, Richard Sent: Wednesday, August 20, 2008 11:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] SpeedTree4.1\OSG2.2 draw lagging 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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
