Why are Max rigs so much slower than Maya rigs?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Display Modes
  12 December 2007
wavlet compression, is a way of compressing images based on a grid.
this way you don't need to decompress an image in it's entirety just to work with it.
you can just specify cordinates in a two dimensional map and decompress and view just parts of the image.

meaning, only what you need from the image is loaded into ram.

along with a wavelet shader the shader tells the renderer or the viewport what parts of the image it needs to decompress, and at what resolution, so that the hole image is not dumped into ram at one time.

think of it as a voxel based image of sorts.

floating point just means it's color values are not clamped to 255.

wavelet technology has been around for a while, one of the most popular formats
is jpeg2000, you can wikipidia most of this stuff.
or look for wavegen plugins for max maya and xsi to get an idea of what the technology does.

it would be great to have something like this built into max.

Carlos Anguiano
CEO Mangosoft LLC
  12 December 2007
Thanks Carlos I'll have a look for it.
Paul Neale
  12 December 2007
Hi carlos thanks for the explanation. have to se about this format too.
idnt want to say you dont ned textures , just to put them only iff is needed , and i is neede it always can be done lowress for viewport. is just becaue some people do the proces of modelling ,later texturing and finally rigging , so the always got heavy textures howing in screen. we dont do that we got only model and rig , and later we paste the animation with point cache in a shaded model, everithins started ages ago with your nice tool for pointcache Carlos.

for huge images for rendering with max we got to relay in the on bitmap pager than can put textures localy instead on the ram, is a bit pain in the ass because ned to be setup by hand in each machine because is in preferences rendering so is doesnt sav with the rendering normal options.

another thing i forgot to mention and really speed up my rigs is not to have the facial rig linked to the main rig. if you got a bit complex on your facial rig this will ad more weight to the body rig hierrachy and the result wil be a slower rig.

for aboiding this i do my facial rig separated in a separated mesh , and connect the mesh of the body rig with the mesh of the facial rig with morpher and automatic reaload targets and living the morpher in 100. works great and make rigs much lighter.
  12 December 2007
Hey lugi,
It's good to hear, that the point cache tool has been of some use to you.
i agree with you, stripping any shading information from your rigg model is ideal 99 percent of the time.
i prefer it just becuse my look dev people can keep working on the look of the character,
while animation is happening, without the need of updating. it is a very common practice.

it's funny that you mentioned keepeing the facial rigg off the animation rigg.
for years now (starting back in my blur days), I played alot with the concept of offloading riggs.
the idea was to build your rigg so it is broken into modules that can be attached and detached at any time.
this way we could build a bare bones animation rigs (get it bare bones!), a body deformation rigg, a facial animation rigg and then parent one of top of the other.
this would allow you to disconect what ever you didn't need at any given time. so if you wanted fast animation rigg you could fully detach the deformation rigg that would have your skinning and more complex contraints, it also allowed you to swap modules easily when changes in the rigg were made.
this aprouch has been very good for me in the past, but i did have to writte an inteface
to manage all the modules, and when you built a rigg you had to build it we this ideas in mind.

one thing that is nice about maya, is that you can build the same aprouch through referencing.

where all you do is point your reference path to a different version of the rigg, and animation stays untouched.

doing it through referencing is a more flexible, less techy aprouch.

xref character pipe is one of the ideas i'm exploring at this moment in max.
the problem with max is that referecing is not really built with rigging in mind, or the idea
of referencing assets more than once to get multiple characters (which maya does great due to how name spaces are made)

anyways you're absolutly right, one thing that i have seen is that some people try to make one rigg do it all, squash and strech, mucles, complex facial, and then they seat there and wonder, why there rigs are so slow.

Carlos Anguiano
CEO Mangosoft LLC
  12 December 2007
Here is the tool that I wrote to deal with that.


It is designed to load and unload the render version of the rig.
Paul Neale
  12 December 2007
The results are in...

Some more results from a new test.
A character made of one piece of mesh with 3816 vertices, skinned to 88 bones/joints in a complex animation rig, no other mesh deformers used. Playback speed assessed from a looped frame range from 0 to 100 with position and rotation keyframes set on all animation controls at frames 0 and 100.

Playback in 3dsmax 2008: 15 fps.
Playback in Maya 8.5: 18 fps.

The other thing to note is that moving keys in 3dsmax's trackview on the master control (the highest animation control in the hierarchy) caused an initial one second delay before they caught up to where the mouse was dragging them to, while maya had no such delay (The delay is less apparent the further you go down the hierarchy).

Max has come a long way in the last 4 versions in making rigs faster (the jump in speed from max 6 to 8 was especially huge) but it's still not as fast as maya and that trackview delay is the biggest problem with animating in max.

I hate to be so negative about such a great program, but I guess it's the major problem I have with it.
  12 December 2007
Can you do the same test with no mesh on the same rig. Just want to know if it is skin or the rig.
Paul Neale
  12 December 2007
Shapes are faster now, but in general helpers and shapes, slow down a rig considerably, contrary to geometry objects. So, a rig should have those hidden in max, to be faster.

the track view is very slow with "Modify Subtree" and/or "Modify Child Keys"
it is as if max reevaluates the whole hierarchy without optimization
may not be following this thread.
  12 December 2007
Ah yes, points are very slow to display for some reason. I always turn off all their display properties just incase they are unhidden by mistake. Also another one Brad you can test that I would like to know about. In past versions editable mesh objects have been far faster then editable poly objects when skinned and displayed. Make sure that you convert the base mesh and don't try and force it further up the stack.

Can you test the numberrs with those changes as well?
Paul Neale
  12 December 2007
In the last test, I was running max and maya simulatneously, which adversely affected both programs. This time, they're running individually (only with firefox in the background now) so all speeds are a bit faster now.


Same test as above with the same character in 3dsmax 2008. The trackview delay is the pause measured when dragging keys on the master control dummy in the trackview curve editor with interactive update turned on.

Editable poly: 16.5 fps. Trackview delay: just under a second.
A turn to mesh modifier above editable poly: 16.6 fps. Trackview delay: almost a second.
Editable mesh: 18 fps. Trackview delay: about 3/4 of second.


Here are the results with the character mesh deleted from the scene:

Maya 8.5:
Joints and control curves: 24 fps.
Joints only: 24.5 fps.
Nothing visible: 25 fps.

3dsmax 2008 (all helpers are dummies - no points):
Geometry bones and control helpers: 20 fps. Trackview delay: just over half a second.
Control helpers only: 23 fps. Trackview delay: about half a second.
Nothing visible: 23 fps. Trackview delay: about half a second.


Good tip with the editable mesh Paul. I'd been using turn to mesh modifiers, thinking that was helping me. I know better now.

  12 December 2007
another small thing that helps alot is in the properties of objects.
backface cull off wil make things quicker specially with the lowress cut meshes to do the quick rig.

Carlos i was tented to got on the version fo diferent rigs constrained between them that you can merge and connect but know i got a diferent aprroach.

i do my updates fo rigs true batch processing.heavy based on name convention.

the script will:

1-select al the controls of the characters, save the animation
2-check if iks and master got any diferent linked to the original
3-delete the character
4-merge the new version
5-do change on linking of iks and master if it was not by default
6-load the animation

the only problem with this is i ne to get the mapping previously done.and files in the correct folder.

Last edited by luigi : 12 December 2007 at 02:33 PM.
  12 December 2007
Hey Lugi,
i gotten away from the save animation approach, just because sometimes the animator will brake a rig, or constraint the rigs, at that point rebuilding a animation file can get trickier, and need some manual labor.

the way i used to build my riggs was all based on parenting
so it had very little over head.
the final version used two methods to remember it's attachments ,
one that was based on custom attributes (so the rig could be renamed and duplicated in the scene),
and a naming convention so you could dump modules out of the file and unto separate max files.

i have a few demo's of how it all works, I'll see if i can share some of that stuff with you guys.

now a days I'm using xref, which doesn't work as well as, but with some scripted tools is really simple to manage.

for example i have a show that has many robots building cars in a factory.

i have one robot rig, that is xref and can be copied just be re xrefing and changing the character prefix (this is controlled by a script).

if the rig needs to be updated the update tool will select on the animation shapes, and hold a max script array of all the controllers, the rig is removed by killing the xref , and then it's re-xrefed so that all new object and hierarchy are correct, the old controllers are pasted onto the new animation shapes to maintain any animation or constraints the animator may have had.

this same method can be used to have different rigs for muscles cloth hair or any secondary character effects.

the point cache tool has evolved into an animation publish tool, which used to methods of getting the animation into a final rendering mesh.

1)point caching for deforming geometry
2)baking controllers out for rigid non deforming objects

the second method is super useful when using xref controllers.

so the same way we would drop a point cache mod on an object, we can now dynamically xref the animation from a published max file.

anyways, it's interesting to here about how other TD's handle rig swapping, sense half the time i make this crap up as i go along.

Carlos Anguiano
CEO Mangosoft LLC
  12 December 2007
Don't we all make it up as we go along?

Ya my rig swapping has a couple of methods that it will use. First is constraints for each joint on the high res rig that is merged in. That rig is remembered in the scene so that it can be deleted at any time. The second is baking the animation to the high res rig so the animation rig can be deleted. It will do that for you as well. Also there is a batch process built in.

Carlos if you are using xRefs how are you getting around not being able to get to modifier panels for ui's? Or have you built them other ways? I have tried to come up with work flows for xrefs and just never liked any of them as I can't use CA defs.
Paul Neale
  12 December 2007
I'm using the merge modifiers option.
not the most elegant, but it works pretty
good, sense the update scripts delete and resets up the
rigs xrefs the modifiers are rebuilt.

I'm hoping that we can be more involved In the next
Beta it would be great if we could push xrefing in max.
Xrefing is still really behind in max.
Carlos Anguiano
CEO Mangosoft LLC
  01 January 2008
I don't have any scientific way of testing this, but I just discovered that ironically, having the frame rate statistics showing in the viewport seems to slow things down considerably

Anyway, I just wanted to thank everyone that's contributed to this thread lots of good info in here - Some really weird stuff I never would have thought about, like that edit mesh instead of edit poly thing, very useful =)
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 11:30 AM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.