Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Aerodynamics for non cloth
#1
Do I understand correctly from documentation that only cloth has simulation of aerodynamics from particle velocity?
Is there a way to enable this, or do I need to do this by code or apply fake "wind" each tick? E.g. apply aerodynamics on bones for ears when moving a character.
Reply
#2
(24-04-2025, 08:41 PM)Jawsarn Wrote: Do I understand correctly from documentation that only cloth has simulation of aerodynamics from particle velocity?

Hi!

No, cloth, ropes, rods, fluids all are affected by wind. Cloth is just used as an example in the docs. See the "ComputeRopes" sample scene for an example of ropes affected by wind. Or if you change the solver's "wind" vector in the "CharacterTentacles" sample scene, you'll see the character's limbs/tail affected by wind.

There's an "Aerodynamics" section in the ObiBone component that lets you control how it's affected by wind.

(24-04-2025, 08:41 PM)Jawsarn Wrote: Is there a way to enable this, or do I need to do this by code or apply fake "wind" each tick? E.g. apply aerodynamics on bones for ears when moving a character.

Even if you couldn't apply wind, you can still apply forces or accelerations. Note you can use force zones to apply wind, force, or acceleration.

The difference between wind, force and acceleration is that wind takes into account the shape and mass of the object: a cloth directly facing the wind direction "catches" more wind and is affected more than a cloth that's perpendicular to it. Similar thing applies to a rope or rod. The surface of a fluid is more affected by wind, since it is exposed to it (while particles inside its volume are shielded from it). Heavier objects are less affected by wind that lighter ones.

Forces take into account mass as well, however affect the object regardless of its shape. And finally accelerations disregard both shape and mass and just change the object's velocity.

For something as simple and relatively small as ears, it's unlikely you'll notice any difference between wind and forces.

kind regards
Reply
#3
Ok!

From when I'm testing if I move the attachement transform of a rope (that is child of solver), it will not induce aerodynamic forces as I would expect - but only when I add wind. From the documentation it seems like aerodynamics for cloth moving particles on by default? Maybe I'm misunderstanding something. 

The use case is large ears almost as big as head. So we would like the wind to bend them backwards when running etc. The documentation says that one should put solver on the character transform. Is the intended way to provide wind forces from character movement to apply wind forces manually? And do I undestand you correctly that you have seperated the forces so that regular movement of particles does not induce aerodynamic forces? Generally any velocity difference with respect of shape cause this. So does that mean aerodynamic constraints are only active when we use wind forces?

Thank you for your time,
Reply
#4
(25-04-2025, 12:34 PM)Jawsarn Wrote: Ok!

From when I'm testing if I move the attachement transform of a rope (that is child of solver), it will not induce aerodynamic forces as I would expect - but only when I add wind.

Aerodynamic forces take effect even in the absence of wind (wind set to zero). However make sure you're not confusing wind with inertia (what would happen when the character starts/stops running and the ears flop accordingly).

(25-04-2025, 12:34 PM)Jawsarn Wrote: From the documentation it seems like aerodynamics for cloth moving particles on by default? Maybe I'm misunderstanding something. 

Aerodynamics are on by default for all actors.

(25-04-2025, 12:34 PM)Jawsarn Wrote: The use case is large ears almost as big as head. So we would like the wind to bend them backwards when running etc.

In the real world that would happen mostly due to inertial forces, not wind: set the solver's world space linear inertia scale to something else than zero.

If you're completely still and then start running, your ears would want to stay still so they'd flop backwards. Similarly, when you stop running your ears would want to keep moving so they'd flop forwards. While running at a constant speed (no acceleration), the ears would be completely still.
Ears (no matter how big and floppy) are usually not light enough to experience any significant drag forces just from their owner walking around, assuming regular - not extremely dense - air.

(25-04-2025, 12:34 PM)Jawsarn Wrote: The documentation says that one should put solver on the character transform. Is the intended way to provide wind forces from character movement to apply wind forces manually?

I still get the feeling that what you call "wind" is just inertia. Inertia is controlled via the solver's inertia scale sliders, which allow you to independently control linear and angular inertia.

(25-04-2025, 12:34 PM)Jawsarn Wrote: And do I undestand you correctly that you have seperated the forces so that regular movement of particles does not induce aerodynamic forces? So does that mean aerodynamic constraints are only active when we use wind forces?

They're not separated, moving particles are also affected by aerodynamic forces even in the absence of wind. The thing that matters is the relative velocity between the particles and the wind.

Important to note here: solvers perform simulation in *local space*, so moving the solver around rigidly transforms all particles inside - not affecting their velocity and hence, not giving rise to any aerodynamic effects.

kind regards,
Reply
#5
No I'm not confusing it with inertia.

For games you somtimes want to exaggerate the physics a bit, especially if you run fast in this case to get the feeling of motion.

I think you are wrong in your statement "While running at a constant speed (no acceleration), the ears would be completely still.". Air drag is from the formula F = 0.5 * ρ * A * C * v^2 , where v is velocity in medium with density ρ. This is simply tested by holding at the end of a paper and moving it through the air. It will be bent throughout the whole movement irregard of initial and final inertia. This is not what I'm experiencing when moving my attached transform with a rope that has small mass and high air drag coefficient, once I add a bit of wind through solver it moves a lot though.
Reply
#6
(25-04-2025, 04:45 PM)Jawsarn Wrote: No I'm not confusing it with inertia.

For games you somtimes want to exaggerate the physics a bit, especially if you run fast in this case to get the feeling of motion.

I think you are wrong in your statement "While running at a constant speed (no acceleration), the ears would be completely still.".

Hi,

I was talking about inertial forces when stating that: if you’re on a car moving at a steady 100 km/h, you don’t feel any forces acting upon you: only if you suddenly accelerate or brake. This is the same thing that happens to actors inside a moving solver in Obi.

Obviously if you factor aerodynamics in, or any kind of external drag force proportional to velocity then then there’s a force being applied: the force you’d feel while A) stationary inside a gust of 20 km/h wind and B) running at 20 km/h with no wind is the same. I was simply pointing out that ears of any kind (or any other body appendage) aren’t light enough for aerodynamics to normally have any effect on them, but I understand you might want to greatly exaggerate its effect. In order for this to work in Obi, actors have to move relative to the solver.

(25-04-2025, 04:45 PM)Jawsarn Wrote: This is not what experiencing when moving my attached transform with a rope that has small mass and high air drag coefficient, once I add a bit of wind through solver it moves a lot though.

I’m unable to reproduce this: moving a rope in absence of wind with high drag does have a noticeable effect. Make sure the transform you’re moving is not the solver itself, as that will move the rope as well while excluding world-space velocity effects. Could you share a video of this?

Nevertheless, note that in the case of a character you’ll need to take the solver out of its hierarchy and keep it static (that is, perform the simulation in world space) for this to work, otherwise particles won’t have any velocity relative to the solver and aerodynamics won’t have any effect.

If this is an inconvenience in your case, I can add a option to consider the solver’s velocity when calculating the relative velocity during aerodynamics. This would allow aerodynamics to work in absence of wind even when particles are not moving at all relative to the solver.

Kind regards,
Reply
#7
Thank you for clarifying.

What I'm moving is the attached transform that is child of solver. See video.
https://drive.google.com/drive/folders/1...sp=sharing

Quote:Nevertheless, note that in the case of a character you’ll need to take the solver out of its hierarchy and keep it static (that is, perform the simulation in world space) for this to work, otherwise particles won’t have any velocity relative to the solver and aerodynamics won’t have any effect.

Do I undersand correctly that I would have to parent the character to the solver outside then? A tangential question there is it better with fewer solvers in the scene? Or performance overhead to keeping the whole world inside one solver (actors and not, apart from unity hierarchy perf).

Don't you think calculating the forces manually to apply as wind is a better approach then if possible? At least for managing scene stuff. (Or just the solution you may add below when added)

Quote:If this is an inconvenience in your case, I can add a option to consider the solver’s velocity when calculating the relative velocity during aerodynamics. This would allow aerodynamics to work in absence of wind even when particles are not moving at all relative to the solver.

This seems to be a good option that would solve for the effect I'm after for the ears right now.
It alone would not "solve" the general issue I'm observing with inter solver particle movement though (if I'm correct in what I'm observing that is).


Thanks a lot for the assistance!
Reply
#8
(25-04-2025, 08:21 PM)Jawsarn Wrote: Thank you for clarifying.

What I'm moving is the attached transform that is child of solver. See video.
https://drive.google.com/drive/folders/1...sp=sharing


Do I undersand correctly that I would have to parent the character to the solver outside then?

Yes, the solver should be outside the character’s hierarchy, so that the root can move around “inside” the solver. I’ll add an option so that this isn’t necessary though, so if you can wait a couple days for me to implement it it’ll not be necessary to modify your current setup at all.

(25-04-2025, 08:21 PM)Jawsarn Wrote: A tangential question there is it better with fewer solvers in the scene? Or performance overhead to keeping the whole world inside one solver (actors and not, apart from unity hierarchy perf).

There’s not much of a difference. Solvers enqueue jobs that are then performed in parallel by the appropriate backend, doesn’t really matter if the jobs came from 1 or 5 solvers.

Scene colliders are only kept and processed once regardless of the amount of solvers in the scene, so not much of a difference in that department either.

Kind regards
Reply
#9
(27-04-2025, 11:25 AM)josemendez Wrote: Yes, the solver should be outside the character’s hierarchy, so that the root can move around “inside” the solver. I’ll add an option so that this isn’t necessary though, so if you can wait a couple days for me to implement it it’ll not be necessary to modify your current setup at all.

Thank you, this works for me.

You said this previously,

Quote:I’m unable to reproduce this: moving a rope in absence of wind with high drag does have a noticeable effect. Make sure the transform you’re moving is not the solver itself, as that will move the rope as well while excluding world-space velocity effects. Could you share a video of this?
Did you have time to watch the video I sent and could confirm what I see is the expected behaviour? It seems contradict what you wrote here. I tested if I add a sibling cloth with simlar attachment transform with same drag, it behaves as expected, leaning to a 45 degree angle against the direction, to be affected when it is moved by being pulled by the attachement. As I understand the addition you're making does not make this part correct (if not a problem with my setup).

Thank you
Reply