Hi Robert,
> Could it be that I have compiled the OSG uses a release build and
> you've compiled debug, or not enabled the release build.
Due to debugging etc. I went blind to the fact that I was doing the
timing of the test application in debug mode. In release build the
updated after vertical scaling took approx 4-6 secs. which is
significantly less than 16 secs., however, a 1 second delay as you
report would definitely be preferable.
Best regards,
John
Robert Osfield wrote:
Hi John,
On Fri, May 30, 2008 at 10:24 AM, John Vidar Larring
<[EMAIL PROTECTED]> wrote:
Please excuse my ignorance, but osgdem produces pagedLOD databases per
default, doesn't it? At least, the top node of my terrain database start out
like this:
Yes by default VPB creates paged databases. You're ascii except
confirms that you have a paged database too, so... we need next to
look at why....
1 sec. vs. 16 sec. makes a big difference! OK, I am running my tests on a
laptop, but it has the following specs: Intel Duo T7300, GeForce 8600m GT
512MB, 2GB Memory, running CentOS 4.6 (a.k.a RHEL 4). So unless you've spent
a fortune on hardware, I don't think hardware differences alone can explain
the difference.
What could potentially contribute to this difference in update time. Any
ideas?
I have a Intel quad core 2.4GHz machine with 4GB of memory and a
7800GT. The update is done single threaded in this case so the extra
cores should make no difference.
Could it be that I have compiled the OSG uses a release build and
you've compiled debug, or not enabled the release build. If you run
ccmake . or cmake . for the first time instead of ./configure it'll
not enable the release build, so perhaps this has caught you out.
Unfortunately I haven't spotted a way of forcing cmake to default to
release build, so I wrote the ./configure script to enable the release
build. Have a look at the script it's just a one liner.
FYI, the thing that will be taking all the time in the generation will
be the display lists/texture object update. Making osgTerrain a bit
more intelligent about it's updates it would be possible to just
update the existing vertices and normals when changing the scale,
something that would be much cheaper. The dirty/update mechinism
would have to be alot more sophisticated though. Long term this is
where osgTerrain is heading, right now its very much in its infancy.
Thanks, this is very useful information. I'll see what I might figure out
when, and if, I get the time. But I'll certainly keep a watchful eye on any
VPB svn updates;)
The suggested changes to osgTerrain are unrelated to changes to VPB,
so it's osgTerrain itself you'll want to keep a watchful eye on in
addition to VPB which itself will have its own development path.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
