--------------- MESSAGE cgaa.v001.n484.1 --------------- From: Jeff Lander Subject: Re: CGA: Re: Cool 3D Realtime Characters... Date: Tue, 23 Sep 1997 10:51:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199709221756.KAA18521@lists1.best.com> <199709231536.IAA21132@list s1.best.com> I cc'd Brian Hook on this since his opinion and knowledge may greatly differ from mine. If he is not already swamped, perhaps he can shed more insight. Brian, this is a thread I started on the CGA maillist about hot real-time character animation. Matt Small wrote: > You know, the thing I don't understand about realtime deformations is the > suggestion I've read recently that you can somehow use them to store and > render MORE complex polygonal characters -- implying that the technique > actually eases the burden on the CPU somehow. > > I'm not talking about Messia; Shiny's using some kind of technology for it > that drops or merges unnecessary polygons, which is totally different. I'm > talking about games like Half-Life, which uses a modified Quake engine but > the developers claim that their proprietary rt skeletal mesh deformations > allow them to stick characters with 1000+ polygons each into the game. I haven't read about this but it smacks of marketing hype. First off, the benefit of using skeletal deformation on enemy characters seems to me to be limited. The only need for skeletal deformation is if you want to create unique poses on the fly. For enemies, you would normally be very sure of all the actions they could perform. It makes the most sense to pre-calc any animation poses and then interpolate between them for smooth animation. Quake (wisely I think) chose to use pre-calculated single mesh characters. Both because they are very fast and IMO look better than object hierarchies. The only reason I could see using a skeletal system for a Boss character that really responds to your position via some IK solver. But, no one is doing that in games that I know of yet :). In a third person character game where the lead character is key and you want a lot of dynamic motion, a skeletal system makes more sense. > It makes sense to me that you could store animation data for more complex > models using real time bones and skinning, since you only need to store > data for the bones. But how does this translate into more polygons/sec > from a rendering perspectvie? Or doesn't it? There is no way that a dynamic deformation system is faster than a pre-calced one. You have to consider that deformation involves calculating percentage of weight between each bone per vertex. This is fairly expensive and should only be used for key characters who really need it. The PR people for Half-life may be using the "skinning" to do level of detail stuff. That would give you a performance gain as you can have very low poly counts when characters are far away. This has nothing to do with deformations though. You can do LOD work with static character meshes also. I believe Quake had at least one real lo-res LOD working but I am unsure if it made it in Quake. I could be wrong but tend to be very skeptical of magazine articles. I think of them as advertising. Jeff -- Jeff Lander Darwin3D jeffl@darwin3d.com http://www.darwin3d.com/jeffl Custom Realtime 3D Programming, Design, and Creation --------------- MESSAGE cgaa.v001.n484.5 --------------- From: David Bennett Subject: Re: CGA: RE: Cool 3D Realtime Characters... Date: Wed, 24 Sep 1997 13:30:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <199709221756.KAA18521@lists1.best.com> With respect to what John Lander said about 3D characters: >Shiny has probably patented it though they haven't showed it (cheap shot I know). Are computer graphics artists & designers responsible for determining whether the rt3d techniques they develop violate some patent? I wonder how difficult it will be to enforce patent law in this arena. Many game designers and engineers are quite secretive about their proprietary techniques while the computer graphics community as a whole is still very open and academic. If you saw a game I created and suspected me of violating your patent, how would you verify this? Could I not in any event point to tens of papers or theses in academic journals about similar techniques to show that my design belongs in the public domain? Should we all be going through our notebooks and applying for patents? Or mailing these notebooks to ourselves via registered mail? --------------- END cgaa.v001.n484 --------------- --------------- MESSAGE cgaa.v001.n485.8 --------------- From: Paul Atkinson Subject: Re:Cool 3D Realtime Characters Date: Thu, 25 Sep 1997 10:23:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Continuing the discussion on realtime skeletal deformations, I thought I'd stick my nose in. We are currently mid way through developement of a N64 'mario' type game. Every one of the 50 or so 3d characters within the game use skeletal deformation. I'll list a few of the pro's and cons we've come across. We can store a characters mesh (600+ polys), plus all of its animation, typically 3-400 frames in about 30k using skeletal deformation (before any compression). If you compare this to pre-calculated single mesh frames you're talking mb's of data. We can use one character's anim for other characters (providing they share the same skeletal heirarchy) Likewise we can substitute a character's model, made from 100 to 600 poly's depending on the level of detail required. We can collapse the skeleton joint nodes. You want the character to explode or his legs to run off? You got it! Modifying the character's geometry is done only on one 'master' model, posed in a control position. Imagine modifying every frame!! One restriction we've found is that animating textures have to be handled carefully. Using pre-calculated meshes we could have animated the textures on a per frame per model basis. We have to control these animated textures with code. Scaling the skeletons on the fly is out. I don't know why, but they said NO! (programmer's eh?) I hope this clears some of the questions up. We've found that the main benefit for using of rt skeletal deformations is space. With the N64 or for that matter any other console, memory is very limited. Just incase you were wondering, we use Alias PowerAnimator, and export to PC, N64 and PSX with a custom plugin. (one magic button that does it all.) Paul Atkinson --------------- END cgaa.v001.n485 --------------- --------------- MESSAGE cgaa.v001.n486.9 --------------- From: Jeff Lander Subject: Re: CGA: Re:Cool 3D Realtime Characters Date: Thu, 25 Sep 1997 18:51:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199709251533.IAA02521@lists1.best.com> Paul Atkinson wrote: > We can use one character's anim for other characters (providing they > share the same skeletal heirarchy) Likewise we can substitute a > character's model, made from 100 to 600 poly's depending on the level of > detail required. That sounds pretty cool. Interesting reason to use deformation, space savings. Can you say anything about your weighting? With 50 characters, calculating the weights would take a significant amount of time. I have found that calc'ing the weight between two bones is not so bad but many more is a killer. This is especially true on the PSX (and I imagine the N64) as the CPU are fairly weak. Several companies I know tried full mesh deformation and had to dump it cause it was too slow. > Scaling the skeletons on the fly is out. I don't know why, but they > said NO! (programmer's eh?) It is generally very tough to scale the whole skeleton without fixing the initial root position. If you scale the legs, the feet will penetrate the floor. But scaling the arms and head within limits works great. If you get too extreme, the arms may pass through the body, walls, etc. But who cares, it looks cool. I like to put giant heads and hands on characters. Picture "Big Head" quake. Two other questions. Did you use motion capture? If so, did you use one of the hierarchical format like BVH or Acclaim. Do you ever create unique motions on the fly? That is the major benefit of a deformable character. Also, the main reason I think it is pretty overkill for most projects. Jeff -- Jeff Lander Darwin3D jeff@darwin3d.com http://www.darwin3d.com Custom Realtime 3D Programming, Design, and Creation --------------- END cgaa.v001.n486 --------------- --------------- MESSAGE cgaa.v001.n488.7 --------------- From: Ken Robertson Subject: Re: CGA: Polycount's in the house! Date: Fri, 26 Sep 1997 15:18:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199709261550.IAA13133@lists1.best.com> <199709261733.KAA24701@list s1.best.com> Without doing too much of a shameless promotion, I wrote a chapter for "Inside Max vol II" that deals specifically with real-time game modelling, covering a couple of techniques and their benefits depending on whether you are creating for BSP or z-buffered engines. I also cover real-time mapping techniques, and the programmtic principles / concepts behind real-time game engines, which can be very useful when beginning to model, so you don't construct yourself into a corner. I would be interested to hear any feedback on this chapter from any and all interested parties, as I do teach Max in the Bay area, and would love to hear any other variations or principles from my fellow "list-ees" that I may not have touched on. Thanks in advance! Ken Robertson Asst Art Director 3D Artist \ Animator Gametek Inc. --------------- END cgaa.v001.n488 --------------- --------------- MESSAGE cgaa.v001.n491.1 --------------- From: Paul Atkinson Subject: Re: Cool 3DRT Characters Date: Mon, 29 Sep 1997 09:50:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199709261550.IAA13124@lists1.best.com> Jeff Lander wrote: > Can you say anything about your weighting? With 50 characters, > calculating the weights would take a significant amount of time. > I have found that calc'ing the weight between two bones is > not so bad but many more is a killer. This is especially true > on the PSX (and I imagine the N64) as the CPU are fairly weak. > Several companies I know tried full mesh deformation and had to > dump it cause it was too slow. > We tried using weighting, but came pretty much to the same conclusion. It's too slow. We have to assume that each joint/bone has 100% influence on it's vertex clusters. It's not too bad, but it does sort of dictate how we arrange the poly's around a joint, ie, very carefully! *sigh* > > > Did you use motion capture? If so, did you use one of the hierarchical > format like BVH or Acclaim. We tried a few sample HTR files, great fun, but too restrictive. (and costly!) We decided that the IK tools in PA would let us do what we needed, besides, toon's can get away with murder... > > > Do you ever create unique motions on the fly? That is the major > benefit of a deformable character. Also, the main reason I think > it is pretty overkill for most projects. This stuff is in the pipeline. Once it's been coded, we'll be able to take all of the animation loops and break them down into their individual branches, eg, we could have loads of different (but similar) walks, and randomly mix left and right leg anims to increase the variations. It'll be a way of controlling each limb independently, but it's not really unique motions. We thought about letting the programmer's hard code some actions, but really, would you let them do that to your character? *grins* Paul Atkinson Patk@curved-logic.com www.curved-logic.com --------------- END cgaa.v001.n491 --------------- --------------- MESSAGE cgaa.v001.n499.1 --------------- From: Jeff Lander Subject: Re: CGA: Date: Tue, 07 Oct 1997 09:38:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199710070527.WAA28180@lists1.best.com> Don, Great post. I really like Animation Master also. I never found a way to work with it for Real-time gaming, though. I mean, splines are cool but until hardware supports them, it is a poly world. They really need a better way of getting meshes and animation data out than DXF. Press them to create an SDK or at least better export options. I think it could be a great real-time tool. Especially for the price. There is a lot of hype around dynamic tesselation right now and Hash creates very cool organic sets that are perfect for that technique. I never got over that "Flinstones" style world on the demo disc. Very cool. > A few people have been talkin about RT skeletal deformation. I've been > checking it out. No weighting of vertices though, and from an esthetic or > artists point of view it's not worth it until weighting happens! From other > vantage points though it could be quite a boon. This is really happening now. Several game companies are working on this. So far everyone with released products are just weighting the vertices 100% to a bone. But 50/50 is pretty easy and the extension to full weighting is not much more work. Sure the CPU load is a pain, but you wouldn't use it for much more than the lead character anyway. I am writing a Gamasutra article that covers mesh weighting right now. Should be finished in a few days. Later. -- Jeff Lander Darwin3D jeffl@darwin3d.com http://www.darwin3d.com/jeffl Custom Realtime 3D Programming, Design, and Creation --------------- END cgaa.v001.n499 --------------- --------------- MESSAGE cgaa.v001.n516.2 --------------- From: Jeremy Dale Subject: Die by the Sword... Animation/MoCap/Procedural/what? Date: Wed, 22 Oct 1997 13:37:24 -0700 MIME-Version: 1.0 Content-Type: text/plain Hey, this may seem like a dumb question, and almost something that could be addressed on CG-Char, but i thought i'd ask here first as this is a Game list. What's the deal with Die by the Sword (and Tomb Raider for that matter) as far as their using "a physics model for animation instead of motion capture". What's this all about? For starters i find it amusing that apparently there's only two kinds of animation (MoCap and Physics). So did they keyframe the animation and just script the stuff to fit the physics model, or is everything derived from code and DOFs or what? The whole reason i'm asking is because of some stuff NextGen wrote regarding it, say on page 41 of issue 35: "...The game's control scheme may effectively mark the beginning of the end for canned motion captured sequences in action games. They simply cannot provide the variety of motions needed for realtime, unscripted, sword-to-sword combat." So i went back and read the Alpha of it on p. 94 (or so) of issue 33, and got the quote from the second paragraph about physics model animation. Anybody have the scoop? jerOme ----- JEREMY DALE -_ValleyDweller ProductionShack_- jerOme@valleydweller.com http://www.valleydweller.com "If you can look at anything you do and be satisfied with it, you are in the wrong trade." -Chuck Jones --------------- MESSAGE cgaa.v001.n516.3 --------------- From: Jeff Lander Subject: Re: CGA: Die by the Sword... Animation/MoCap/Procedural/what? Date: Wed, 22 Oct 1997 18:30:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199710222038.NAA09242@lists1.best.com> Jeremy Dale wrote: > > Hey, > this may seem like a dumb question, and almost > something that could be addressed on CG-Char, but > i thought i'd ask here first as this is a Game list. > > What's the deal with Die by the Sword (and Tomb Raider > for that matter) as far as their using "a physics model > for animation instead of motion capture". What's this > all about? For starters i find it amusing that apparently > there's only two kinds of animation (MoCap and Physics). > > So did they keyframe the animation and just script the stuff > to fit the physics model, or is everything derived from code > and DOFs or what? > > The whole reason i'm asking is because of some stuff > NextGen wrote regarding it, say on page 41 of issue 35: > "...The game's control scheme may effectively mark > the beginning of the end for canned motion captured > sequences in action games. They simply cannot provide > the variety of motions needed for realtime, unscripted, > sword-to-sword combat." > > So i went back and read the Alpha of it on p. 94 (or so) > of issue 33, and got the quote from the second paragraph > about physics model animation. > > Anybody have the scoop? > > jerOme They use a little motion creation tool to allow designers to create there own unique moves. It is a sort of "dumb" FK animation system. "Dumb" in that it is restricted from a full FK system by making it easy to use for the novice. They have dials and settings for the various actions and you can combine them to make a unique attack. Sort of build your own combo move. Pretty cool concept. Most of the "physics" model stuff I have seen described are mainly limits to the DOF for the joints. There seems to by interpolation between move settings to make it smooth. The actual physics is more of the gravity/force of flying body parts. Not any real character dynamics or inverse kinematics. That title has been around for a while. I saw a crude tech demo over a year ago and was not too impressed. The screenshots now look much better. Tomb raider is strictly a hand animated hierarchical object system. The only twist I see in that is the pseudo-IK of the "aim gun at the enemy". Of course these are just my observations from the outside so take them for that. But it sure seems character animation is getting hot in the 3rd and 1st person 3D games. Jeff -- Jeff Lander Darwin3D jeffl@darwin3d.com http://www.darwin3d.com/jeffl Custom Realtime 3D Programming, Design, and Creation --------------- END cgaa.v001.n516 ---------------