model Improvements IV

I rather like Userdata file. Something like :

In myModel.usd
==============
myVertex = 1024;

In script
=========
// Assign the following action to myModel.mdl
entity* ent;
action modelact
{
ent = my;
vec_for_vertex(temp,ent,ent.myVertex);
}

The animation data being stored/loaded separately from the models is a very,very important improvement we need urgently(or at least to know it's coming for the full release).

The animation system needs to have this and the skinning done on the GPU too eventually, for A7 to remain competitive with the other indie engines out there.

I think adding these features or at least putting them on the roadmap, is especially relevant as high quality animation has been made an A7 Pro only feature, but as it stands currently you really won't be able to do Pro quality animation due to the lack of these elements.

I doubt the lack of that one feature (which isn't even needed) is going to take A7 out of the competition (i.e. remain competitive with the other engines out there). The engine has given them all a run for their money for years and will continue to do so.

@Orange Brat: Let's be clear about this, I totally agree the latest A6 is very good and A7 is looking great.

However, if you try to do anything with character animation of a Pro quality, (and remember we are only talking about A7 Pro here)these missing animation features are a big deal.

Without the separation of the animation data you will rapidly run out of memory if you try to have the number of animations needed for a typical modern game, as you can't share one set of animation data among multiple models. Ask Larry about animation space difficulties on the Mothers's Den demo for example.

That's why this method is already used by all the AAA engines and all the best indie engines too.

GPU skinning simply gives you a performance gain in most cases and frees up CPU cycles for other uses like better AI etc. which is why most modern engines give you the option to do it this way.

Please don't take my comments as knocking A7, these are simply positive suggestions for the future of the Pro version that are already the industry standard way of doing things, not some sort of crazy request .

@joey: here's a link to good explanation of GPU skinning if you want to understand what I'm talking about http://lynxengine.net/ati.htm

It's always interesting to learn which features are "needed urgently for Pro Quality" or even "used by all AAA engines" . Just some comments:

- "GPU skinning" is used for demos. In game engines the CPU needs access to the current mesh shape for tracing and polygonal collision detection.

- "Separate animation data" has nothing to do with "out of memory" or "AAA engines". It's used for easier assignment of bones animation in model editors. It has some advantages to load bones animation separately, but not for memory reasons. Animation matrices are very small and can't get you out of memory.

@Frank: FBX import is already released (up to 4 bones per vertex), so the future is now. And yeah it's a Pro only feature. Fortunately (or more like luckily), I was able to acquire a very cheap, legal A6 Pro off eBay ($300) and now have A7 Pro, so I'm all set for it when the time comes.

Not problem with memory or I am envious to the AAA engines but...

You gain a looooooot of time, or incluse a looooooooooooooooooot, not sorry a looooooooooooooooooooooooooooooooooooooooot of time, and this is the gamestudio "way of live".

@JCL:I would hope open intelligent discussion of ideas/suggestion for the engine would be welcomed here and treated with respect, not greeted with sarcastic remarks. Please let's keep this amicable and objective.

Please do not forget other people may also have real development experience too and might wish to use the engine and tools in ways you may not have thought of yet.

OK let's try looking at my request again and remember I'm only talking about for the Pro version:

1) Data separation should certainly be on the roadmap for Pro
a) 'Convenience' for animators as you put it earlier, is a huge understatement for the fact it would be extremely tedious for the animators not to have this when faced with any substantial animation work-load, they would certainly not a have a good work-flow without it as would have to re-export the animations multiple times for evey little tweak or change required. On a commercial project this would waste time and money you can ill afford.

b) Regular skeletal animations are tiny as you state, but special animations like kill moves, signature moves, destructions effects and cut-scenes etc.are all significantly larger and can very quickly add up to a real impact on the amount of data you have to load and store. This is also especially important if you want to target lower spec machines or consoles with the same animation data.

Even if you only agree with the lack of it affecting the animators work-load adversely, that alone still means data separation is important enough to deserve be on the road map for Pro. The fact this method is used by Unreal, Source, Quake 4 and the Granny engine, confirms it as the industry standard. Most Indie engines work this way too for the same practical reasons.

2) I agree having the option of GPU skinning is certainly not needed immediately –I did say “eventually” in my original request, but to dismiss it as something only for demos is simply incorrect. GPU skinning is already provided in or is currently being added to; Unreal, Source, Quake 4, and even Ogre. Again that list of AAA engines by definition means it is already an industry standard. A full-blown game such as Quake 4 is clearly not just a demo.

DX10 has been designed with it in mind too. It is definitely the future. Yes it doesn’t suit all circumstances, but is often the preferred method currently and will increasingly be so as GPUs keep on getting more powerful.

Just to clarify when I post on this forum I’m thinking something like “OK fully featured production ready A7 around Dec 2007 maybe, that means typically some time in 2009 before you would expect to release a completed project”. So please take my feature request seriously with that sort of lon-ger term thinking in mind –this is the future forum right?


REFERENCES:

ANIMATION DATA STORED SEPERATELY
Unreal http://udn.epicgames.com/Two/ActorXMaxTutorial.html
Source http://developer.valvesoftware.com/wiki/SMD_file_format
Quake IV http://www.iddevnet.com/quake4/Animations
Granny http://www.radgametools.com/granny.html
Dark Basic Pro http://darkbasicpro.thegamecreators.com/?f=enhanced_animations

GPU SKINNING OPTION SUPPORTED
Unreal 3 http://www.unrealtechnology.com/html/technology/ue30.shtml
Source http://www.productive.com/news/newsarticle.asp?searchid=15494
Quake IV http://www.iddevnet.com/quake4/Animations
OGRE http://www.ogre3d.org/index.php?option=com_content&task=view&id=373&Itemid=2
Blade3D http://www.devmaster.net/engines/engine_details.php?id=413
Vatan planning to add.
Visual3D.Net http://www.visual3d.net/Features/tabid/55/Default.aspx
Unity planning to add.

Good article explaining what GPU skinning is and why it’s prevalent in the industry nowadays. http://www.gamasutra.com/features/20070418/paanakker_pfv.htm

Good discussion on Devmaster on the pros and cons of CPU versus GPU skinning with a definite consensus for doing it on the GPU. http://www.devmaster.net/forums/showthread.php?t=4542

OrangeBrat: You can import but not edit up to 4 bones per vertex.

Yes, but I was addressing your comment that more than 4 bones per vertex was in 3DGS Pro's future. It isn't an experimental or beta feature anymore, it's an official one. It's true that you can't edit these bones in MED nor will the animation editor display them, but you didn't' mention that. Hopefully, this will change in a future update. However, most people aren't going to use MED to edit their FBX files anyway, so it doesn't really matter.

fragMotion will support FBX soon and up to 4 per vertex, and fragmo is aware of the recent changes and the upgrade to A7. The creators of Ultimate Unwrap 3D are also aware of the new MDL7 SDK and FBX support, too.