Hi John
Probably the easiest way for me to resolve the dirty not effecting all
tiles is to try it out at my end. Could you submit your changes for
the vertical scale to osg-submissions, then I can review it, merge in
appropriate, make changes if required, then I can then easily recreate
the vertical scale adjustment via a tweak to osgmultitexturecontrol
example.
Robert.
On Fri, May 23, 2008 at 10:53 AM, John Vidar Larring
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
>> GeometryTechnique right now looks for the enclose
>> osgTerrain::Terrain's SampleRatio, and
>> very easily could read a VerticalExageration parameter as well.
>
> I have now implemented the vertical scale property in osgTerrain::Terrain as
> you suggested and it works great if only set once while creating the scene
> graph:
>
> osgTerrain::Terrain* terrain =
> findTopMostNodeOfType<osgTerrain::Terrain>(model.get());
> if (!terrain)
> {
> terrain = new osgTerrain::Terrain;
> terrain->addChild(model.get());
> terrain->setVerticalScale(2.0f);
> model = terrain;
> }
> viewerWindow->setSceneData(model.get());
>
> Hence, vertical scale can be set in the config file of the application.
>
>> There isn't an automatic dirty of the GeometryTechnique of the
>> TerrainTiles underneath a Terrain, but this is something I've though
>> about adding - this would be required to make sure new values of
>> SampleRatio and VerticalExegeration can passed on.
>
> I've tried to complete the implementation of this feature as well, but only
> with partial success. There is already _dirty bit available in
> TerrainTechnique what I've done is to implement the following methods:
>
> include/osgTerrain/Terrain:
> ...
> void setVerticalScale(float scale)
> {
> _verticalScale = scale;
> makeRegisteredTilesDirty();
> }
> ...
>
> src/osgTerrain/Terrain.cpp:
> ...
> void Terrain::makeRegisteredTilesDirty()
> {
> OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
>
> for(TerrainTileSet::iterator itr = _terrainTileSet.begin();
> itr != _terrainTileSet.end();
> ++itr)
> {
> TerrainTechnique* tt =
> const_cast<TerrainTile*>(*itr)->getTerrainTechnique();
> if(tt)
> {
> tt->dirty();
>
> // Force recreation of Geometry
> // const_cast<TerrainTile*>(*itr)->init();
> }
> }
> }
> ...
>
> When changing vertical scale while the test program is running, new (i.e.
> not previously viewed) tiles get the new scale value while the old tiles
> retain the old scale. This puzzles me a bit since:
>
> 1) TerrainTile::traverse() calls virtual TerrainTechnique::traverse()
> 2) GeometryTechnique::traverse() calls method TerrainTile::init() if dirty.
> 3) TerrainTile::init() calls virtual TerrainTechnique::init() if
> TerrainTechnique is dirty().
> 4) GeometryTechnique::init() re-generated the geometry without furter ado.
>
> What I don't understand is why not all tiles are regenerated (old and new)?
> Furthermore, if I uncomment the line after "Force recreation of Geometry",
> then all tiles are recreated, but it feels like a temporary freeze of the
> application because of the mutex lock used in the method.
>
> I reckon that there is something basic to OSG that I have totally ignored /
> overlooked. I hope someone will care to enlighten me:) Thanks in advance,
> and apologies for the length post.
>
> Best regards,
> John Larring
>
>
> Robert Osfield wrote:
>>
>> I'd recommend placing a VerticalScale into the osgTerrain::Terrain, to
>> sit alongside the
>> existing SampleRatio parameter. The osgmultitexturecontrol example
>> shows adjustment
>> of SampleRatio in action.
>>
>> GeometryTechnique right now looks for the enclose
>> osgTerrain::Terrain's SampleRatio, and
>> very easily could read a VerticalExageration parameter as well. There
>> isn't an automatic
>> dirty of the GeometryTechnique of the TerrainTiles underneath a
>> Terrain, but this is something
>> I've though about adding - this would be required to make sure new
>> values of SampleRatio
>> and VerticalExegeration can passed on.
>>
>> The reasons to go the route of placing the controls into
>> osgTerrain::Terrain is that it you can
>> control the central parameters for the whole terrain at one time, and
>> it can be used with other
>> TerrainTechnique beyond the current GeometryTechnique (this is
>> currently hardwired in to
>> VPB generated --terrain databases but this itself will eventually move
>> as a configuration parameter
>> of the Terrain itself just like SampleRatio.)
>>
>> Robert.
>> _______________________________________________
>> osg-users mailing list
>> osg-users@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.
>
> _______________________________________________
> 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
