> well, wouldn't this lead to huge datas saved in the j3f (btw i found nothing
> about j3f on the web - where can i get some informaation about ..?)
> because you save the objects arrays - or at least the vertex and normal
> arrays of it - for every "KeyFrame" in the file for morphing form one to
> one...
Yes, it would be quite huge, and puts strain on artists, the artists will
have to create as efficient animations as they can, using as little keyframes
as possible. Its kind of a pain. But it also depends, for example, if your
end user will have a slow computer, computationaly morph targets are faster,
while skinned animations take quite a bit of calculations to achieve. If you
plan to distribute on the web, you may come across situations where that you
have such a wide audience that they all might not have fast computers, or
they might not all have fast connections, so its really a bit of a trade off.
It also depends on the kind of games you are making, if the software requires
a lot of character animation then skinned animations would be better. Also
there are diffrent forms of skinned animations, the high performance ones
will have inaccurate lighting or no lighting at all, the slow ones will
recalculate normals every time the mesh is recalculated.
I'm not sure why the Java3D team is hold off of doing it, I can only guess
that its to do with how to implement it in a way that would take advantage of
hardware accelerated skinned animations that a number of video cards support
today, or maybe its the architecture of Java3D, like for example how does the
mesh know when to update, every frame or should it be told to update by a
behavior (this is how I envision it), will TransformGroups be bones or will
bones inherit from them so that you can attach objects to it. Maybe they are
waiting for someone else to do it to get ideas, I dont know. I was
considering doing it, but right now I am working on a project to show off at
E3, and my dead line is tight, my business is slowly going under at the same
time :p, so I have a lot to do.
> so, my idea - will be testing that next time - is to save model data once in
> the file + the animation data like rotations for a group of vertices of the
> mesh, then calculate the vertex- and normalarray for the next KexFrame "on
> the fly" and morph to it (of course now looping that)
You might want to also consider not doing it on the fly, but also testing it
by calculating by extracting morphs from an animation file (searching for key
frames, and then turning those key frames into morph targets). Ive thought
about this as well.
> the only problem, is to get this - e.g. the skeletal animation - mixed up
> with a face animation for talking, because therefore the i need the
> vertices/normals of all the KeyFrames..
Oh, yeah, that is definetly an issue, that I fortunetly enough do not have to
deal with or plan to deal with in my current project.
The j3f format is being used in the Sun Java3D Fly Through Application...
http://developer.java.sun.com/developer/earlyAccess/java3D/flythrough.html
Leyland Needham
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
