So after quite a bit of mucking about, I have figured out why my fishbones are being offset.

The answer is that moving a newton chain after it has been rigged causes the offset. It doesn't seem to matter if it is the first or second or third chain imported. It doesn't matter if you move it in it's own chor and then import that into another chor. The thing that messes it up is moving it once the chain is linked.

The good news is that it the problem is identified. The bad news is that so far the only solution I have is to rig each chain in place.

The sample project includes two choreographies that have been simulated. the first is simulated with the fish in the position in which the chain was rigged. The second is exactly the same except that the fish was moved before simulation. As you can see the bones in the second have the offset problem.

Click to view attachment

As always any insights are appreciated.

Ha! Nice catch! And I don't mean the fish either.

This offset only happens if you move the objects using "group" mode in the chor. Where you select a bunch of models and translate them. If you select each part of the fish and translate it then the simulation works properly without offset. I often notice that using "group" mode doesn't actually change the file. If you move stuff with the group mode you can't save that change. You have to do something else. There is definately something "odd" about "group mode" in the chor. It doesn't force keys even on frame 0.

Good news... I was able to get it to work ONCE using some combination of key filters and force keys on the fish parts after moving them... but... I can't get it to work again. I forget exactly what I did.

-vern

It's not just group mode. I constrained the fish to a mover object to see if that would work, it did not.

I did confirm that if you move it one piece at a time it works, but thats more work than moving with group mode and then rigging in place (which I think works, but I'd better double check.) I could not find a solution that used group mode in combo with force key that worked. I think it's clear the group mode issue is actually an issue that needs to be fixed.

I'll let you know if I come up with more insights, thanks for yours.

This is weird because... I wonder how this is effecting my own rag doll rig? I move mine around using constraints and yet there doesn't seem to be any offset after simulation. I have to admit I usually only move it in the z and y axes though. As a matter of fact I think that must be why I've never noticed this problem specifically. This actually might explain some odd behavior I thought was something else!!! I kept having trouble understanding the angle limits on newton chains because the kept behaving differently... it might have been due to moving the rig causing offset that looked like incorrect angle limits.

I am very seriously considering creating an application to build my rig choreographies. I need to look at the file format code to see where the heck those values are being "stored" in the newton chain that causes the shift. It has to be in the file right? Or is it the actual plugin "changing" only during "runtime"?

-vern

I did a real fast comparison of a simple file to determine the difference between moving a group of models with group mode and the other way. In my test I moved two shortcuts of the same model in a chor the exact same distance along the x axis. In one I moved using the group mode. In the other I moved by selecting each one separately and moving.

Here's what I found. When moving using group mode an extra "transform" emptydriver is added called "QUATERNIONROTATEDRIVER". Another "EMPTYDRIVER" is added below it for scale. I believe this is some chunk of code that refers to the group? Yet there is no group saved in my test file. This entire chunk of code below is the only part of the two chor files that are different. I believe it is this chunk of code that is causing the problem with Newton. By deleting it the files should work the same. I have to test some more.

What the heck is a <QUATERNIONROTATEDRIVER>? And why does it only appear when group mode is used?



-vern

Whoa! More interesting... very very interesting discoveries. I mentioned that code that is added to the chor when objects are moved using group mode? Okay so I opened the "fishy" project. I moved the fish groups around and then opened that chor in Jedit and removed all of that "added" code from all the model shortcuts. Guess what really odd weird thing happened? When I opened that chor the translation locations were the same as before but the rotations I had added were gone.

The next weird thing happened to just these two model shortcuts in the chor:

fishbone1_sk2
fishbone1_tail

Both of these models had been reset to 0,0,0 in the translation. Deleting that "QUANTERNIANDRIVER" and other stuff had removed JUST THOSE translations for those two models and none of the others. I went back and checked the original chor and the "weird" extra code was in just those two models. I don't know how it got in that chor but at some point those two models were moved using group mode or some other method that causes the same thing. Maybe it has to do with key filters? I don't know.

Based on lots of "weird" things that happened to me working with my newton project, and from looking at the file format extensively, here's my theory: Moving models in a chor adds that "extra" code or whatever it is. I have seen it before I just never understood what it was. I think these extra bits of code never go away. If you move stuff around at any time using group mode it's added in and stays with the chor and shortcut. Maybe it is important but... why does it only appear when group mode movement is used?

The other shortcuts that didn't get their translation "reset" after modification did not have the "extra" code until AFTER I moved them using group mode. The two models that WERE reset after removing that extra code had that same code already in the file. You follow me? They had those weird extra "QUANTERNIANDRIVER" bits of code in the shortcuts from before. When I removed it it obviously deleted the translation locations but not from the others.

This needs more research so I can log a report. This is reminding me of that ancient "empty relationship" issue from years ago or whatever it was. This is a real tricky one. Since if involves the file format and you can't see any difference whatsoever in the AM file while working on it in AM it's very hard to figure out what is actually happening.

-vern