9 réponses à ce sujet

[MerricksDad]

I'm working on this new gorilla model, and everything was going fine until at one point my model starts to jiggle. Not the whole thing, just one node, the torso. I don't have any modifiers on it. It has no scale keys. In most frames, not including during deadspace between animations, and start and end frames, or anywhere no animations exist between start and end frames, it just scales, but only on the X axis. How is that even possible. It seems to scale in and out like the model is breathing hyper fast. If I clone the node, it makes a really weird shape and often fills the entire view.

 

I've tried importing another version of the same node without animation keys on it, and it works fine, except it is missing all the animation work I just did. So I tried attaching the imported older version to the current version, which just carries the jiggling to the new mesh too.

 

I have no idea what this is, or what is causing it. When I export my model, it is entirely mangled. All the parts are out of order everywhere. Never seen anything like it.

 

Ive closed and restarted GMAX to make sure it wasn't just a temporary issue. Same thing. Reload the model. Same thing.

 

Any ideas? Is there a way I can look at internal properties that gmax not have gui for?

[MerricksDad]

If you know this one, do let me know. In the meantime, I just redid the torso and baked my pivots to clear it up.

[Killmonger]

Offhand I am unsure if I comprehend your present dilemma...

 

However,

 

1) Out of frame animation keys? Bounce/Jiggle may be from an incomplete deletion of ancillary files (Check schematic view)

2) Reset Xforms on unlinked geometry after scale (before animation)? Exploded geometry can be a result

3) "Scale locked in X axis" Is the scale function set to the correct mode (of 4 types)

 

Just some thoughts

imho

[MerricksDad]

These don't account for the jiggle on the one node, but here is what I found so far:

 

After I cloned some anim keys, I used undo. Something happened in the undo and it caused some of the nodes selected, but not all, to take on a rotation offset of quat 0 0 -1 0 (node.objectoffsetrot). I had been intentionally using node.objectoffsetpos to do some bone work that I later bake with a function I wrote. Unfortunately I had not saved the last few animation sequences I had just completed, and with undo having corrupted the nodes, I needed to move forward. So what I did was bake my offset positions (pivots). Then I fixed each node not rotated to quat 0 0 0 1 by setting their objectoffsetrot to quat 0 0 0 1, and then setting the node rotation to quat 0 0 -1 0, then applying my custom resetXform to that node.

 

None of this fixed the jiggle on the torso node. So I baked all the pivot out of the torso node as above, which corrupted the vertex placement, just like if I was to clone the node. I take this as somewhere in the pivot data, there was also some transform data on the X axis which was corrupted. The X axis locations of all vertices that were non zero went off screen, as if scaled by infinity. So I imported the old torso shape, attached it to the non-jiggling-but-corrupted torso, and then deleted by element the old torso, leaving just the original shape. Pain in the ass.

 

Anyway, back on track now, 3 hours later.

[Killmonger]

Yes I understand better now

 

Depending upon the world scale, could it have been a precision rounding error in the script?  int / float variables? hmm...

 

But you are back on track on again...

[MerricksDad]

The issue occurred directly after the undo. I will have to intentionally do this more with some test models to see if I can duplicate it. That way I can be sure exactly what causes it, or if the undo action is just faulty around pivot data in Gmax. I'm sure they fixed it in newer versions of max.

 

I don't know anything about how it runs numbers internally, except that when rotations are made using quat values, sometimes it runs the wrong direction around one or two of the axes, which is beyond annoying. I try to avoid doing any non-integer quat values at all costs, including rotation addition/subtraction.

 

In any case, I have 10 copies of the corrupted jiggler gmax file so I can poke at it later to see what caused the infinite scaling on the X axis only. I wasn't aware I could even scale on just one axis without using a box transform, especially without even using a modifier. This may be something I can use to my advantage in the future.

[MerricksDad]

ah, spoke too soon. The "fix" damaged the animation on some of the sequences for the right arm. But doing the right arm over is not that big a deal.

[MerricksDad]

I was able to duplicate this. So here is what is actually happening:

 

When I went to select multiple objects, I accidentally used shift instead of ctrl, which is the default clone object key. When I hit cancel, the corruption begins. Not always, but I can definitely duplicate it more times than not. It appears to only happen when the model is not at timeframe 0.

 

So the model node X scale seems to go to 0, making all verts move to x location 0. No amount of undo will fix it, and is more likely to burn it into the model ( in a way of thinking ).

 

If you then try to import an older model and attach to it to restore the shape, the scale gets even further messed up, making some kind of weird jiggle when animated, as mentioned above. Something in the model then sets the X scale to any number between 0 and infinity, but if you move the slider, no scale is shown in the GUI. By this time, you are stabbing your own heart out.

 

So how do you get out of it without having to go through all the crap I mentioned above? Simple:

 

1) Select the flattened offending model node

2) from the maxscript rollout (I'm using v0.8b60), on the first panel (General Utils) click the "IntoDummy" button.

3) The node will transform into a dummy, removing all animation on that node. You don't want that.

4) Now hit undo and it will back up one step inside the IntoDummy script, which restores TWO copies of your fubar model, but in a restored shape.

5) Select the cloned model node which DOES NOT have animation keys on it.

6) Delete that duplicate. Doing this will unlink the node<>parent structure.

7) Select the unparented child nodes and reparent them to the restored node.

8) Done! Easier than doing all the stuff I went through yesterday.

 

I hope nobody actually has this problem in the future, but at least the fix is simple.

[Tarot Redhand]

Have you thought of compiling all the fixes, that you have come across since you started modelling, into a single, up-datable document and putting it onto the new vault?

 

TR

[MerricksDad]

not particularly. I'm hoping this never comes up, but I may just make a quick function for this in my script library. I may personally need it a lot, especially since my damn fat finger wont stay off both ctrl and shift at the same time.