Just a little interjection here...

Joe Kiniry wrote:

>
>
> As you might imagine, we believe that motion capture is appropriate for
> some game elements in the future (pre-scripted cut-scenes, complex moves
> like a multi-combo motion or similar), but are strong adherents to the
> believe that pre-scripted motion in gaming is going to become a thing of
> the past very soon now.

Since MoCap was developed there has been argument over it's appropriate
animation use vs. artist animations, kinematics systems, and procedural
animation, as you are implementing.

I can say definitely, that in the game industry, MoCap is here to stay,
AND quickly replacing other types of animations data generation systems.
  We are in contact with several game companies, and any next-gen title
they are developing is making heavy use of MoCap.

Why?  For several reasons...

1) The data playback systems are the same as for tradition animation
data.  But,  the MoCap almost always looks better!  The fact is, the
human body has incredibly subtle motions that only the very best
animators can nail down.  And not everyone can get the best animators...

2) Data generation rate, is often (but not always) much quicker for
MoCap.  When you need 5 different ways to catch a football, MoCap is
where it's at.

3) Run-time playback is less computationally intensive.  It is very
simple to playback animations, and with modern game animation systems,
the system can have hundreds of motion components mixing and blending
together to create fluid transition between jumping, running, falling,
climbing, and still be run-time cheap.  Procedural animations are very
expensive operations.  As cool as they are to figure out and program,
they are still too computationally intensive at run-time.  They need
collision feedback systems, kinematics systems, and often solid physics.
  Now, one might say that in the near future this won't matter.  And
it's true that the extra processing power creeping into game system is
allowing for physics engines to appear more and more in certain types of
games.  However, to correctly simulation the human body as well as MoCap
can playback is unlikely for a long time.  I imagine a hybrid system
where MoCap is used to get going but the physics engine is modify the
animation based on live game environment data... :-)


> Our next addition is to add the generation of textures using various
> genetic algorithms based upon the digitial genomes that are part of every
> entities specification.  An entity's physical morphology is already
> represented thusly, thus if two "close" species mate you get a new entity
> that resembles the parents - with no modeling in Maya!

This sounds incredibly ambitious, I hope to see your demos someday.
Right now, it takes us a year to teach these 3D modeling skills to
students, and that's an accelerated program.

By the way, I am a big proponent for procedural modeling and animation.
  We actively use it for terrain generation and world interaction.  But
not for characters or vehicles.  This is a very tough problem, and
almost any solution we've seen only works for a very narrow class of
models.  I look forward to your efforts!

> Best,
> Joe Kiniry
> --
> Joseph R. Kiniry
> Chief Scientist
> DALi, Inc.
>
> --On Tuesday, December 12, 2000 02:30:36 PM -0500 Shawn Kendall
> <[EMAIL PROTECTED]> wrote:
>
>> We are using "Skin and Bones" using Java3D GeometryUpdate interface and
>> By-Ref geometry.  That means only the transforms are animated and the
>> geometry is transformed in the GeometryUpdater based on it's bones
>> transforms.
>>
>> The animation's data is procedural and keyframe based using
>> interpolators (ours not Java3D) and animation data files.  The
>> animations are built in Maya.  The models and built in Creator and Maya
>> and import using our OpenFLT loader.
>>
>> As far as motion capture, for gaming that is the way to go.  But Java
>> doesn't need to know anything about where the animation data came from.
>> The motion capture data is processed (mapped, cleaned up. etc.) in
>> Maya and then output to the same animation file used for "regular"
>> animations, which is the position and rotational keyframes.
>> Hope that helps.
>
>
> ===========================================================================
> 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".


--
___________________________________________________________

Shawn Kendall               Full Sail Real World Education
Course Director             3300 University BLVD
Real Time 3D for Gaming     Winter Park FL 32792
[EMAIL PROTECTED]       http://www.fullsail.com
___________________________________________________________

===========================================================================
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".

Reply via email to