Hi John,
Perhaps a Terrain::init() or update() method would be appropriate -
one that goes through all the tiles registered with
the terrain and calls init() on them.
As for 16 seconds, this is looooooong time. I am only seeing around a
second of time update on a database
that is getting on 10TB in size, the trick is it's a paged database
and only what is loaded is updated.
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.
Robert.
On Wed, May 28, 2008 at 4:55 PM, John Vidar Larring
<[EMAIL PROTECTED]> wrote:
> Hi Robert et. al.,
>
> I've tested the new vertical scale implementation on osgTerrain::Terrain now
> and it works great, BUT...
>
> The typical osgTerrain databases we would operate on are >= 8GB in size
> (i.e. full gtopo30 + bluemarble 500m + selected areas in higher resolution).
> When altering vertical scale on such a database, we are talking of more than
> a few frame drops, the application becomes unresponsive for 16 sec++.
>
> Waiting several seconds is not a problem in itself for this interactive
> operation, as long as I can report to the user that the operation is in
> progress and when it is completed/finished. However, this is where I need
> some guidance from experts: How / what's the best way of collecting this
> information from OSG?
>
> If I add an explicit call to _viewer->updateTraversal() after
> _terrain->setVerticalScale(), then I know when the recalculation of the
> geometry if completed:
>
> case(osgGA::GUIEventAdapter::KEYDOWN):
> {
> if (ea.getKey()=='v')
> {
> _terrain->setVerticalScale(_terrain->getVerticalScale()*1.25);
> osg::notify(osg::NOTICE)<<"Vertical scale
> "<<_terrain->getVerticalScale()<<std::endl;
> _viewer->updateTraversal();
> osg::notify(osg::NOTICE)<<"Geometry is recalculated"<<std::endl;
> return true;
> }
> ...
>
> However, I suspect that much more elegant solutions are available;
> UpdateVistor callbacks maybe? If you point me in the right direction I'll
> try to implement it.
>
> For testing interactions like this on large models I have attached a new
> example program derived from osgmultitexturecontrol which in the future can
> be used to demonstrate how to give user feedback for operations that are not
> real-time (e.g. terrain->setVerticalScale())
>
> My test database based on gtopo30 and bluemarble can be downloaded from:
> ftp://ftp.weatherone.tv/private/jvl/osgTerrain_globe.tgz (3.1 GB)
>
> (This file will be removed before the weekend)
>
> Best regards,
> John
>
> Robert Osfield wrote:
>>
>> Hi John,
>>
>> On Tue, May 27, 2008 at 1:14 PM, Robert Osfield
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> I haven't tried changing the scale on a existing model yet, for this
>>> it might be worth adding an event handling into the
>>> osgmultitexturecontrol example that adjusts the sample ratio and
>>> vertical scale.
>>
>> I have now added an TerrainHandler to the osgmultitexturecontrol
>> example that increases
>> decreases the sample ratio and vertical scale of the Terrain in
>> response to 'r'/'R' and 'v'/'V'
>> key presses respectively.
>>
>> I have also reorganized the way the the TerrainTile dirty mechanism is
>> managed, this enables the dirty
>> to work on all tiles, with the init on the TerrainTile being called on
>> the next update traversal after changes to
>> the Terrain SampleRatio/VerticalScale have been made. You can a big
>> frame drop with this update so not
>> suitable for real-time work, but it's certainly viable for interactive
>> apps.
>>
>> Robert.
>> _______________________________________________
>> osg-submissions mailing list
>> [EMAIL PROTECTED]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-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
> 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
