Hi Robert,
thanks a lot for your feedback.
To provide with a bit more context, I am mainly working with osgconv to produce
optimized scenes for web rendering.
I've been refactoring some code from a fork that hopefully should go in osg
trunk. Part of my refactoring was to split a plugin that was doing some
specific optimization and serialization to a custom format into two separates
plugins since one might want to use this specific optimizer in other context
than the original one (e.g. this optimizer can split a geometry with indexed
primitives into geometries the constraint that all indices are < n; this was
useful for first version of webgl where indexed buffers where limited to 16bits
indices and I suppose this could be useful for other needs such as streaming of
a scene with "packets" of a fixed size).
The thing is that this optimization should be executed *after* the
osg::Optimizer to ensure that the index contraint is fullfilled (the
MERGE_GEOMETRY or MERGE_GEODES optimization flag could break this otherwise).
My workflow is:
load scene graph -> use specific pre-optimizers -> use osg::Optimizer -> use
specific post-optimizers -> write scene graph on disk
where specific pre/post-optimizers work "in memory" just before the data
actually reaches the filesystem and are triggered using "fake file extensions".
To illustrate it could be something like
OSG_OPTIMIZER="DEFAULT|MERGE_GEOMETRY|MERGE_GEODES" osgconv
input.obj.0,0,1.trans output.myformat.compress.gles
where
* gles will optimize the scene graph for web rendering ("pseudo-writer" that
modifies the scene graph in memory and returns a new root node)
* compress will alter buffers to reduce the final filesize ("pseudo-writer"
that modifies geometry buffers in memory that further modifies the scene graph
and return a new root node)
* myformat will actually write the data on disk in the wanted format without
doing anything more ("actual writer" that do not modify the graph).
So as the trans plugin alters the scene graph in memory *before* the
osg::Optimizer, I need to be able to alter it after.
In my mind the extension feels natural but I have some very specific needs so I
would totally understand if you really find this a bad idea. My workaround
works fine but I was just wondering if it would not be benefecial for everyone
to make it generic.
Regards,
Marc
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60289#60289
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org