Hi Carlo,
Carlo Orru wrote:
> Hi Carsten,
>
> As you already know I'm working on an OpenSG based animation framework,
> and so far every tested part seems to work.
Sounds good! Looking forward to seeing it in action! :)
> Now I'm trying to implement some methods in order to save (load) the
> whole animation to (from) an OSB file, and the basic idea is to store
> the control points list inside an Attachment (hosted by the field
> container whose fields are to be interpolated).
OK.
> I thus created a new FieldContainer (using the fcdEdit.exe tool) which
> is derived from 'Attachment' and has among its fields a
> MFFieldContainerPtr: such field is used to store the control points,
> each one in form of FieldContainerPtr.
>
> To save to/load from an OSB file, the idea is to create a new object
> that inherits SceneFileHandler and overrides its read()/write()'
> methods. Such new object's behavior would be the following:
>
> - write() method:
> Before saving the scene to a file, the control point lists
> are attached to the proper field containers. Then the file
> is written via the
> 'SceneFileHandler::the().write(rootNode, fileName)' method.
Is there a reason not to keep them in the graph at all times?
> - read() method:
> In order to import a scene from an OSB file, the
> 'SceneFileHandler::the().read(fileName)' method is used at
> first to populate the graph, then the idea is to perform a
> 'traverse()' operation to find out which field container
> has an attached control point list. If an attached control
> point list is found, it is then passed to the
> AnimationController object (together with the corresponding
> field container).
>
> Another possible approach could be modifying the SceneFileHandler's
> write() and read() methods to add such functionality directly to OpenSG.
I would probably make it simpler by just loading the files normally and have
the
app populate the AnimationController explicitly. The app needs to know about it
anyway to run the animations, so the initialization shouldn't be a big deal.
> Now I have a couple of questions for you:
>
> 1 - What do you think of such ideas ?
> 2 - Could they be improved in any way ?
> 3 - How challenging do you think it would be to
> integrate my animation framework into OpenSG ?
I'm not a big fan of hard-changing core functionality. We could come up with a
way to have pre/post-read/write callbacks that can be registered with the SFH.
But I think the app still needs to know about the Animation anyway, so making
the app init the controller sounds simple enough, IMHO.
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
