Hi Toni,
sorry for the late response, the end of the semester is a little always crazy.
Antonio Bleile wrote:
> Hi,
>
> as we are collaborating with the local technical university
> and as we're offering some master thesis, we also proposed a
> thesis (with Dirk's authorization of course) that would resolve
> the animation issue in OpenSG, the title is "An Animation
> Framework for OpenSG". If there's time remaining, the solution
> also contains a plugin for 3ds and/or Blender that exports
> animations. The description of the thesis contains an
> explicit commitment to the Open Sourcness of the results and the
> collaboration within an international and distributet team of
> developers (that would be you!).
> We now found a young computer science student who is interested
> in this topic, and he's ready to go. But before taking off I've
> a couple of questions:
>
> - Do you have some concrete ideas on how an animation
> framework should look like in OpenSG? Are there any
> papers/references other SceneGraphs where to learn from?
None that I'm aware of, this is not really my topic. X3D has a basic concept
(Fields/Routes) that seems to work reasonably well, but it is very general and
goes beyond animation.
> - Where should he work on? In OpenSG 2.0 or OpenSG 1.8? I
> personally prefer 1.8 as I think we won't use 2.0 anytime
> soon.
I'm with Marcus on this one: if you can write it in a way to supports both or
can be ported easily. The mainly means use RefPtrs everywhere. :)
> - What about Collada? Collada contains animation description and
> as far as I know, a Collada reader will be available in 2.0 ?
Yes, but so far it doesn't have animation support (AFAIK). I looked into the
Collada animation and the basics seem interesting, so it might be a good start.
Definitely something to look into.
> - I need some help from you guys taking care that the result
> is satisfying for all of us (a kind of tutor/mentor). Any volunteer?
I'll be happy to have you bounce ideas off me, but my reaction times are a
little unpredictable these days (I'm swapping quite a bit). :-/
Here are some ideas/aspects:
What to animate? Given that OpenSG has a reflective interface, it would be nice
if any Field could be animated. That would a very nice and generic approach.
Which fields can be animated would depend on what kind of animation needs to be
done.
Some fields (like children) will probably only be able to switch between sets
of
values. This could be the minimum behavior.
Other fields (like Vectors) are interpolatable. There are different kinds of
interpolation, like None (see above), Linear, Quadratic, different Splines etc.
AFAIK (and don't quote me on this), as long as you have linear operations on
the
type all of those work. IMHO all animation should be time-based (more about
that
later), so I would use time as the input parameter.
Collada (and some animation packages) break everything down into 1D
interpolations. I can see the point to be able to draw it in a GUI, but in
general it seems not very intuitive to me, so I probably wouldn't do that.
Interesting cases are matrices and quaternions.
Interpolation matrices is possible but non-trivial (see Marc Alexa's SIGGRAPH
paper http://portal.acm.org/citation.cfm?id=566592), so I'm not sure if you
would want to support it. Just switching should be fine. ComponentTransform can
take care of that.
Quaternions need special interpolation. Most probably slerp, even though I
remember an article in Game Developer that advocated cheaper approximations for
animation.
Time is important, and I would separate the animation from the time objects, so
that it is possible to control and share time independently from the
animation(s). I'm also not a big fan of relative/incremental animations. IMHO
it's easier to simulate relative animation using an absolute system than the
other way around.
I also think it would be nice to have the option to have multiple independent
times, in addition to a default time, so you don't have to specify an explicit
time for everything. Which means there's going to be some animation master or
controller than keeps track of all animations and times, to make it easier to
advance the animation.
Do we need linked animations, i.e. the end of one animation triggers the next?
Might be useful, and would probably be fairly easy to do by making times in the
animation relative to a predecessor animation. I.e. there would be be a need
for
explicit triggering, it would just happen at a relative time.
How simple can it/does it have to be? Does anybody care about Performer-style
Sequences, i.e. simple nodes that automatically switch between their children?
I
could never come up with a convincing use case for that, so I'm ok with not
having trivial animation.
Special cases: characters/skinning and particles.
Characters are IMHO not an animation problem. They need new nodes for drawing
them in the graph, but thetual animation should use the normal
vector/quaternion
animation.
Particles are totally separate, as they don't just animate, there is a lot of
creation and simulation going on, so I would not tackle particles at first.
They
can use some parts of the animation framework, like the time, but they are
intrinsically different.
Just my $.02
Dirk
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
