Manually calculate bounce

[tiresius]

Hello everyone-

I believe I have run across the phenomenon described in the NewtonMaterialSetContactNormalDirection help doc.

I have a marble player which can land on a "bouncy" tile. A bouncy tile is just a material that is set to have a high elasticity so the marble bounces. These tiles are part of the level and all tiles are geometric shapes like planes and slopes, nothing fancy. I've found that when the marble bounces near where two tiles meet, sometimes the bounce direction is a little incorrect. Is that the contact normal discrepancy that NewtonMaterialSetContactNormalDirection speaks of?

This is not a show stopper, I can have slightly incorrect bounce with the game... but I can see a player getting annoyed if they bounce on a perfectly flat tile and don't continue in the exact direction they were going in.

So here's my next question. I would like a perfect bounce, but by using the DBPro Newton wrapper I don't think I can use the above function to correct this very easily. One thing I can think of is to change the elasticity of the bouncy tile to nothing (like a normal tile) and calculate an artificial "bounce" vector myself by grabbing the collision details and placing a local impulse (or setting the marble's velocity vector) manually.

I can retrieve the contact position, the player position, the normal vector/speed, the tangent1 vector/speed and the tangent2 vector/speed. I don't really know what the tangent vectors are for (I haven't seen the tangent2 reporting any values in my tests??) so if you can point me to a collision tutorial somewhere online explaining these values that would be helpful.

Since I have the normal vector, and it may be incorrect, I'm assuming with the contact position and the marble player position I can determine a new normal vector. But I probably need to know how to include the two tangent vectors since Newton would no longer do the bounce for me?

Is this possible to do?

Thanks for any help!

[Julio Jerez]

this problem had being fixed in 2.00.

In the special case of a sphere you can just tke the distance from the contact point to the sphere center and normallize it.
and set the as sphere conntact normal, for each contact.

[tiresius]

this problem had being fixed in 2.00.

I was expecting you to say that! Although the function I mentioned still exists in the header, perhaps it has other uses?

In the special case of a sphere you can just tke the distance from the contact point to the sphere center and normallize it. and set the as sphere conntact normal, for each contact.

I was hoping to avoid this but I suppose since several contacts can be found between a sphere and an angled plane, the only real way to do it is through the callbacks for each contact. So having a single force/velocity vector solution is not possible?

For the contacts would I be using NewtonMaterialSetContactNormalDirection inside one of the the collision callback functions? Which one should this go into? NewtonContactBegin, NewtonContactProcess, or NewtonContactEnd ?

Thanks for the help! Sorry for all the basic questions. As strange as it sounds, I haven't worked with callbacks much.

[Julio Jerez]

In the special case of a sphere you can just tke the distance from the contact point to the sphere center and normallize it. and set the as sphere conntact normal, for each contact.

I was hoping to avoid this but I suppose since several contacts can be found between a sphere and an angled plane, the only real way to do it is through the callbacks for each contact. So having a single force/velocity vector solution is not possible?

no you do it for each contact as you get them in teh call back, in the ball hit a colner teh solve will calculate teh repsponded alon the righ direction, regarless if multiple contacts.
Basically it will bounce along the efective weightd contact formed by the ball velocity and the number contacts in the collision, it is what the solver does.
As long as the contact are good represenation of what the collision is, the solution will be relasistic.
So for a sphere rectifing each contact by making it pass by the center of the sphere is right, because on a the surface normal of all point on the surface of the sphere are sphere radios.

[tiresius]

That makes sense. Thanks Julio.

I found an example in the demo doc that uses that function in a callback for a player object. That should meet my code-monkey needs. Trick will be to make it work clean in the 1.53 wrapper, maybe with userdata or some other stored flag so it knows the collision is for a sphere shape. Thanks again.

[Julio Jerez]

I do not understand why you people insist in usin and SDK that is soo old.

I was criticised because I took too long with 1.53 and now that there is a replacement people insist in uing the old SDK.

[JernejL]

The big problem is with the wrappers that are outdated and those communities have nobody skilled enough to update them properly.

But i have a idea - we could make a easier conversion path from 1.53 - with using a intermediary library that emulates some of the changed newton calls and callbacks, the only really big changes were added parameters and the material callbacks, + auto-freeze changes, and that shouldn't be dificult to translate without too much overhead? most of functionality would still be mapped 1:1 to the "real" newton 2.0 dll.

But still, the most proper path would be to upgrade those wrappers.

[Dave Gravel]

The material callback is a major change for my oxNewton, I have need to rewrite many parts.
The good thing, I have and it have optimize the way to deal with material...
I have need to update many others parts after this too but nothing so complex.
It's not super long to do all changes, the problem you need to have the old code and know what you do.
Some engine have old wrapper and new users need to learn this code before update it, many is not uptodate .
I think when you have a personal game work, the best is to write a sort of wrappe only for your need.
Not something over all the big 3D,2D system, because both can come updated and it can come complex.
Now newton is pretty simple to implement, you don't really need to wrappe it.
You just need a data object that you can share with newton and with your 3D,2D, and the rest is physic math and your imagination...