I had some pretty nice results with RODEO tests when it was the Beta version.
Now with 7.0.1 I am trying some more of these…
I set up a “target” ball and a “cue” ball. Cue ball rotates and rolls toward target ball,
as planned, but after the “solve” the target ball instantly falls right through the floor
(due to -9.81 gravity).
Why isn’t the floor (a cube created using ubershape) stopping it from disappearing
into oblivion?
All the sizes and densities are reasonable and normal. I think friction is normal.
First thing I’d do is try it using a plane NOT made with an ubershape. Just to see if it is because Ubershape is creating a single-sided plane or to see if there is some issue between the two plug-ins.
This is my system: G5 dual 2G, 3.5 G RAM, OS 10.4.11, EIAS 7.0.1
This is what’s happening: I set up a SIMPLE movement of one ball rolling into another ball.
The ground plane is a flat cube exported from FZ. When I “solve”, both balls simply “fall” through
the ground plane due to gravity.
Sizes and densities are about the size and weight of large marbles (cherry wood). Everything else
is left on default.
Then I delete the RODEO plugin, and the animation doesn’t revert to the simple rolling.
Now the balls just fall through the ground plane, with or without RODEO, and the animation is
neither implicit nor explicit but some kind of fragment of a path… and I can’t clear the animation frames.
This seems very quirky. I remember getting much better results with the RODEO Beta.
Firstly, is the ground cube added to Rodeo and enabled ?
Secondly, you can clear the animation by going to frame 1 and disabling animation. Rodeo animation will be saved after you delete the plug-in and this is a gooooooood thing in my opinion. If I remember correctly, it’s like XP in that it writes custom frames for each movement, not paths.
Thirdly, increase the number of min/max subframes to try to ‘catch’ the moment when the balls pass through the cube.
The balls do not fall through the table… They fall with the table.
Locking the table group will not stop Rodeo to make it fall with gravity, unchecking the animation triangle will.
Your child balls do not have to be animated nor included in Rodeo calculation, they will follow the parent.
Having a ball “inside” the other will probably “confuse” Rodeo.
Start with that, keep us posted. I included a similar setup with ubershapes that works fine, check it out.
You will see I use a cube to hit the cue ball because the cylinder had a tendency to “pierce” the cue ball and grab it.
Upping the minimum subframes made it better. It was however more simple to use the cube to hit the ball.
Why you dont test Mouse Tracker to move wood stick?
Parent the stick in a null (to constrain in one axis), rotate the null to achieve the correct angle with the table, enable the stick animation and record the motion with Mouse tracker..
Very interesting suggestion… I had to find out what Mouse Tracker was! Now I know.
The Tutorial with the cue stick is Richard Joly’s. He was helping me w getting RODEO
to work.
Richard’s Tutorial works perfectly on my computer, but when I try to recreate it, all I get
are balls that just sit there or fall due to gravity!! I must be missing something…
