[osg-users] Operation progress report from OSG Interactive operations

[John Vidar Larring]

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
> <larring at weatherone.tv> 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
> osg-users at lists.openscenegraph.org
> 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.