Did a run through on Mikael Pettersons Guided Simulation tut.

I get very different results once at the last node used - RBDBulletSolver.

My geometry goes through the ground plane and in all directions.

I double checked the parameter settings on all the nodes that he uses and couldn't catch any differences I may have used/missed.

He's using H18.287 and I am using 318.

Other than an oversight on my part - is it possible that between the two builds there be some new ‘default’ setting changes on the solvers node?

Never worked with RBD/sovlers so I'm not familiar with the workflows.

you haven't made the connection to use guided sim, connect to the last slot.

Once connected, test it…it STILL just falls down,

then you go into Guided sim tab and enable Use guides.

THEN it works…

EDIT: ahhh forget the handholding…I'm sure you know your way around…just missed the use guided sim step, is all.

Actually it doesn't make a difference.

There's two phases in the tut on the solver and in both cases it's still the ‘same’.

The one phase (without Use Guides ticked on and last input not connected) he was demonstrating the result you would get.

In this case everything is suppose to just fall down on the ground plane in the same spot the model is standing.

In my case, it goes right through the ground plane and in all different directions.

The next phase one ticks on Use Guides and the last input is connected to get the model fall to pieces on the ground plane as it moves along.

In my case with even with Use Guides ticked on and last input connected I still only get my first result with the exception there's some forward motion added to the result.

Since your saying that's the problem (tick Use Guides) I'm assuming you opened the file and it works for you. If that's the case it probably means my hip has a ‘memory lock’ (it's happened before). Will just try another set up with a ‘fresh’ hip or try another daily build.

What build did you use?

Thanks for the feedback.

So I've tried it with build .348 and still get the same results.

How about the other way round: this one works fine on .287, maybe give it a go - if the sim´s odd on your setup, it´s probably the bulid

Weird, had your file open with .287 as well, just to be sure - works just fine…
Got pretty slow internet, so I´m generally skipping daily builds, hope it´s being fixed in the next production bulid
Good Luck + Cheers!

Yeah…so I re-installed .287 and it works fine.

I have noticed since .287 a number of references to the RBDBulletSolver in the changelog.

So because of an update it is either a regression bug or some default/s parameter settings have changed for that node.

Not experienced with workflows in the area this tut covered so I'm going to leave it as is and just muck about with the parameters to see if some adjustments can be made to ‘fix’ it. Not gonna file a bug.

Thanks for the input guys.

just FYI, I'm on 287 and followed same tute…just worked the first time.

Yeah…Mikael posted on the tut chat with his hip reference.

He has it wired differently as what is shown in the tut.

I'm uploading a hip with the two comparisons to show why there is a difference in results.

I guess Mikael is rectifying or making a correction note on the video now, since I no longer see it available in the tuts section.

Sorry for the delay, on .348 by now and the sim really flew all over the place.
All right, so the point deform only takes care of the guiding (rightmost input) -
Now that I know it makes more sense
Many thanks for the scene file!

The problem you're experiencing with the pieces flying everywhere with the new builds isn't in the sim - if you dive inside the RBD Bullet Solver you'll see the sim behaving as it should.
There was a fix that was pushed out to address an issue with animated and deforming geometry not making its way into the sim - this caused a regression when no “deforming” attribute was found on the geometry. This has been fixed in 18.0.353

In the meantime, if you add a “deforming” int attrib on the incoming geo and set it to 0 should fix the issue, or making sure the input is not time dependent will work too.