Baking Animations (2)

[iamxsj]

Hi,

I am fairly new to the API, just picking up...while trying to write a plugin to kind of bake animations; as in convert all the animations into plain polygon and vertex information. We can later import the baked animation, and use it to for lighting and other purposes, rather than use the rigged models. I am kind of stuck figuring out a way to export the vertex+anim data. Here are a couple of ways I could think of:
1) Export all the vertex data, and import it later, offseting the vertices to the new value in each frame. I think this would be impossible because of how heavy the scene will turn out to be...
2) Create a callback function on frame change, which kind of offsets the vertices to the corresponding position when you switch tp that frame. Again issues such as will this affect the realtime scrubbing or playback rate in maya viewport creep in...

If any gurus have any idea or experience, please share...would greately appreciate it...

Thanks,
Sarge

[joojaa]

Why would you need the api for this? I mean maya llready knows how to bake deformations out to animcurves. So they would no longer be bound.

Anyway metghod 2 is as heavy as method one, infact it may be more heavy than method 1. Anyway maya allready has all the tools you need for this. If having a buch of anim curves is slow (wich it is), you can either use the cache node, (maya 8 ships with a even better one than older mayas but basicaly it only has some polish on top), or use softbodies and PDC files.

In general you dont tdo maya development in terms of frame change callback ideology but ratther as a dirty refresh ideology of the DG graph wich is much better anyway. Since maya would not update things if it dont need to, infact you are a quite brilliant developper if you can do this better than mayas current methodology.

[iamxsj]

Hi,

thanks for the reply...
There are more that one reason I am doing this...

First of all, its not just the anim curve that I need to export, but all the deformations by rigs, constrains...etc. In fact, after I export the stream animation, the guy down the pipeline need not know about the rig or animation curves...like a special effects guy can import the stream without needing the rig or animation, or a texturing guy can simultaneously do texturing, while animation is going on, and just transfer the UVs on the stream after texturing and animation is over. One other reason, however is interoperability between windows and linux machines...seems a little far fetched, but tat is wat is happening with me now. I got rigs which use specific plugins which run only on windows, and I have no way of doing the rest of the stuff in linux. By this method, it seems possible. Softwares such as XSI already have this method, but maya dosent. Hope these reasons make sense.

Anyways, here's the progress till now...I've exported the stream file by writing an export plugin inheriting from the MPxFileTranslator...it exports a model, its UVs, material groups...etc and the delta of the vertices in the succeeding frames...
To import them, I have written a custom node inheriting from the MPxShape, MPxShapeUI classes, and connected the time node as one of its inputs. I successfuly import the model in the first frame, and now trying to get the rest of the frames when the time input gets dirty(in compute function). Hope I'm on the right track. Please let me know your comments.

Thanks,
Sarge

[joojaa]

QUOTE(iamxsj @ 09/14/06, 08:37 AM) [snapback]247486[/snapback]
Softwares such as XSI already have this method, but maya dosent. Hope these reasons make sense.

why is it a feature is instantly missing when you dont know where to find it? did you even bother to look for it. Anyway all your development time is a bit wasted.

Yes your problem mekes clear sense, i do it every other day. And yes the feature IS IN MAYA. This si exactly why you shouldnt let people to develop api stuff untill the know what is what. Also you cant reaqly develop sanely in maya untill you do!

The easy but retehr slow way (theres 2 better ones but dont use them unless your dataset is somehow bigger than 100,000 points):

select your skin and do:

Edit->Keys->Bake Simulation (yes the optionbox not the menuitem)

chek thet the settings are

hirarchy below, channels all keyable,

ckek on driven channels, ciontroll points, shapes,Disable Implicit Control

adjust sample by,

unchek keep unbaked you may or may not want to use sparse bake.

you can now delete your rig completely, the skin will move.

This beakes everything down to anim curves, no no they arent your original curves (also they arent realy usable to anything and whatever you do a user could recreate them anyway), its like reading the raw stuff in. Its a bit slow on huge meshes (it works at acceptable speeds for meshes up to 50,000 poits or so) as outlined above but thats why my answer contains 2 other alternatives for this frameCache being a good option especialy in maya8 where its built into the gui and supports big sets. Anyway you dont need to write a plugin for any of this suff, and save yourself about 7 days of development (wich should mean about a grand to 5 grand in savings).

And yes this is interoperable between versions of maya even.

PS
To use particle disk canche make the object copy soft and make the original goal with veight of 1 and make a disk cance then delete original. this is faster but uses more disk.

Now this wasnt hard was it.

im mayya 8 use the new cache feature its slightly faster and more contained.

[iamxsj]

Hi,

Thanks again for the advice.

Sorry in not being clear by specifying earlier, but I already tried the bake simulation. The reason that didnt work is tat its simply not practical. For example, I tried exactly as you said on a 25000 vertex model(typical in a studio), and heres wat I got:

System: hp xw9300(Opteron 248 + 2GB mem + Quadro FX 3450 card)

baking time: more than 30 sec
before size: 56Kb
after sizeL 48 Mb, and it crashed when I tried to open the hypergraph selecting the baked object

take a look at the hypergraph and the animation graph. Once you bake it, you cannot practically tweak the animation if you had to(sometimes we have to). Maya creates like a gazillion nodes and curves once it is baked.
The file becomes unusably heavy, wheras, I am storing just the delta of the frames, and it comes up to a few kilobytes. Maya file

I agree tat functionalitywise, maya is one of the best and complete software around, but the way it stores all the data in this humengous file with nodes, and not budging to export it in anything else SUCKS!

and wat abt the added advantages of transferring UVs etc, parallel pipeline etc?

My method reads the vertice offsets happening in the frame, and draws the poly on the viewport, which maya does anyways(plus, I can use the opengl vertex extensions on my nvidia 3450 to make it more faster), and let the system(linux) to worry about caching(and it does a good job)

I connect the time node as one of the inputs to my node, so, in every frame change, it computes the value(the same as done by the emmiter in particles)...guess Ill take tat brilliant coder comment you mentioned in the first

Hope those reasons are convincing...
and also we are using maya 7, cant shift to 8.
-
Sarge

[joojaa]

good taht you have a sollution thst working for you. By the way you should have been able to test a and b allready. Wich was faster!

Yes the maya native keyframe isnt very compact in size, agreed Anyway im sure you can develop something thats faster than mayas default solution usin fragment progs thats not super hard since maya uses NONE if you take the keyframe sample as the base.

But read cerefully i tolfd you i can do it in 2 faster ways! all wich are normal maya.

PS (quick tip maya does at certain time refersh bakes much faster if you disable the viewport!)

But let me point the problem of delta values... if you sore delta form frame to frame you need to go trough all the frames, if local delta you nee dto sum it. Its not different to say a point is at 10,00 or current value+0.001 all it does is defeer the problem. Infact this is why your delta calculator would need the fragment program to sum up the change, if you wrote the local value you wouldnt need it, tough granted a fragment prog would indeed load stuff faster bavcause the GFX card caches it

But now that you re-explain the thing it occours to me maya allready has this node too, its calle the blendshape.

What the hell does uv have to do with this, all you need to do is mark anim curves as secondary nodes and they wont graph. And yes it is indeed much more compact, that having keyframes. I would demo thsi to you but im on deadline for monday. By wich time you allready should have tested both solutions. Or use the particle cache.

Thing is when you bake the stuff its no longer as editable as it is. BUt yes it realy sounds like you want tto upgrade to maya 8 look at this:

http://download.autodesk.com/us/maya/m8dem...aya8\_demo4.html

So thing is thuis has allready been adressed properly. So yes now you nee dto develop stuff thats allready been developped. such happens.

[iamxsj]

you should forgive me because I explain things so badly!
By delta, I meant world cordinates of the the changed vertices. So, I read the value, and just offset the vertices(i mean redraw).
for any frame, because storing the delta of vertex cordinates dosent actually save much space, since I am storing it in fixed float format(cant deal with variable bits...to complex for this stuff). In th first frame, I read the entire model and store it as the geometry for the shape node, and in the rest of the frames, I just slap on the changed vertices to that array.
Ill try both the methods you mentioned, and ll post the results...unfortunately, Im also a bit caught up, cause im caught up in another project, which is getting drqueue to work on windows :S
Anyways, thanks so much for your time, I have a better picture now...and yes, I need to know maya better...so Im joining a maya class(seriously ) from monday onwards, to better grip the non-programming part of it.

-
Sarge

[joojaa]

Do you store the values somehow compressed?

I mean if every vertex vere to change and you stored a floating point value as double float wich is 64 bits or 4 bytes in order to store one frame worth of doubles for each vertex would mean youd use

3*4 bytes per vertex per frame or for the 25000=300 k per frame in binary mode wich makes a scene of 100 frames worth ~30MB (im using a disk manufacturer notation here). So how come you only use few kilos? Offcourse i do undrstand if the mode is more or less stationary you could omit changes for those frames wich would for anear static surface make way for huge amounts of sabvings but im curious whats thepacking algorithm you use to get so low memory consumption.

so if you now use a few kilos, thetd mean a whopping 1/1000 lossles comprssion

[iamxsj]

Hi,

Ya, I read a few papers on compressing vertice information, and couldn't be bothered with all that complexity right now, so I just use zlib and pass the data chunks through the zlib filter before writing and reading. Since it is mostly text information, the size reduces, in most cases to 1/10th the original size. 30Mb -> 3Mb. A few kbs I was talking about was for a 25 frame static model, which maya blows up anyways...

Also, I would like to know if what Im doing is right...which is the whole point I posted here...I connect the time node to one input attribute of the custom node I made...it recalculates when I scrub through the timeline, but when I hit playback, it dosent...guess Im missing out some facts...I know its too little information for you to figure out, but if you have come across such problems, please lemme know. The emmitter node connects to the time node too, but it updates every frame.

emmitter node

time---->-----emmitter
|. . . . . . . . . . . |
|. . . . . . . . . . . |
->---particleShape--->particle

my custom node

time--------->--------animCacheShape--------->-----animCache

Im guessing I should have an output from the custom to some other node, for it to recalculate during playback?

-
Sarge