Magnus effect

[Slick]

For simulating a spinning ball flying through the air I should be able to just add a force for the Magnus effect.

Is there any example code for this?

[Julio Jerez]

I did not know what magnus effect was, so I look it up.

It is the aerodynamics effect generated by wind turbulence when in contact with the rough surface of an object moving thought the air.

In newton spinning the object alone will not do it, but you can simulate the effect by making a joint.

Basically it is almost identical to the dry friction joint.

In the loop the joint calculat the plane on rotation. With in the normal on the angular velocity. If it is large than some value, tthat's one vector.
The secund vector is the direction of motion.
With those two vectors, take the cross product, and the will give you the vector perpendicular to both the motions.

With that vectors you calculate two points on the line defined by the direction and on the surface on the sphere.

With those two points you now calculate the speed of each point.
For a spring object one point will be moving faster that the other.

now, using the formula of air lift, which is function of the speed and density. You calculate a lift force wich will point along the line of that vector.

These two forces will oppose each other, the one with the point moving faster will be smaller, since will had a bigger vaccume, therefore there will be a net force pushing the ball alone the point the moves faster.

It should be a very eassy to implement.

Are you in 4.00?

[Slick]

Thanks for the answer. I am not using 4.0 but I think I will change for this project and progress.

I'm not sure that I will be able to implement what you explained but I will go through it slowly. From what I have read it seemed like just calculating a force and applying it would be enough but I have probably over simplified it.

It's a good time to move to 4.0 anyway. I'll report back.

[Julio Jerez]

I think you are totally correct.
The force can be best calculated in a force and torque callback. Not need for a joint.

The good part about 4.00 is that since it is cpp, the callbacks are now cpp classes.

For example the core and torque callback, transform cock, and all the others, is an object called notify.

So it is eassy to subclass from the base and simply overload the force to calculate that force and the call the base apply force.

This make much eassy to work with 4.00 than with 3.14

Also 4.00 happens to be far more robust and faster than 3.14 specially when running multithreaded.
The algorithm are the same, but in 4.00 the implementing are lock and atomic free.
This is the part that put a bottleneck in 3.14 that after 2 or three cores, they core are basically serialized in exclusive reads and writes. Now this is not the case and the performance grow linear with core count until asymptotically read the memory bandwidth limit of the cpu.

Anyway please try moving to 4.00
I am planning to make first stable release before the hollydays. And this time we are planning the first real gpu solver version.

[Slick]

I updated my pull from GitHub and built 4.0 today.

I need to study the samples to see the differences with 3.1x. I had reduced my wrapper to be very thin before so as to convert vectors etc.

I think it should be relatively straightforward. I'll be back with questions I am sure. The first demo with lots of stacked objects seems to run slower than the rest but is probably because of the number of objects.

Basically I need to work out the changes that 4.0 requires. I was already using the Newton c++ classes as much as possible.

[Slick]

I made some progress on this and am getting some effect that looks lifelike but also some parts of it not. For example the higher the spin it just goes up and up. I've also had times where it goes in circles.

My code for the force is:

Code: Select all

spinforce = dynamicBody->GetVelocity().CrossProduct(dynamicBody->GetOmega());
//spin = dynamicBody->GetOmega().CrossProduct(dynamicBody->GetVelocity());
//spin  = spin * (0.5 * air_density * lift_coeff * ball_cross_section / ball_mass);
//spin  = spin * (0.5 * air_density * lift_coeff * 1.0f / 1.0f);
spin *= 0.0005f;

I do see that the ball curves as you might expect. As you can see from commented out code I have been trying various snippets from the net.

Another slight problem is units. If I have a small ball let's say less than 10cm those units are a bit small for newton. So if I change my simulation scale to lets say cm instead of m I'm not sure how to adjust everything. Anyway, the scale part I am going to ignore from now.

Here is a clip:
https://www.youtube.com/watch?v=k6GdnXPgfJw

[Julio Jerez]

ok. here.

Code: Select all

spinforce = dynamicBody->GetVelocity().CrossProduct(dynamicBody->GetOmega());

you do need to normalized the vector so that you get a unit vector.

the aero forces only magnitude depends of the of the shapeform and the speed.
the vector is only to get the direction.

also remember to check that the margined is not too small, a too small magnitude means the spins is such that is parallel to the linear velocity so no side force.

on the amount of deviation, is bas on how heavy the object is, I have seen ping pong player put such huge pin on ping pong balls that is almost as if the ball moves backwards, there must be you tube videos about that.

BTW that video look quite cool.

on the small ball, you can set the substeps to something like 4, or higher.
for that kind of project would not make a difference.

later after I made the first stable release of 4.0 I will add some code utilities for controlling continue collision.
I have learned over the years that continue collision is in fact an overrate feature, with very specific functionality, but that requires a tremendous amount of effect, further more I also learn that most programmers actually turn it off for reason of performance and bad physics and instead they deal with is in a case by case.
so my solution will be to add a cople of function to handle it in case by case as well.

but for now, setting the number of sub sample higher should fix the problem and you will get a
high quality simulation.

[Slick]

As usual thanks for the insight.

I did think and try substeps 16 earlier but it ran a bit slow. Also, because I am not sure of the equations I wasn't sure what the problem was. I'll try 4 along with a smaller size and normalise vectors. I will also reread your notes and see if I can implement them.

[Julio Jerez]

16 probably too much, 4 should be enough.