Hi Chris, On Mon, Nov 23, 2009 at 6:15 PM, Chris 'Xenon' Hanson <[email protected]> wrote: > 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.
I still standby this advice, in terms of making terrain modification work without intrusive changes to the OSG or VPB it works. This doesn't change the fact it's a specialist plugin that has a very narrow feature. > 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. You don't actually need to rewirte anything if you don't want to, and you don't need to change anything for your client's app. You can maintain and distribute your plugin as you see fit, the plugin as it stands will still work regardless of what other plugins we might write in the future. 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. > 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. 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. 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. > 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. 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. > 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? 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. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
