So I'm working at the other end of the ragdoll evolutionary ladder, trying to get a fish skeleton to behave. I'm much of the way there, but impact keeps breaking my skeleton. This doesn't happen every time, as Newton gives a different solution every time. I've tried a bunch of different things, different material settings, different model designs, high velocity, and it's getting better, but not fixed. If anyone else playing with Newton has any suggestions I'd really appreciate it. I think my forehead is taking on the brick pattern from the wall.
The movie includes a typical breakage. The project is ready to simulate.
Click to view attachment
Click to view attachment
Full Version: Ragdoll Devo(lution)
Hash, Inc. Forums > Technical Direction and Development (Learning Animation:Master) > A:M Tutorials and Demonstrations > Newton Physics
I'll take a closer look at what you did when I have a chance. After a quick scan here here's a few tips you can look at.
Make the "stops" bigger... the cylinder stops on the joints. I ended up making mine pretty "beefy". Remember that the physical property of the stops is based on the mesh. A thicker larger mesh means that the other objects aren't likely to pass through. If the stops are too small and thin and the force pushes through from one frame to the next... it breaks. You want those stops to be "strong" enough to prevent that.
Another issue I ran into was trying to create "physical" joints that stayed together. It was too unpredictable. Once those joints break apart that's the end of the story. I ended going with a newton chain and a sphere joint between the joints that have those "stops". This means the joints might come apart but will snap back together (my joints now are perfect. They never break).
This works actually because of a "fault" in newton chains. Newton chained objects don't "interact". they don't see each other as physical objects. The inner sphere would intersect both sides of the joint. When that happens both of those shapes will not actually react to the inner sphere joint but WILL react to each other. Then you can totally and completely eliminate the need for that "axle" center piece. That is the real problem with that type of joint. You want a "smooth" loose joint. Trying to put a "post" through rings... I never got it to work well. It always broke apart. It was just too... realistic.
So the inner sphere is sort of like a Teflon ball bearing that holds the joints together. The two parts that "hinge" on either side don't need to be "hollow" through the center with the rings and holes. You just need a circular center "post" on one side (with the rotation stops), and two circular circular parts on the other for the "slot". The newton chain sphere between them locks it together. The circular sides keep the joint lined up and no side to side movement. You can chain both sides of the joint to the sphere or chain one to the sphere and the sphere to the other. Makes no difference because no matter how it's chained the center sphere object does not react to collisions with the joint models.
I think that will solve the problem. It does require a bit of trial and error... in my case... lots of error... and mostly being found guilty at trial.
-vern
Make the "stops" bigger... the cylinder stops on the joints. I ended up making mine pretty "beefy". Remember that the physical property of the stops is based on the mesh. A thicker larger mesh means that the other objects aren't likely to pass through. If the stops are too small and thin and the force pushes through from one frame to the next... it breaks. You want those stops to be "strong" enough to prevent that.
Another issue I ran into was trying to create "physical" joints that stayed together. It was too unpredictable. Once those joints break apart that's the end of the story. I ended going with a newton chain and a sphere joint between the joints that have those "stops". This means the joints might come apart but will snap back together (my joints now are perfect. They never break).
This works actually because of a "fault" in newton chains. Newton chained objects don't "interact". they don't see each other as physical objects. The inner sphere would intersect both sides of the joint. When that happens both of those shapes will not actually react to the inner sphere joint but WILL react to each other. Then you can totally and completely eliminate the need for that "axle" center piece. That is the real problem with that type of joint. You want a "smooth" loose joint. Trying to put a "post" through rings... I never got it to work well. It always broke apart. It was just too... realistic.
So the inner sphere is sort of like a Teflon ball bearing that holds the joints together. The two parts that "hinge" on either side don't need to be "hollow" through the center with the rings and holes. You just need a circular center "post" on one side (with the rotation stops), and two circular circular parts on the other for the "slot". The newton chain sphere between them locks it together. The circular sides keep the joint lined up and no side to side movement. You can chain both sides of the joint to the sphere or chain one to the sphere and the sphere to the other. Makes no difference because no matter how it's chained the center sphere object does not react to collisions with the joint models.
I think that will solve the problem. It does require a bit of trial and error... in my case... lots of error... and mostly being found guilty at trial.
-vern
Another tip: For things like cylinders you don't need newton groups for each "section". A cylinder can be just one newton group. Outside curved surfaces have denser "collision hulls". It is the INSIDE curves that are "bumpy" and need lots of groups. Inside curves just aren't "important" to newton apparently. It' mostly concerned with the outer surfaces. By eliminating the "hoops" and consolidating the groups I got your joint gizmo down to just 7 newton groups instead of... uh... 90 or something.
-vern
-vern
That's a stiff lookin fish. Too much time in the fryer.
Keep Vern on it. He's the rag doll guru.
Keep Vern on it. He's the rag doll guru.
Vern, you the man- the ragdoll man.
Used your suggestions and got excellent results. The only drawback is that in using Newton chains you seem to have to rig it in the choreography that you are simulating in. I had hope to import the fish choreography into itself several times for multiple fish falling, but the impoted skeletons are not newton chained and just fall apart. Oh well, I'll just have to simulate the fish one at a time. (quit snickering, I said SIMULATE)
Here is a successful fish drop. Again, the project is ready to simulate.
Click to view attachment
Click to view attachment
Used your suggestions and got excellent results. The only drawback is that in using Newton chains you seem to have to rig it in the choreography that you are simulating in. I had hope to import the fish choreography into itself several times for multiple fish falling, but the impoted skeletons are not newton chained and just fall apart. Oh well, I'll just have to simulate the fish one at a time. (quit snickering, I said SIMULATE)
Here is a successful fish drop. Again, the project is ready to simulate.
Click to view attachment
Click to view attachment
QUOTE(Bendytoons @ May 8 2009, 02:41 PM) 
I had hope to import the fish choreography into itself several times for multiple fish falling, but the impoted skeletons are not newton chained and just fall apart.
That's weird. I am using that technique with my rag doll set up. I import the chor with the newton chains in place and it works. It could be having "duplicates" might be the problem. It also might be that I renamed the shortcuts in the chor. Instead of "skeleton (2) skeleton (3) I gave them names like "front skeleton" and "Back skeleton". I don't know if that would make any difference but Newton does reference the NAME in the chor specifcally. Also Newton won't "update' the chains if you change the names of the models in the chor. I bet that's it. When you import a second copy it tags a number to the end of the name in the shortcut. This will break the newton chains because the name is different.
Glad I could help.
-vern
Another tip. I stopped bothering with the transparency on the newton objects surface properties. It was easier to just run the simulation and then hide those objects before rendering. If you put them in a chor folder you just select children of the folder and make them "inactive" in one shot. This way you can "preview" the simulation with just the newton objects to see how they are working. If they are "invisible" it's hard to tell what's going on sometimes.
-vern
-vern
Good tip about the transparency. You were correct about the naming issue. I went in a checked, then redirected the chain to look at the renamed objects.
Don't know how... dedicated you are or... comfortable working with the raw file fomat but an easy way to set up multiple "fishies" to bring in to the chor can be done with a text editor. For example you save out just the chor. Open in a text editor and find all the references to the "duplicate" shortcuts in the newton chain info. You change them using a global search and replace. You make several copies of this chor from the text editor each with the correct shortcut names to match. Then when you import each of those chors into the main chor they are ready to go. The newton chains care correct. The newton chains "match".
For instance name all the shortcuts in the original chor so they aren't "repeated". Skeleton front, skeleton back, head, tail, tail joint, head joint, body joint, etc. Open that chor in a text editor. Save out several copies of it (as many as you need) but change the Newton links and add the "number" to the end, skeleton back (2) etc. You could even make it really simple and name those shortcuts in the chor with a common extension like _fishy and then search and replace all at once.
I can show you exactly how to do this if you want. It's not that hard.
-vern
For instance name all the shortcuts in the original chor so they aren't "repeated". Skeleton front, skeleton back, head, tail, tail joint, head joint, body joint, etc. Open that chor in a text editor. Save out several copies of it (as many as you need) but change the Newton links and add the "number" to the end, skeleton back (2) etc. You could even make it really simple and name those shortcuts in the chor with a common extension like _fishy and then search and replace all at once.
I can show you exactly how to do this if you want. It's not that hard.
-vern
QUOTE(heyvern @ May 9 2009, 02:47 AM)
Don't know how... dedicated you are or... comfortable working with the raw file fomat but an easy way to set up multiple "fishies" to bring in to the chor can be done with a text editor. For example you save out just the chor. Open in a text editor and find all the references to the "duplicate" shortcuts in the newton chain info. You change them using a global search and replace. You make several copies of this chor from the text editor each with the correct shortcut names to match. Then when you import each of those chors into the main chor they are ready to go. The newton chains care correct. The newton chains "match".
For instance name all the shortcuts in the original chor so they aren't "repeated". Skeleton front, skeleton back, head, tail, tail joint, head joint, body joint, etc. Open that chor in a text editor. Save out several copies of it (as many as you need) but change the Newton links and add the "number" to the end, skeleton back (2) etc. You could even make it really simple and name those shortcuts in the chor with a common extension like _fishy and then search and replace all at once.
I can show you exactly how to do this if you want. It's not that hard.
-vern
For instance name all the shortcuts in the original chor so they aren't "repeated". Skeleton front, skeleton back, head, tail, tail joint, head joint, body joint, etc. Open that chor in a text editor. Save out several copies of it (as many as you need) but change the Newton links and add the "number" to the end, skeleton back (2) etc. You could even make it really simple and name those shortcuts in the chor with a common extension like _fishy and then search and replace all at once.
I can show you exactly how to do this if you want. It's not that hard.
-vern
Yeah, I've been following the ragdoll thread and saw you were using this technique. I realized this approach would work while walking to the pub to meet a friend last night. It confirms that the mere promise of a cold beer can solve problems.
I'm sure I will solicit more help as I fumble through this process. Thanks for all the help so far and to come.
-Ben
Progress report:
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*
In jedit, I alter fish1.cho, and replace "fish1_" with "fish2_" and save the new fish2.cho
I create a new choreography in A:M, and import fish1.cho directly into the new Choreography.
I simulate Newton and all is well.
If I import both fish1.cho and fish2.cho, I have a problem. When I import the .cho it brings it 's objects with it, if I import two .cho with shortcuts to the same object, it imports the objects anyway and increments the number at the end. Now my second fish is made up of objects that are not referenced in the newton properties.
I though the solution might be to import the chor into the PWS, then drag the contents into the new chor. This does not create new objects, but the dragged and dropped fish doesn't simulate, and I'm not sure why.
Any thoughts would be helpful.
In the mean time, my skeleton is working well enough that I can get pretty good results with no newton chains, just physical ones, and barring Vern's (or somebody else's) brilliance giving me a solution I will keep going that way.
Here is a multi fish shot. You can see the tail break in the fish that slides off screen right.
Click to view attachment
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*
In jedit, I alter fish1.cho, and replace "fish1_" with "fish2_" and save the new fish2.cho
I create a new choreography in A:M, and import fish1.cho directly into the new Choreography.
I simulate Newton and all is well.
If I import both fish1.cho and fish2.cho, I have a problem. When I import the .cho it brings it 's objects with it, if I import two .cho with shortcuts to the same object, it imports the objects anyway and increments the number at the end. Now my second fish is made up of objects that are not referenced in the newton properties.
I though the solution might be to import the chor into the PWS, then drag the contents into the new chor. This does not create new objects, but the dragged and dropped fish doesn't simulate, and I'm not sure why.
Any thoughts would be helpful.
In the mean time, my skeleton is working well enough that I can get pretty good results with no newton chains, just physical ones, and barring Vern's (or somebody else's) brilliance giving me a solution I will keep going that way.
Here is a multi fish shot. You can see the tail break in the fish that slides off screen right.
Click to view attachment
Can't help you with Jedit...but just want to say how funny that movie clip is to watch...
Haha its raining fish ,I remember some years ago it did rain fish insome part of the UK
QUOTE(Bendytoons @ May 13 2009, 10:39 AM)
Progress report:
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*....
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*....
Dagnabbit you are right. My mistake. I was doing this originally with EXTERNAL linked models. Linked models not embedded work fine with this technique. For some reason though when the models are referencing the project it brings in new ones... silly program, tricks are for kids.
Dragging and dropping from another chor keeps any links from the first chor. Very annoying. It doesn't update those things that are dragged in to reference things in the NEW destination chor. Very odd if you ask me.
-vern
QUOTE(heyvern @ May 13 2009, 04:51 PM)
QUOTE(Bendytoons @ May 13 2009, 10:39 AM)
Progress report:
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*....
Skeleton is working much better now, though I still break the tail some. Jedit is very cool, but now I'm having a problem:
I create "fish1" choreography, with shortcuts named fish1_*....
Dagnabbit you are right. My mistake. I was doing this originally with EXTERNAL linked models. Linked models not embedded work fine with this technique. For some reason though when the models are referencing the project it brings in new ones... silly program, tricks are for kids.
Dragging and dropping from another chor keeps any links from the first chor. Very annoying. It doesn't update those things that are dragged in to reference things in the NEW destination chor. Very odd if you ask me.
-vern
Once again your wisdom and experience solve the problem. I saved all the skeleton bones as external models and all seems to be working again. Woohoo.
Glad to help!
I still think that import chor behavior is... uh... er... incorrect. It doesn't make sense to create duplicate models when the model name and shortcut are clearly indicated in the chor file. Maybe it should at least be an option to create "new" models... a check box or something. Of course you could always embed the models at some point but... when you are doing a huge stage crash or creating a complex rag doll rig... it's a pain to save out all those models.
-vern
I still think that import chor behavior is... uh... er... incorrect. It doesn't make sense to create duplicate models when the model name and shortcut are clearly indicated in the chor file. Maybe it should at least be an option to create "new" models... a check box or something. Of course you could always embed the models at some point but... when you are doing a huge stage crash or creating a complex rag doll rig... it's a pain to save out all those models.
-vern
Aaaargh.
So here is the ongoing status of this project. I completely redid the skeletons using Newton links, not physical ones. This seemed to work great.
drop the fish from anywhere and the skeleton behaved.
I made a file with only the fish, and named the shortcuts fish1_*
I took that file into Jedit, and edited the shortcut names, but changed nothing else.
Again, import any of these into a new chor and they work great.
So I tried importing more than one of my fish into a new chor- not great.
The first fish imported works properly. The second fish, and subsequent ones, do not work properly.
It does not matter which fish is imported first, all files are identical except for shortcut names, it works.
It does not matter which fish are imported after, they break.
Everything looks fine, and I'm not quite sure whats broken.
The chains stay relatively in tact, but the pieces pick up minor translation from each other, which they should not be able to do, but they do not break apart.
Here is an example. The fish on the right behaves properly. It was imported first (though it is fish2). The fish on the left breaks and gets weird translation.
Click to view attachment
Any thoughts, ideas, advice will be very welcome.
So here is the ongoing status of this project. I completely redid the skeletons using Newton links, not physical ones. This seemed to work great.
drop the fish from anywhere and the skeleton behaved.
I made a file with only the fish, and named the shortcuts fish1_*
I took that file into Jedit, and edited the shortcut names, but changed nothing else.
Again, import any of these into a new chor and they work great.
So I tried importing more than one of my fish into a new chor- not great.
The first fish imported works properly. The second fish, and subsequent ones, do not work properly.
It does not matter which fish is imported first, all files are identical except for shortcut names, it works.
It does not matter which fish are imported after, they break.
Everything looks fine, and I'm not quite sure whats broken.
The chains stay relatively in tact, but the pieces pick up minor translation from each other, which they should not be able to do, but they do not break apart.
Here is an example. The fish on the right behaves properly. It was imported first (though it is fish2). The fish on the left breaks and gets weird translation.
Click to view attachment
Any thoughts, ideas, advice will be very welcome.
Any chance you can post the "template" fish chor so I can try it myself? It might be quicker than setting up something and trying the text editing routine from scratch.
I have a theory about what is happening though. When you did your editing to the original and changed the shortcut names did you make sure they were changed in the Newton links? The Newton links point to the shortcut as well. I am assuming you did that. Its a wild guess. Seeing the file and looking at the text would help me test this out.
-vern
I have a theory about what is happening though. When you did your editing to the original and changed the shortcut names did you make sure they were changed in the Newton links? The Newton links point to the shortcut as well. I am assuming you did that. Its a wild guess. Seeing the file and looking at the text would help me test this out.
-vern
I just did a very very simple text editing test with two linked models and it worked. I had two models to start. ConeA linked to CubeA. I saved out the chor, and changed the names to ConeB and CubeB in one file and ConeC, CubeC in a second file.
ConeA was changed only in one spot. The shortcut name. CubeA had to be changed twice, once for the shortcut and once as the target for the newton chain in ConeA.
I loaded the two chors into the original chor with the "A" named models and simulated. Each one worked independently as expected.
So the key is to make sure all the spots get changed (and not too many). It appears you have 6 parts in your fish. Each linked to the next and the last one not linked to anything. This would mean you would change the shortcut name twice for all models except the first in the chain which nothing links to so it's shortcut name would only appear once in the chor. You would end up with a total of 11 changes, 2 x 5 + 1.
Make sure your chains are correct in the original chor by clicking on the newton chain link reference and making sure that the correct shortcut name is HIGHLIGHTED when the window pops up. If the name is not highlighted in that pop for the newton chain it isn't properly linked. After importing one of the changed files do the same thing to make sure the links are correct. Once you get one to work the others should work as well.
-vern
ConeA was changed only in one spot. The shortcut name. CubeA had to be changed twice, once for the shortcut and once as the target for the newton chain in ConeA.
I loaded the two chors into the original chor with the "A" named models and simulated. Each one worked independently as expected.
So the key is to make sure all the spots get changed (and not too many). It appears you have 6 parts in your fish. Each linked to the next and the last one not linked to anything. This would mean you would change the shortcut name twice for all models except the first in the chain which nothing links to so it's shortcut name would only appear once in the chor. You would end up with a total of 11 changes, 2 x 5 + 1.
Make sure your chains are correct in the original chor by clicking on the newton chain link reference and making sure that the correct shortcut name is HIGHLIGHTED when the window pops up. If the name is not highlighted in that pop for the newton chain it isn't properly linked. After importing one of the changed files do the same thing to make sure the links are correct. Once you get one to work the others should work as well.
-vern
Vern,
First, thanks again for your help.
I'm attaching a project file which has four choreographies, the original fish chor and three numbered chors that have had the fish1 and/or fish2 chors imported.
#1 has just the fishes1.chor imported and simulated (I repositioned the fish after import)
#2 has just fishes2.chor imported and simulated
#3 has both fishes1.chor and fishes2.chor imported and simulated
#1 and #2 both work properly
In #3 fish1 (imported first) works properly, but fish2 does not. If you look at fish2 (on the right) after simulation you'll see that pieces of the skeleton are offset, which shouldn't be possible with the Newton chain.
I checked in jedit, and all the links in the files are right from what I can see. If you find my mistake I will be really happy.
Click to view attachment
First, thanks again for your help.
I'm attaching a project file which has four choreographies, the original fish chor and three numbered chors that have had the fish1 and/or fish2 chors imported.
#1 has just the fishes1.chor imported and simulated (I repositioned the fish after import)
#2 has just fishes2.chor imported and simulated
#3 has both fishes1.chor and fishes2.chor imported and simulated
#1 and #2 both work properly
In #3 fish1 (imported first) works properly, but fish2 does not. If you look at fish2 (on the right) after simulation you'll see that pieces of the skeleton are offset, which shouldn't be possible with the Newton chain.
I checked in jedit, and all the links in the files are right from what I can see. If you find my mistake I will be really happy.
Click to view attachment
At first glance It appears to be an issue in AM.
I created a new third fish chor from the original fish chor. Edited the file for 3 copies. Those 3 copies are PERFECT. Each one comes in fine on its own. Each subsequent one added though gets a slight offset. I need to study this some more to see what's going on. I also want to add "3 fishes by hand" to make sure it isn't the text editing causing the problem. Another issue that might be causing this which I want to test is the NUMBERS at the ends of the names. I've started using letters because AM likes to add numbers to the end of multiple copies of the same object... it's a long shot but worth testing and eliminates and possible conflict. For example instead of "fishbone3_sk1" I would change it to "fishboneC_skA, fishboneC_skB, etc etc". This is critical research for me because I have yet to test my rag doll rig on more than one character in a chor. If I can't use multiple instances of the set up it's going to be a huge set back for me. This SHOULD WORK DANGIT! I am hoping there is one teeny tiny thing we've missed somewhere.
If I create a chor from scratch, setting up all the shortcuts and links BY HAND and it still does the same offset thing, then we know it's some kind of issue with AM. If however, it works after doing it by hand I have a file I can use for comparison to see where the differences are. I will keep you updated on my experiments.
-vern
I created a new third fish chor from the original fish chor. Edited the file for 3 copies. Those 3 copies are PERFECT. Each one comes in fine on its own. Each subsequent one added though gets a slight offset. I need to study this some more to see what's going on. I also want to add "3 fishes by hand" to make sure it isn't the text editing causing the problem. Another issue that might be causing this which I want to test is the NUMBERS at the ends of the names. I've started using letters because AM likes to add numbers to the end of multiple copies of the same object... it's a long shot but worth testing and eliminates and possible conflict. For example instead of "fishbone3_sk1" I would change it to "fishboneC_skA, fishboneC_skB, etc etc". This is critical research for me because I have yet to test my rag doll rig on more than one character in a chor. If I can't use multiple instances of the set up it's going to be a huge set back for me. This SHOULD WORK DANGIT! I am hoping there is one teeny tiny thing we've missed somewhere.
If I create a chor from scratch, setting up all the shortcuts and links BY HAND and it still does the same offset thing, then we know it's some kind of issue with AM. If however, it works after doing it by hand I have a file I can use for comparison to see where the differences are. I will keep you updated on my experiments.
-vern
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.