PhysX Source Code Editing

Hi everyone. I only know the basics of programming - and I am NOT a super cool programmer of the 80th level. So do not rush at me with advice that I need to learn everything from A to Z. I am doing a project and learning in the process. But the problem that I encountered is not solved by the standard editor tools, and writing “my own” physics from scratch will probably be much more difficult than making edits to an already written physics engine.

I recently learned that there is access to the source code of the physics engine. I need that when two or more objects collide (collide only), no angular impulse is generated, or a zero angular impulse is generated so that the objects do not start rotating when collide.

I could use constraints, or just set the angular velocity to zero during a collision, but I need objects to be able to rotate when forces are applied to them, but not generate angular impulse when colliding AT THE SAME TIME. In several other communities, I was told that it was impossible to do this using the engine’s standard tools.

Can anyone explain me, how can i do this?

I think I have some ideas about how to do this without physics engine modification, past that here’s this: wiki.unrealengine.com

In order to assist you with the ideas, I need to know exactly what you mean by collide. If an object is spinning due to angular movement due to other forces than collision, then any protrusion from that object could collide with another object. How would you differentiate the different kinds of collisions and what would the resulting force be ? What if two spinning objects collided through opposite spins? unstoppable forces?

In the meantime, UsceneComponent::MoveComponent can be used to move a collision mesh on an object without physics but still with collision detection. You could have a duplicate collision mesh that is mimicking the movements of the physics collision mesh using MoveComponent. When you detect a collision with this secondary mesh, you can get the angular and directional velocity of the primary mesh, apply it to the secondary mesh and then enable physics on this mesh. Cache the current position of the secondary mesh and then tick. After tick, compare the new position of the secondary mesh to the cache position. That difference is now the new directional velocity of the primary mesh. And so on…

Just use collision channels to pull this off.

Is it really so difficult to correct the source code of a physics engine that you proposed such a slightly confusing method for solving the problem? It’s just that I’m a beginner in this (programming, physics). Perhaps, there is a lot I don’t understand, but is the second option proposed by you really easier and more efficient to implement than to go into the source code of the physics engine?

I just would like to simplify everything and not build big confusing structures and connections. In the project that I am doing, I will never need to calculate the angular momentum in collisions at all. Physics is tailored to look realistic, I understand, but I don’t need this particular part of “realism”. I just want to eliminate angular momentum calculation altogether. Directly. That this should not be in the game at all.

But, in any case, thanks for reading my post and responding. The same method with two meshes has already been suggested to me several times in Russian-speaking communities, but no one has suggested how to solve the problem directly without reinventing the wheel :smiley:

Firs of all.
You don’t really have access to physx within the engine unless you build the engine from source.

Replacing the dll to a baked editor is possible, I suppose, but it is very likely to break things… consider it a hack in fact. Also makes publishing harder because you don’t know if that DLL will get included as is or taken from something else (sort of likely actually).

Second of all.
What you want doesn’t require you to edit the physics system at all.
The system is already set up to allow you to adjust things on the fly.

Last.
As far as how you go about it.

Set up the objects to detect collision.
Set up an event for when the collision takes pace.
Check that the collided object is the one you want to remove the angular rotation from.
Override the angular values as you see fit.

I really don’t see anything that would make others tell you what you want is impossible.
In fact, you can just do all of that in blueprint without much of an issue.

Keep in mind that the angular value is still generating. You are just overriding it before it is applied.

As a whole, you probably shouldn’t be simulating the physics on this behavior, and why you want to we have no idea, but it doesn’t change the fact you should be able to without needing to edit anything at all.

At worse.
On the collision turn off simulate physics first.
Read in the values you want - maybe the object impact normal?
And manually apply only the momentum you need after turning simulate physics back on.

That’s assuming that for whatever reason the engine skips a beat and doesn’t manage to 0 out the momentum normally (which is unlikely as I had something similar set up without issues).

Also, anything else applying forces after the collision takes pace would normally rotate the item - which is what you wanted going by your post.

To do something else
like absolutely deny angular momentum after the collision until after the object is put to sleep, you would need to change the angular value on an ontick basis.

It is my fault that I did not describe in the post more precisely the behavior that I need.
I already understood that to zero the angular momentum at directly at the moment of collision. But the problem is that the collision can be prolonged. I am making a car on sphercast / linetrace. Two collision primitives (spheres) are used for the body. This is an off-road vehicle, and accordingly there will be more jumps, coups, stunts in the game. The car’s suspension is constantly working. When hitting a small obstacle (for example a stone), the car changes its rotation under the influence of the suspension force. But for example, when a car drives into a wall or collides with another object, it changes its direction. If I reset the angular momentum and angular velocity during a prolonged collision, the suspension will not work correctly. I’ve been working on this for over a year now, and I’ve tried so many different variations, and I’m out of ideas. I would not write here, and on the nvidia forum and on many others, if the solution to my problem was simple.

So far, I don’t see any other option.
No, though. There is one more, but I also have no idea how to implement it. It consists in writing a simplified version of collision detection, also based on a primitive of the sphere type. At the moment of the sphere overlap with another object, the mesh to which the sphere is attached would simply be manually moved through the transform in the opposite direction from the obstacle it collided with. I tried to use such a method, but I’m not very good at vector mathematics, so so far I also can’t implement such an option.
Plus, some of the UE features don’t work as expected. For example, in the HitResult structure, ImpactPoint does not display the coordinates of the collider’s intersection with the normal. Instead, it outputs the coordinates of the center of the collider with which the intersection occurred.

The impact point can be almost anywhere (first point of contact).
The impact normal is usually the result of that specific case.

To you that’s useless.
You just need the other actor’s forward axis (assuming it’s a head on) and to create an on-tick event that uses a line trace to detect when to turn itself off.
You move the object in that general direction while it can run the part of the ontick function.
You start with that, then you can implement different vector math to get you the correct value for slant hits.

Can you share a video or something?
From reading it seems that you are having issues when sliding along a wall- which with default physx has never been an issue for me.

The real problem is that you are trying to use the physx vehicle when the original game is literally just using the equivalent of a character capsule with very little if even any movement.

Read up on the memory limits used by the original game. It’s probably N64 or even less.

Try to get the same motion going with a regular character or, better yet, a pawn.
You should be able to play with the bounce values that physx uses and actually get pretty similar results.

Ready-made vehicle solution from nvidia is disgusting and absolutely does not suit me. I do not using physx vehicle class. It’s a pawn with static meshes, collision spheres and a spheretrace function for suspension.

I’m afraid not. The developer of the original game used two sphere primitives for collision detection. One for the front part and one for the back. Both primitives can rotate, but only under the influence of force, but not collision. But the principle of collision detection is different from what Nvidia provides. Therefore, I ask, is it possible to make a simple version of a sphere collider that would simply repel objects linearly and, if so, how?

If you don’t trust me on it being the same as for character capsules…

Take a video of a sphere bouncing with a grid texture on the sphere.

Then take a second video of the sphere bouncing with a solid texture.

What do you notice?

Now Imagine the sphere with the solid texture was the vehicle mesh.

In other words. You can literally just take the position of the sphere bouncing and apply it to the mesh position.
If you completely ignore the rotations the visual effect will he very similar if not identical to what your samples are, without any additional physics needed really.

Obviously, going from concept to implementation will be a bit more complex here.

My guess, based on what you wrote - which isn’t much - is that you can probably re-do the system without the spheres.

I can explain a bit on how:
A car is essentially 4 line traces off the corner of a box
that offset the suspensions up to a limit, then shift the vehicle’s base rotation.

Note right now that this behavior is reactive.
What’s that mean? It’s after the fact. And will only essentially work on a still object.
To get the behavior right, you have to trace and use the results ahead of where you are going by X so that the rendering can use the appropriate values.

This does becomes more of a an issue above 15kph - and it is particularly evident if you implement some sort of death loop. The car will literally appear to be inside the road if you don’t account for the trace shift.

With those simple traces in pace you’ll only be caring about what is directly under a “tire”.

You will have issues when your tire trace is inside a wall.
To limit this you simply add a hull convex or a sphere to take care of the collision of the pawn.

This isn’t physics really. It’s just to determine where and how the pawn can go. A box may be the better base to use here.

That should get you the basics.

The best material you’ll find on this is probably related to Gears.

Now you can try and come up with a solution based on the start sphere experiment and the basics of a custom vehicle setup.

There’s only about a million ways you could do this, including just bouncing a box instead of a sphere.
It may actually be more accurate in the long run even if you probably need sphiels at the side of the box since rounded corners will react way better collision wise.