Help Rod is shown with a "stair" effect

[cberinger]

Dear Obi Team,

while experimenting with rods, I came along this "stair" effect (see attachments)


Question is: how to get rid of the "stairs"?

Cheers,
Christian

[josemendez]

Dear Obi Team,

while experimenting with rods, I came along this "stair" effect (see attachments)


Question is: how to get rid of the "stairs"?

Cheers,
Christian

Hi Christian,

This is because in sequential mode, constraints are grouped in batches to be able to simulate them in different threads.
Switch the bend/twist and/or stretch/shear constraints to parallel mode. This will somewhat hurt convergence, but you can make up for that by using more substeps or iterations. See:
http://obi.virtualmethodstudio.com/tutor...gence.html

Also, this post by DissidentDan is related (his point #3):
http://obi.virtualmethodstudio.com/forum...p?tid=1550

[cberinger]

Hi Christian,

This is because in sequential mode, constraints are grouped in batches to be able to simulate them in different threads.
Switch the bend/twist and/or stretch/shear constraints to parallel mode. This will somewhat hurt convergence, but you can make up for that by using more substeps or iterations. See:
http://obi.virtualmethodstudio.com/tutor...gence.html

Also, this post by DissidentDan is related (his point #3):
http://obi.virtualmethodstudio.com/forum...p?tid=1550

Hi Jose (hope I got the name right :-))

thanks for the quick answer! I will try and experiment with the parallel mode!

Cheers,
Christian

[josemendez]

Hi Jose (hope I got the name right :-))

thanks for the quick answer! I will try and experiment with the parallel mode!

Cheers,
Christian

You got it right, don't worry .

I've slightly updated the solver docs to reflect this important difference between the two modes:
http://obi.virtualmethodstudio.com/tutor...olver.html

In Sequential mode, all constraints are evaluated in the order they were created (which is determined by each specific ObiActor) and each constraint “sees” the adjustments made by all previous constraints. This ensures quick convergence, so your constraints will need few iterations to look good. However it is not very stable when several constraints are fighting for control, so there are some use-cases where this mode is not a good choice. It is order-dependent, so in low-budget situations (few iterations and/or large timesteps) this can result in visible patterns in particle arrangement. For those of you a bit on the technical side, this is a Gauss-Seidel type of solver.

In Parallel mode, all constraints are evaluated but their adjustments are not immediately applied to the particles. Instead, they are stored, averaged, and then the final result is then used to adjust particle positions. This yields a very stable simulation even with lots of constraints applied at once, however more iterations are needed for “hard” constraints. It is also order-independent, so it ensures smooth particle arrangements. Use this mode if you want to trade performance -with high iteration counts- or quality -with low iteration counts- for stability. Again, for technical users: this is Jacobi-like solving.