--On Wednesday, December 13, 2000 02:18:04 PM -0500 Shawn Kendall
<[EMAIL PROTECTED]> wrote:
> 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.
We, too, have interaction with many game companies, and you are right,
motion capture is here to stay. We don't propose replacing those
circumstances where motion capture is appropriate, as I mentioned above, we
propose supplementing the standard motion capture or hand-animated creation
cycle that exists with a third possibility, that of genetically engineered
digital organisms.
> 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.
No arguments with points 1 and 2, they are the reasons motion capture is so
popular today.
> 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... :-)
On a related note, the argument of too computationally expensive and far
too algorithmically difficult is something we have heard from many
folks/customers (until they see our work, that is).
I've found that anytime I try to push the state-of-the-art I hear similar
criticism. Let's just say that, with sufficient use of grey matter, such
issues are resolvable. We don't fob off the problem by claiming the need
for a Pentium 5 or the graphics cards of three years away.
Our baseline system is a Pentium II 350 and a Voodoo 3 - the machine of
1999. And to tell the truth, our current limiting factor is Java3D, not
our physics system, not our artificial intelligence, not our artificial
life, not our asynchronous networking, etc. Note that *all* of our
technology is implemented in Java.
Your mention of a hybrid system is entirely within our world-view as well.
>> 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.
This is *exactly* one of the main points of our technology. Let's say you
are building the next greatest massive multiplayer online experience.
Online consumer growth has continued unabated and you expect to see around
a half-million concurrent users.
(1) You need to create a playground (so to speak) big enough for those 1/2
million individuals. Using current manual methodologies building such a
world would take dozens (if not hundreds) of people months or years of work
and it is likely the world would be incredibly repetitious and generic.
Witness the effort that goes into static world creation in a game like
EverQuest or Asheron's Call and consider their size - several orders of
magnitude below what I'm talking about.
(2) You need to populate this playground with interactive experiences and
entities. With current manual methods you need to hand-animate and
hand-program ever single distinct entity in the universe. This typically
means (as Shawn implicitly mentioned) a (very) large team of experienced
modelers, animators, artists, and programmers working many months (often
years). Today's experiences typically end up having only a couple of dozen
distinct entity types, retextured and resized a few times to seem like a
hundred. Fundamentally though, you are constrained again by your capital
investment and how that directly translates into hires, training, tools,
and manual construction of assets.
(3) I won't go into the networking/distributed system scaling problems
inherent in the above scenario. This is part of our work as well, but not
relevent to this discussion.
Instead, we provide the tools so that much less experienced individuals can
create amazing complex, self-aware entities with little to no programming.
Couple that with the fact that the resulting experience is amazingly more
compelling in that the user isn't watching the same animation over and over
again for months, camping on spawn spots, and knows every simple behavior
exhibited by every entity in the world (i.e. run towards character, attack
until wounded, run away and repeat).
> 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!
Any interested in hearing more about our work should sign up for our
mailing list. Our technology demo which includes nearly all of what I've
described (in terms of key technology) is going into beta testing in less
than 3 weeks. See http://www.dalilab.com/mailinglist.html for more
information.
Best,
Joe Kiniry
--
Joseph R. Kiniry
Chief Scientist
DALi, Inc.
===========================================================================
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".
