How to define directions of friction

[JoeJ]

I think i have currently the same problem another user had years ago when working on a shufflepuck / bowling kind of game.
I made a very basic character controller. Capsule with up vector constraint, driven by external force.
Now the capsule does not move precisely along the input of external force direction. Instead it's direction has a somewhat random offset (about 30 degrees at most). It behaves like the floor would have anisotropic friction properties (it hasn't), which tilts the movement direction.

This is how i imagine to fix it:
Afaik, on contact generation, Newton calculates a primary direction of friction orthogonal to the contact normal. Mostly aligned to relative velocity. It also calculates a secondary direction perpendicular to this.
Now i want to rotate these directions so they align with the players reference space of movement, which is the camera in my case.
After that, i hope movement follows the desired input direction accurately.

Previously i did such things in some callback, e.g. changing contact velocity to make conveyor belts.
Now i guess that's a matter of subclassing somethinjg. Maybe ndContactNotify? But i'm not sure...

[Julio Jerez]

Yes that's how the friction directions are produced.
you can look a the TireJoint, they
Manipulate the friction direction of the tires So that they aligns with the tire frame and not with the contact relative velocity. That's similar to what you describe.

Basically you can get the contact map, and for each contact, you can rewrite the however you want.

I believe the player capsule who's is a sdk object now, does something similar, but I do not remember.
Has you tried the player capsule. I think it does what you seek, and can be customized to do what you want.

The play capsule, is not trivial, it uses a lcp solver to negotiates one way contacts, and also interact with the world. The player actually moves by friction the contact patch. So the contact has to be aligned to the desired direction.

It also has logic to predict steps, corners and stuff like that.

[JoeJ]

Following the tire example i got it to work easily, thanks.

But now my controller is a ndModel, so i'd like to to move adding the external force from body notify to the ndModel, so everything is one one place.
I guess i can do this in the Update() method as well, but let me know if i should use PostUpdate() or if there is some other catch i should know.

I'll look at your controller later. For my current needs the dumb simple thing is enough.
But i noticed a collision bug in your simple player demo.
If you start it up, you see a wall in the distance, with stairs on the left.
Go below the stairs to the corner, and you can go through the wall.
(There are issues with animation import, which asserts. And i still did not yet update. But i guess it's not that.)

Another issue i saw:
The class ndContactNotify has D_MSV_NEWTON_ALIGN_32 in front, but no D_GCC_NEWTON_ALIGN_32 at the end. Looks like you forgot to add this.

[Julio Jerez]

Yes you place in a model, and that gives you hook for doing g stuff to the model.

An analogy of the model to a 3d render pipe line is.
A render pipe line had stages.
Vertex assembly,
Vertex shader
Primitive assembly
Geometry or texelarion, or now nest shader
Rasterization
Pixel shader
Pixel color

There could others stages.

In the physic, this pipe line is.

External forces,
Bradphase pair update
Contact generation
Model update (new for newton 4)
Contraint solver fir internal forces.
Momentum update
Integration update
Sleeping update
Post model update
Post bodies update

As you see, model update happen after collision and before solver, this is the place for doing physics related stuff.
The d model would be like a mesh shader, you can associate, bodies. Joints, collision, and application stuff all at one.
The compcpt of model I introduced in 4.00 to simplify the modeling.

Post model update, happen after all the phys is applied,
This is the place for the app to apply any kind of game relate stuff, a typical example would be update the visual model anymation.