Where best to locate your own physics?

[SeBeQ]

When it fails PhysX, where best to insert own code of physics? The Tick, or elsewhere?

[SeBeQ]

There is no such a place?

[Wyldhunt]

If you want to script your own physics engine, you'll need to script a custom DLL to do all of the physics work and then use DLL Bind to call the functions every time you want anything non PhysX related to happen.

Of course, Nvidia has spent several years working on UDK's PhysX engine, so it may take you a while to script something better.

[ffejnosliw]

You don't have to do custom physics in a DLL. Granted, I imagine you would see performance benefits from doing so. But, you can do physics calculations in UnrealScript. And even if you use DLLBind, you still have to call the functions in the DLL for performing your physics calculations from somewhere in your scripts. So the question remains...where is best to do that?

I think the answer depends on what you are doing, but in general something that needs to update every frame (which physics would usually fall into that category) would be done in the Tick() function. If it only needs to be update at specific intervals, a timer function would work well.

[SeBeQ]

Thanks!!! Yes, I want to do it in UnrealScript.

I do not intend to create an advanced physics. PhysX does not handle small objects. When it hit it pass through the wall. Larger does not (well, maybe sometimes).

[Wyldhunt]

Aha. Yes. Sorry, I was in a hurry and missread your post. I thought you wanted to try and overide 'all' of physx. lol

Anyway, yes. ffejnosliw is correct.

Although, if your problem is that very small objects are passing through walls, it may not be directly a PhysX problem.

I remember reading a thread a while back where someone was having a problem with a small mesh that had no collision. No matter what they did, their small object would not store a collision model or react to other collision models. They could scale it to be as large as a house in UDK and it would have the same problem.

The answer turned out to be using 3ds max to scale it a little bit larger. Then UDK managed to recognize it and give it collision. Once it worked in UDK, they could scale it back down and I think it would keep its collision.
My memory fails me as to the details, but you might try something like that. Scale it up in your modeling software and re-import it. Then scale it back down in UDK. May save you a lot of scripting if it works. Especially if you plan to have a lot of small objects.

[SeBeQ]

Hmm, I will try and do so. Although small objects sometimes bounced well.

[SeBeQ]

After several tests with the idea of reducing the scale of a large object, it was OK. But there is always a BUT:).
Minimized object behaves as if its weight was like before scaling. So move slowly.
With a combination of velocity, becomes the object acceleration and ... object passes through the walls again.

[Wyldhunt]

So, passing through walls seems to be linked to the objects velocity? That's interesting. I wonder if it has to do with the object moving too far in a single tick and not registering that it is at a collision mesh. How fast are these objects flying? Do you know what your frame rate is in your game?

[SeBeQ]

Very fast, in the real world can say, throw the ball like baseball. FPS = 60 FPS in game. You can try. Find object in Generic Browser (best small Static mesh), convert to Kactor and fun with physic gun.

[Blade[UG]]

The way I understand it, is that if a physics object is going so fast, that it can be fully on one side of an object in one Tick, and then fully on the other side of the object in the next immediate Tick, it will pass through that object.

It is very, very likely that you should find a better way of doing your movement, if this is a problem. :) (like, not trying to use physics for bullets)

[SeBeQ]

Hmm ... Tick That is not a good solution? During the frame generation can happen is the same as in normal KActor. Need a dynamic object with a bunch of speed and certainty that the object of bounces. Imagine a game where the golfer strikes the ball and it disappears somewhere. (He takes the new :) )

[Wyldhunt]

You would need to figure out how far it can travel in 1 tick. Send a ray trace or something to see if there is collision closer than its 1 tick travel distance. If there is a collision, then script a custom function to make it bounce.
As long as it is travelling far enough to pass the collision in 1 tick, then it never actually touches the collision, so there is no PhysX.

[Wyldhunt]

I did some math to see just how easy things could jump past a collision mesh at high speeds. For my example, I assumed 1 Unreal Unit = 2 Centimeters (About what Epic tends to use). If an object were travelling at 160 Kilometers/Hour at 60ticks/second... then that object would be moving 37 unreal units (74cm) every tick. So, it is theoretically possible for something as large as 35uu to pass through a planar collision surface if it's travelling at 160kh with 1uu=2cm size conversion at 60fps. Given, that 35uu object would have to be lined up perfectly. But, it could. anything above 15uu or 20uu would probably be fairly stable.
If we slow it down to 96kph, then it moves 22uu every tick.
I'll have to keep that in mind when I'm designing stuff. I never stopped to think about how that could bypass collision.