Hi Robert,
Well... ok. This will require a bit of work and I'm currently in a hurry... :-\
But let's review!
First of all: agreed to make it work for all (images, shaders, potatoes...)
About features:
> 1) Enable writing out of images only once
> 2) Handling of paths that are absolute or relative.
> 3) Handles directory creation when paths don't just exist
Additionnal feature:
2.1) Also get the absolute path where it was written, as well as the path
relative to the "main file" (= the 3D model)
2.2) Also generate writing paths which may keep original directory structure
("_keepRelativePaths" member).
Ex: Reading model.osg, which has "images/img1.jpg".
Writing "/somePath/newmodel.osg" and "/somePath/images/img1.jpg"
Of course, with the option disabled, this may write
"/somePath/img1.jpg"
4) Duplicate handling: avoid writing two different images (or "things") at
the same place.
What should also be added:
5) Handling of naming constraints (such as "8.3" names in 3DS)
About "caching" values, yes that's true FOR NOW the write() comes just after.
So, I agree to merge setCurImage() and write() ("writeImage()", then?). But
this also makes getCurAbsolutePath() and getCurRelativeOrAbsolutePath() return
paths where image was written. So maybe the writeImage() should return a pair
of strings (or fill a structure)?
And finally, what about "WriterHelper" or "ExternalFileWriter"?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "Robert Osfield" <[email protected]> a écrit :
> Hi Sukender,
>
> I've just reviewed your PluginImageWriter submission, and come away
> unsure about it's role, design and implementation. I believe I
> understand the intention behind it but it just doesn't feel quite
> right, my gut instinct is that it's a bit awkward in both design,
> implementation and usage, not how I'd normally go about solving such
> a
> task. I'm easier about plugins not being so tight on design, but
> classes that make it into the public scope of core OSG libraries have
> justify their existance and approach more riguorously.
>
> I think it would be appropriate to distill down the intended
> functionality and then look to how we might achieve that. My reading
> of the requied features are:
>
> 1) Enable writing out of images only once
> 2) Handling of paths that are absolute or relative.
> 3) Handles directory creation when paths don't just exist
>
> Please chip in ones I've missed.
>
> I would also add implementation features such as using a design that
> avoid uneccessary state being cached, in the proposed implementation
> there is a PluginImageWriter::setCurrImage() and then a write()
> methods are coupled and with it have state that has to carried
> between
> the methods for them to work. In code that uses the
> PluginImageWriter
> the two methods are always coupled together, why not just use combine
> the two into one public write method that neatly avoids potential for
> misuse and the need for caching state. By avoiding unncessery state
> one leaves the door open to making such classes thread safe, as well
> as making them easier to use robustly.
>
> I also think that if find a name for the required class that is a bit
> more appropriate it'll be more natural to think about. Currently I
> feel that the name PluginImageWriter makes one think that the class
> is
> directly related to implementing plugins, while in implementation
> it's
> a generic class that could be used in plugins or in users application
> code.
>
> I do also wonder if being specific to images is probably
> unneccessary.
> The same issues of writing out out external data files applies to
> models as much as it does images.
>
> Robert.
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
