Hi Jose, Getting 10fps is pretty bad, I personally wouldn't be happy till get that up to 60Hz+. The first step is to work out what is the bottleneck - you say that you have too many triangles in your scene, and cutting this down gets you back your frame rate. There are lots of ways to manage the number of triangles, if you have fog to hide what is in the distance you can get away with enabling culling on the far plane, but if you do enable this then you have to disable the compute near/far as the two will be dependant on each other and you'll end up with a feedback loop that might not behave well.
Far plane culling isn't the only techinique - using LODScale is another technique, as is use of osgTerrain::Terrain::setSampleRatio() if you are using osgdem --terrain generated databases. See osgmultitexturecontrol example for code that controls these parameters. I've talked about these in last month so have a trawl through the mailing list archives. Robert. On Tue, Sep 23, 2008 at 8:59 PM, Joseanibal Colon Ramos <[EMAIL PROTECTED]> wrote: > Hi all, > > Good, I am happy it is all clearer now, and I am sorry it wasn't enough at > first. So back to the original issue: > I observe my problem of auto-changing near/far planes when I modify the > LODScale via "camera->setLODScale(float)". This *always* happens whether > or not culling is enabled, but of course I am not affected by this problem > when culling is disabled because no matter what values my near/far planes > have, my objects do not get culled. I enable culling via: > camera->setCullingMode(getCurrent() | osg::CullSttings::near | > osg::cullS::far) - I don't have the code in front of me but that is the > idea. The problem I encounter is that since I am culling the near/far > planes, some objects get culled from my scene if the near/far planes shift > positions automatically. Robert already explained that with my current > near/far computing settings I will get some slight changes to the near/far > planes when changing the LODScale. Although this is undesirable for my > application, it makes sense given Robert's earlier explanation. So Paul > asks, what if I just keep the original culling mode? Well, that would be > great, it looks great and I don't have the culling problem of the changing > near/far planes, but there is one *crucial* issue: frame-rate. My terrain > is too large and I need a decent level of detail, but it winds up drawing > way too many triangles. I am attempting to find the optimal LODScale for > my app, which can get me up from 10fps to about 25-30fps at a decent > LODScale, and I also want to cull all those extra triangles, which can > pump me up to 40-50 fps, at the cost of culling objects when not desired. > I think I'll be alright, I need to play some more with the near/far > compute settings. Thanks all for your interest in this topic, > > -Jose > > On Mon, September 22, 2008 10:52 am, Paul Martz wrote: >>> FYI, Roland is correct, the OSG just does culling on sides of >>> the frustum by default. >>> >>> OpenGL does no culling, is just does near and far *clipping*. The >>> OSG of course doesn't change this so will do near/far >>> clipping and the only way to switch this off is to disable >>> GL_DEPTH_TEST. >> >> Even that won't work; DEPTH_TEST is a fragment op, and clipping against >> the >> clip planes is done before rasterization. >> >>> It would seem that Paul and Gordon have confused the clipping >>> and culling a little. >> >> Yes, I thought the original poster was talking about enabling OpenGL >> near/far clipping (probably because I have seen so many newbies ask how to >> disable this in the OpenGL forums and newsgroups). Clearly, the original >> poster said "culling"... My mistake, and thanks to all for the >> clarification. >> >> Back to the original issue: >> >> So, you see this problem when you enable OSG culling for near/far. What >> happens if you leave this disabled (as osgviewer does)? >> -Paul >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
