Need a little help porting some 2.35 code to 3.14...

[Akira1364]

I'm in the process of porting a single-file physics implementation that originally used Newton 2.26 - 2.35 up to Newton 3.14. I've been mostly successful so far, but I'm down to 3 functions that do not exist in 3.14:

NewtonSetWorldSize
NewtonBodySetAutoactiveCallback
NewtonBodySetFreezeTreshold

Basically, I'd just like to verify whether these function will need to be replaced by something else in order for the application to work properly, and if so, what would the appropriate replacements be? Thanks in advance!

[Julio Jerez]

NewtonSetWorldSize
NewtonBodySetAutoactiveCallback
NewtonBodySetFreezeTreshold

these three function are no longer part of the engine, you can just ignore them.

The only one that might give you problems is NewtonBodySetAutoactiveCallback, if you are building game logic around it. The way it works since newton 3.xx is that the force and torque callback is called for all bodies even if the are sleeping. There you can check is the body is sleeping or not and you can your own wake up or sleep logic based on your own criteria.
Since force and torque call back is always called, even for sleep bodies, there is not need for those other callback.

The last NewtonBodySetFreezeTreshold, in newton 3.00 object simple goes to sleep when they are on steady equilibrium. not need for sleep threshold.

the first one, Newton not longer has world size, you can check for that on the force and torque call back if you want.

[Akira1364]

Awesome, this was very helpful. Thanks a lot!

[Akira1364]

One more question... it appears that NewtonCollisionCollide now has two additional parameters: "AttributeA" and "AttributeB". However, these are not mentioned in the current documentation... even the comment block in the source code itself does not include them. What exactly are these parameters used for?

[Julio Jerez]

each collision primitive shape has a shape ID.
This id represents the entire shape because collision primitive are atoms, (they do not have subparts)
however you have a collision that is made of multiple collision primitives. Typical example is a compound collision.
Collison trees and terrains are also made of convex primitives, but for memory saving reason the data is no sore as convex primitive instead is stored in the format that is best for the collision shape, then the code generates a convex polygon on the flight that is passed to the standard convex vs convex collision.

when you made a collision tree, for each face you pass a face attribute, you can also pass an attribute array for height field, and you can set a collision ID for any convex shape.
those IDs are reported by the collide function. you can use them to make sub material decisions in your call back.
of course when you just do convex vs Convex it appear redundant by if you did convex vs Terrain or collision tree, then you find that it makes sence.

[Akira1364]

Thanks again!