This may seem like a ridiculous question, but has anybody successfully rigged a simulated vehicle with built-in nodes? I was absolutely shocked at how difficult and glitchy it is.

I looked at a few Blender tutorials, and they all manage to rig up a vehicle with ease, limiting constraint axes and actually have them be respected by the sim. It correctly moves without glitching, no issue. When trying to replicate such setups in Houdini I failed miserably.

Having checked out online resources for Houdini vehicle rigging, I couldn't find a single convincing setup. They all either act strangely or are simplified to the point of only being able to drive in a straight line.

Even the Houdini HIVE talk "Vehicle Destruction & Dynamic Rigging with RBDs" suggests something completely ridiculous: to set constraint iterations to 8000 or something, which makes even the simplest vehicle setup so slow you want to pull your hair out.

I wasn't able to get cone twist constraints for wheels to be stable even at such high constraint iterations. Hard constraints work better, but v@condir and i@condof seem to get completely ignored a lot of the time, making it impossible to actually limit a wheel to rotate only on one axis or a suspension to only move up and down.

I've attached a shot that shows the kind of result I ended up with, having tried all kinds of combinations of different mass, density, error reduction thresholds, substeps etc. etc. The wheels are one glitchy mess, and I had to jump through hoops post-sim to get them to act somewhat naturally.

The proxy vehicle is the direct sim result, the high-res vehicle is after heavy post-processing in SOPs:
https://www.dropbox.com/s/9z8m4o5cke2mjqh/glitchyRBD.mp4?dl=0 [www.dropbox.com]

This guy managed to build a realtime setup that looks like it's working.. no idea how but it's possible

http://www.hossamfx.org/craft-houdini-vol-1 [www.hossamfx.org]

you definitely don't need crazy constraint iteration number, just make sure your constraints don't fight each other
v@condir and i@condof work well as long as you have correct p@orient or v@r attribute on your constraints that represents the local reference frame

here is a super simple example, just wheels and motor, no suspension etc, but you can extend it as you wish (default simulation settings)

I've looked at your scene and couldn't find any relevant differences to my own scene, except for the orient attribute. And sure enough, that attribute appears to be massively important, even though you're just giving it the default value it seems.

How did you know that this is needed? It's not mentioned at all in the documentation for condir and condof.

Here's your scene slightly modified: I turned the collision shape into a regular ground plane, I added a POP force pushing the car body along X, and I deactivated the orient initialization. The result is what I'd been fighting with for days, i.e. the wheels doing weird things, ignoring their constraint directions. But if you re-enable the orient initialize, it works as expected.

So thanks of course, this is great to know! I have a feeling I'm now among roughly 12 people in the world who have this insight. Having to add 3 barely doccumented attributes via wrangles just to make directional constraints work is harsh even by Houdini's standards.

Digipiction
I've looked at your scene and couldn't find any relevant differences to my own scene, except for the orient attribute. And sure enough, that attribute appears to be massively important, even though you're just giving it the default value it seems.

How did you know that this is needed? It's not mentioned at all in the documentation for condir and condof.

Here's your scene slightly modified: I turned the collision shape into a regular ground plane, I added a POP force pushing the car body along X, and I deactivated the orient initialization. The result is what I'd been fighting with for days, i.e. the wheels doing weird things, ignoring their constraint directions. But if you re-enable the orient initialize, it works as expected.

So thanks of course, this is great to know! I have a feeling I'm now among roughly 12 people in the world who have this insight. Having to add 3 barely doccumented attributes via wrangles just to make directional constraints work is harsh even by Houdini's standards.

They are documented here:
https://www.sidefx.com/docs/houdini/nodes/dop/constraintnetwork.html [www.sidefx.com]

animatrix_
They are documented here:
https://www.sidefx.com/docs/houdini/nodes/dop/constraintnetwork.html [www.sidefx.com]

Yes, I was referring to that page, it's where I learned that condir and condof even exist. But there's no mention of the orient attribute being important for them to work.

Regardless, either I'm being very thick or this gets tricky as soon as you make the rig a bit more complex. I've added a simple suspension to Tomas' example scene, and the suspension doesn't respect its constraint direction.

Each of the four wheels is now attached to the small box closest to it, using the same constraint setup as in Tomas' original scene. Additionally, the four small boxes are attached to the big box via 8 soft constraints: 4 for position (limited to the Y axis) and 4 for rotation (no allowed rotation). But it doesn't work, the Y axis limitation is not respected. The problem persists when using hard constraints instead of soft constraints.

Digipiction
And sure enough, that attribute appears to be massively important, even though you're just giving it the default value it seems.

this is only important if you are rotating the rbds before solve after the constraints are set up, but its good to assume that's gonna be the case
that's why I made the example this way
while the value I gave it is default there is a transform applied later, so the value that actually goes into the solver always stays aligned to the transformed vehicle

Digipiction
How did you know that this is needed? It's not mentioned at all in the documentation for condir and condof.

I've done a lot of constraint work inside of the solver, where the orient plays important role
however it's not exactly necessary to provide it, if you don't provide orient, it will just initialize world space orient at initial frame
in which case it will be important that your condir points in the right world direction and not just representing the local direction since without custom orient there is no local

so due to mentioned transform, it's important to make sure your condir is marked as vector so that it transforms also and points in the right world space direction at initial frame (fixed file included with no initial orient attrib but condir marked as vector)

and here is the fixed suspension

Thank you for all of this information. I will check out your new files tomorrow and see what kind of dark magic you used to make this happen!

I remembered someone odforce had a big thread about car rigging, just found it:

https://forums.odforce.net/topic/39684-how-create-a-constraint-network-for-simulating-car-suspensions/?do=findComment&comment=192004 [forums.odforce.net]

Julian has posted updates on a few other posts on odforce, as well updates towards the end of that thread I linked, worth a browse around.

That looks like a great resource, I hadn't seen it before, thanks!

tamte
and here is the fixed suspension

Take a look at frame 16 in your scene. While the spring motion looks great now (requiring no less than 3 constraints per spring to limit it to one axis!), you can see that the wheels are now not respecting their rotation limitation to just one axis - they are also bending inward.

In Blender or even Unity you have a series of checkboxes that you can untick in order to limit a constraint's freedom of movement or rotation, and from what I've seen that actually works.

To get spring motion along just the Y axis, in Houdini we now had to add:
- a position spring or hard constraint whose @condir is set to Y (condof 2)
- a position spring constraint with free movement
- a rotation spring or hard constraint with no movement

And having made these additions, now the wheels don't respect their rotation limitation anymore.

I think next time I need a vehicle rig I'll do it game-style, with raycasts against the ground and calculating the forces in a SOP solver myself. But this whole thing really makes me wonder whether the internal code is broken somewhow.

Digipiction
Take a look at frame 16 in your scene. While the spring motion looks great now (requiring no less than 3 constraints per spring to limit it to one axis!), you can see that the wheels are now not respecting their rotation limitation to just one axis - they are also bending inward.

you can definitely tweak the settings to make it stiffer
you can increase the constraint iterations a bit, maybe a 100 (I believe you can also do it per constraint)
but mostly Constraint Error Parameter on the constraints defines what percentage of the constraint has to be corrected each step, defaults to 0.2 so it's not gonna enforce it fully, it's not recommended to go above 0.8 for stability tough, but even 0.8 should already give you much stiffer result

there is also an interesting talk about
- Vehicle Destruction & Dynamic Rigging with RBDs | Keith Kamholz | Houdini HIVE Worldwide
Your text to link here... [www.youtube.com]

- a complete car-rig Setup
Your text to link here... [youtu.be]

- so here is my car rig setup
based on tutorial by Ayman Abolila - see link in previous post

the rig setup works fine
Except for the steering

in the tutorial the control is done with a sopsolver
But when I try that, the wheels spin without applying any force
- So I think it has something to do with the Sopsolver
looks like the steering is being forced every frame and is causing the problems

Is this a valid setup to steer the wheels?
or are there better options?

any help is welcome

w_maro
- so here is my car rig setup
based on tutorial by Ayman Abolila - see link in previous post

the rig setup works fine
Except for the steering

in the tutorial the control is done with a sopsolver
But when I try that, the wheels spin without applying any force
- So I think it has something to do with the Sopsolver
looks like the steering is being forced every frame and is causing the problems

Is this a valid setup to steer the wheels?
or are there better options?

any help is welcome

I'm having a similar issue with this set-up. Did you ever solve the steering problem?

not really
- but I think it's deprecated with the new rbdcarrig