Robert Osfield wrote:
> All that is a stake right now is whether we merge the ModifyTerrain
> plugin as is with the core OSG distribution.  My view is that it's too
> narrow a feature to warrant inclusion in to the core OSG, and a more
> general purpose solution would be appropriate for the core OSG.

  Ok. I'll have to accept your decision on that then. I felt otherwise, since 
I'm trying
to build a complete set of terrain-modification and terrain-related tools and 
release it
as I am permitted.

> If someone wants to put an crater into the terrain then this plugin
> wont' do it, they'd need to write their own
> Registry::ReadFileCallback/update NodeCallback/psuedo plugin.

  As-is, yes. The current modifyterrain plugin is mostly just a demonstration 
and
starting-point. I didn't want to hard-couple the modification mechanism to my
implementation of deformation tools, as users might wish to use a different 
deformation
toolset. As I said, I don't have the ok to release more than this yet, but I 
also can't
release more until the underlying foundation it is built on is solidly 
established.

> Everyone has their own specific needs, and the ModifyTerrain plugin
> just isn't general purpose enough for these needs.  It's OK for users
> to go extend the OSG themselves to do specialist work, we don't have
> to try and come up with all possibility and cover them in the core
> OSG.

  Ok. I'll try to find another mechanism for releasing this code to where 
people can
access it.

> The ReadFileCallback idea is just one of FIVE suggestions.  Personally
> I think the suggestion of using a osgDB::Option's attached to the
> PagedLOD would be the closest match to what you had already.

  I am investigating that, and I think your assessment is correct.

> For me these are two different issues, and neither has any sway over
> the other.  Both of the submissions were too problem specific, a route
> that is inappropriate for the OSG as they are both lead us down a path
> of ever expanding the OSG with problem specific code.
> I'm trying to
> keep the lid of the OSG code base, where possible see places where we
> can make the code base more flexibly and extensible while if possible
> shrinking the code base.  I can't achieve this is we keep merging code
> that takes us in the opposite direction.

  Ok. I'll respect that decision then.

> Robert.

-- 
Chris 'Xenon' Hanson, omo sanza lettere                  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to