tyflow vehicle support to linked helpers

[Wintermute84]

Hello! Thank you for the vehicle update, I've been wanting this for years! Currently, I'm trying to develop a proper workflow to rig our vehicles in a way that would be similar to our approach that we used with craft animations. While I can see many reasons to use the tyflow vehicle setup as intended (traffic systems etc.), it can become problematic when funneling dense proxies or large collections of cad data (often in the 1000s) through tyflow. As a workaround, I'm posting some screenshots and a simple scene to illustrate an alternative approach and I'd like to know if there's a way to simplify it further.

As an example, it begins in layer 01 with the preset car (Our rigs will be based on low poly models of our vehicles which I can't post here). The only difference is the addition of a Display Data operator to identify the resulting vehicle particles and a temporary reduction in the forward velocity for testing.

In layer 02, there's a collection of red point helpers that have been assigned a tyParticleController to link them to their corresponding vehicle particles.

In layer 03, there's a collection of green point helpers that parent to the red point helpers while not inheriting their change in scale. It would be nice if the tyParticleController could avoid inheriting scale which would make these green point helpers unnecessary. Is this possible? The actual vehicle proxies and/or cad data would then be linked to these final helpers.

I hope the intent here is clear, and if there's a better way of approaching it, please let me know

Also, I noticed that the rotational value is higher on the front right wheel when driving in multiple tests using the preset car. is this somehow a bug? I'm including a layer 04 which includes point helpers with baked animation (something that will be part of our workflow often) which makes the difference between helper animations more visible in the curve editor but it's very apparent in the viewport alone.

[tyFlow]

The vehicle workflow is designed to work efficiently with hires vehicle models - after first load everything is cached internally and the geometry doesn't need to be reloaded by tyFlow until it changes. So unless you've run into a specific scene where the new workflow is causing issues, you should not hesitate to load the hires geo (even hundreds of hires parts) into tyFlow (by linking them to the corresponding tyVehicle helpers so that they're imported as part of the vehicle rig), rather than try to link it to an exported sim.

If you absolutely need to link to the sim rig, then the tyParticleController is the way to go - although I don't understand why you don't want scale to be inherited...

As for the roll - you can adjust the spin lock parameters in the Vehicle op to help avoid slippage, which is what you're seeing here. By default, PhysX does a really bad job of keeping wheels completely locked to the ground...so I implemented spin locking, which perfectly locks wheels to the ground (prevents any slippage), when below certain spin/speed thresholds - those thresholds make some allowances for slippage if, for example, drive torque is above a certain threshold (which is what you're seeing when there's a bit of slippage as the vehicle accelerates). If you want basically no slippage ever, set both thresholds to very high values (ex: 1000). Also the reason you see it only happening on the front wheels is because by default they're the only wheels set to have drive torque (FWD).

[Wintermute84]

The vehicle workflow is designed to work efficiently with hires vehicle models - after first load everything is cached internally and the geometry doesn't need to be reloaded by tyFlow until it changes. So unless you've run into a specific scene where the new workflow is causing issues, you should not hesitate to load the hires geo (even hundreds of hires parts) into tyFlow (by linking them to the corresponding tyVehicle helpers so that they're imported as part of the vehicle rig), rather than try to link it to an exported sim.

If you absolutely need to link to the sim rig, then the tyParticleController is the way to go - although I don't understand why you don't want scale to be inherited...

As for the roll - you can adjust the spin lock parameters in the Vehicle op to help avoid slippage, which is what you're seeing here. By default, PhysX does a really bad job of keeping wheels completely locked to the ground...so I implemented spin locking, which perfectly locks wheels to the ground (prevents any slippage), when below certain spin/speed thresholds - those thresholds make some allowances for slippage if, for example, drive torque is above a certain threshold (which is what you're seeing when there's a bit of slippage as the vehicle accelerates). If you want basically no slippage ever, set both thresholds to very high values (ex: 1000). Also the reason you see it only happening on the front wheels is because by default they're the only wheels set to have drive torque (FWD).

Our vehicles change often, sometimes within a brief session between fairly elaborate 'trims' and accessories... We take advantage of vrayproxies where we can but we can still find ourselves in a position where our object count can reach into the 1,000s or 10,000s for various reasons and juggling that much geo by adding or removing it to tyflow between passes can be daunting unfortunately. 

We often just create an organized set of layers and have their visibility enabled/disabled through a pass manager when submitting renders.

In addition to the geo itself, we have a very complex rigging system made up of helpers, IK solvers etc. already in place (largely for our suspension systems). With craft animations, we would have this system inherit a lot of it's input through wired parameters, similar to the linked helper system posted here.

Currently, It looks like there's a lot of potential in the vehicle parts offered within the tyflow update (I'm referring to things like the strut, widget, joint etc.) but some would need more options/parameters before we can completely replace our current rigs with a pure tyflow rig (I might make more specific feature request posts in the future on this topic if you don't mind  )

P.S. In reference to the ability to avoid inheriting scale through the tyParticleController, the red helper that was linked to the tyflow wheel scaled non-uniformly in a strange way which is visible in the screenshot, and I just wanted to avoid that if any geo is ever linked directly to the red helper

[tyFlow]

Fair enough - I will make a note to explore these improvements further.