Robert Osfield wrote: > My gut instinct is avoid "configurable" solutions like this, and go > for "programmable" ones in instead, much like fixed function pipeline > has been replaced by shaders down on the GPU, we should also take this > approach for tools like this. The real problem with configurable > solutions is that they only solve a specific problem, as soon as you > want to solve even a slightly different problem you have to write a > completely new pathway. In the case of OSG plugins it'll mean opening > to door to have to write and manage a whole range of pseudo plugins.
I sort of concur with your intent to encourage programmable solutions. However, if you recall from our skype chat this spring, the pseudoloader technique was your recommended solution for modifying VPB PagedLOD databases instead of adding a modification-plugin pathway directly into VPB itself. > With Jeremy Moles proposing use of Lua in osgWidget to provide > flexible control of event handling/callbacks perhaps we could take the > same approach here. Would it be possible to expose a set of > interfaces in Lua and then run a lua script to do the elevation > modification. Once would then provide the a lua script pseudo plugin > and a lua script to modify the terrain/do what you want. Such an > approach would also be re-usable beyond psuedo plugins - you could > invoke the script directly in your app. I'm a little adverse to this for three reasons. One, I can't introduce a new Lua dependency to my client's app. Two, I don't know how Lua's performance would impact the process. What I do know now is that the code path is all C++, with only a couple of virtual methods, so it performs pretty decently. And three, I've already written it without a Lua wrapper and am a bit hesitant to go back and redesign it to use Lua. > I've decided that the MODIFYTERRAIN plugin is just to problem specific > to warrant being included in the core OSG distribution. As it stands > I think adding it to VirtualPlanetBuilder would be more appropriate, > as doing this type of terrain database manipulator is more naturally > aligned to VPB than the core OSG distribution, which is really meant > to be a general purpose scene graph. Hmm. As far as the basic MODIFYTERRAIN (MT for short) pseudoloader itself -- you have to _have_ VPB built to build the terrain that MT modifies, so that's not a big issue. Though it does sort of put the "pseudoloader" into an out-of-the-way place where fewer people will be aware of it (or ever aware to look for it) and integrate its capabilities into their projects. However, most users' application don't actually LINK with VPB's libraries. I had intended that the core classes that make up the MT plugin be integrated into OSG itself (probably osgTerrain), where they would be available to typical user applications that wanted to modify VPB terrain on the fly. The underlying ModifyTerrain classes and code are capable of being run on a VPB-made scenegraph either during a load/save operation in a pseudoloader, OR at any runtime moment for dynamic terrain alteration. So, putting those classes into VPB's library and requiring linking apps to VPB would seem to be an excessively high barrier for people just wanting to add an explosion crater at runtime. Basically, none of my ModifyTerrain classes actually need any code from VPB's libraries, so putting them into VPB's library would seem to me to be a poor decision. I'm still trying to get my head wrapped around the new "custom ReadFileCallback" idea you proposed to surmount the PagedLOD suffix issue. I think I can probably make that work, though my build directory is quite disconnected from current the SVN due to the conflict of keeping my development going versus the state of the multitude of my submissions currently under review. If I can refactor the PagedLOD suffix situation to not require code changes to PagedLOD (and ProxyNode), would that sway your opinion on the generality/programmability versus configurability merits of MODIFYTERRAIN such that you'd be ok incorporating its core utility classes into osgTerrain and the actual pseudoloader into the core OSG SVN? -- 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
