Newton body's "bullet" mode

[VeTaL]

As i remember correctly, in Newton, there is function that adds additional calculations for fast-moving bodies, like bullets.

For example, if i fire little entity now (like bullet), sometimes it fells through walls and level (but sometimes not).

 

It was called like LongCollisionMode, or something like that, i really forget it

[macklebee]

its called SweptCollision

 

It used to be pretty bad with objects going through each other even with Swept Collision on, but that has been rectified in Newton 2.22.

[VeTaL]

http://www.youtube.com/watch?v=OwrPA7n9ISg

When i fire cube into scene objects, cube collide with oildrum, fall on the floor and lay still.
When cube dont collide with oildrum, it falls through floor.

PS: i forgot to enable debug mode: physic bodies are in 10 times smaller than graphic cubes.

[Mumbles]

How thick is the floor? If the bullet is really small, AND the floor is really thin they may pass through each other, even if ContinuousCollision is enabled.

[macklebee]

Download the Newton SDK 2.22 version and use the Newton.DLL from it. This issue was rectified in that version and at one time LE was using it. For some reason either we have reverted back to a previous version in LE or for some reason a later version of the Newton dll is not working correctly. As long as the "bullet" is set with swept collision ON it works fine.

[Mumbles]

I'm on 2.24 but haven't tested that in a while. But as I understood it.

 

ContinuousCollision off:

Fast moving bodies may pass through each other if one body can move inside another with just one update call (if the body is half in, half out then the collision is detected and the bodies react accordingly).

 

ContinuousCollision on:

Fast moving bodies may no longer "sit inside" another body. If one body is sitting inside another body then it will be interpolated back to the point at which it first collided (with the velocity interpolated as well to allow the correct reaction to take place)

 

But if one body has passed through another AND exited on the other side (because both bodies were so small), then it is back in a valid position. Yes, for realism it should be sent back to the point it collided and reacted there. But what if it's two bullets colliding with each other (no one said one of the bodies have to be static) mid way through an update call but have fully cleared each other's overlap zones by the end of the update call. That would be so expensive to detect and to calculate the resulting reactions. My point was based on that point that Julio though it was a waste of resources and allowed to happen regardless - I might be wrong on that one though.

 

I also thought Julio recommended using raycasts for bullets because they were always guaranteed to detect the hit. and if it does hit a player then you could try and calculate the impulse to add to the body (Because you know the "velocity" of the ray)

[macklebee]

I went through this exercise already 6 months ago. I was the one that was providing demos to Julio so he could rectify the issue.

 

As stated for the newton 2.22 version from Julio:

It also fix a bug with continue collision when convex shape has a center of mass far away from the geometrical origin. Sweep collision was predicting the collision point by plotting the matrix origin, but when the center of mass was relatively far away from the origin, the path of the shape is not the path of the origin. This bug was bad especially with small convex hull shapes travelling at high speed. The bug is fixed by making the shape follow the path of the center of mass and not the path of the matrix origin. Bug found by Leadwerk team.

 

When I suggested to Vetal to use the Newton.DLL from Newton 2.22 SDK, it was based on actual proof of it working and not just a guess. Using the current newton.dll that comes with LE 2.4 right now, I was getting the same results as Vetal. I switched to the dll from Newton 2.22 and ended up with this:

 

I also thought Julio recommended using raycasts for bullets because they were always guaranteed to detect the hit. and if it does hit a player then you could try and calculate the impulse to add to the body (Because you know the "velocity" of the ray)

yes, to simulate an actual bullet being fired, the raycast method is the way to go... but I was answering to solve Vetal's issue and any other issues anyone would see with this type of interaction.

[VeTaL]

Looking nice, macklebee.

I just want to implement both type of bullets: raycast and physical... So, i'll try Newton 2.22, but its strange that Josh didnt add it to Leadwerks.

 

//It also fix a bug with continue collision when convex shape has a center of mass far away from the geometrical origin.

"Has a centre of mass far away". I saw this note, but didnt think that its important as my bullets have center of mass inside.

[VeTaL]

PS: Newton 2.25 features looking nice, especially about multithreading.

[macklebee]

Like I mentioned above, at one point LE was using this version 2.22. Somewhere either in LE's myriad of SDK updates or Newton's updates, this was lost.

 

PS: Newton 2.25 features looking nice, especially about multithreading.

 

yes, but it won't matter... the flavor of the week is to use anything other than newton for LE3... granted the same people complaining about how slow newton is now will be also complaining about the crappy unrealistic physics behavior from whatever other physics engine is used in LE3 6 months from now...

[macklebee]

Also, I have tested this successfully with the cube scaled down to 0.04m^3 (~1.5inches cubed)... anything below that it gets a little funky with the physics... but at that size i would suggest just using raycasts since something that size would be difficult to see anyways...

[VeTaL]

Thanks for help, macklebee

[macklebee]

no problem... i thought it strange to see this issue occurring again after it was finally fixed...

 

Only Josh can say what version of the newton.dll he is supplying... which might help if that information was included in our versions.txt file...

[Josh]

Uploaded newton.dll 2.22.