Hi Chris -- I haven't read the whole thread, but if I understand
correctly, the intent is to enable a pseudoloader to wrap PagedLOD file
loads. I've given this some thought, and I recall a trick that we did
with osgTDS to support this in a non-invasive way.
osgTDS was an OSG pseudoloader plugin that would deform terrain. We
required that the application explicitly request to load this plugin, at
init time, as early as possible, so that it was essentially at the top
of the plugin queue.
This allowed the plugin to take advantage of a little-known fact about
how OSG plugins operate: Every time an app loads a file through the
Registry interface, the Registry goes through its queue of already
loaded plugins and lets each one take a crack at loading the file.
If osgTDS is at the top of the queue, it gets called to load a file
before any other plugins. But it's a pseudoloader, so it depends on
another plugin to do the actual loading. So it looks at the file
extension and gets the appropriate ReaderWriter from the Registry, and
uses it to actually load the file.
At that point, osgTDS would make a determination as to whether or not
the file contained terrain that it wanted to deform. If so, it would do
the deformation on the loaded data and return it, and otherwise it would
just return the loaded data.
I can give you more info on this technique if you'd like, either here or
offline.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
Chris 'Xenon' Hanson wrote:
Robert Osfield wrote:
My strong objection your suggested change is that it's a mod to the
core OSG for a very narrow type of usage, that not at all typical
usage. We can't just go bloating the core OSG because each users find
it's a little more convenient to implement their particular usage
model. One of the mantra's I follow is "Minimal and Complete", any
additions from the minimal really have to be justified. If we can
implement the functionality in a less intrusive way then this is the
right way to do it, not to pollute the core OSG with yet more API and
member variables and obscure cases.
I agree completely. However, I think that when you see what the terrain
modification
pseudoloader can do, you might agree that its usage is much less narrow than
you might
initially think. I feel it's as broadly applicable as VPB and osgTerrain are.
And when you
look at how it's used, PagedLOD itself mostly was created as a narrow-purpose
tool to
support terrain databases, though it does have some use outside of that
application.
More generally, pseudoloaders (like scale, translate, etc) are already
broadly useful.
However the overall pseudoloader technique (whether it be for terrain
modification or
something else) runs into a brick wall when faced by a PagedLOD or ProxyNode
entity,
because they manage their own loading of external files and are therefore
oblivious to the
pseudoloader suffix in play on the root-level node load. While the changes I
submitted are
required for my use of pseudoloaders for altering terrain, they really just
permit the
unified application of the existing pseudoloader technique to span across
PagedLOD and
ProxyNode classes.
I don't even personally need the capability for ProxyNode, but I completed
those changes
to make sure the feature was available universally and isometrically for others
to employ
if needed.
One goal behind this infrastructure is to facilitate some more of the
remaining items on
the VPB Development Plans list.
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
