Well, in fairness, 512 is kind of an extreme framerate.
What happens if you choose something more reasonable, say, if you limit fps_max to 120 (kind-of "60 FPS for each eye in 3D")?


I'm not very knowledgable on PhysX, I'm afraid, so I don't think I can help you. Sorry! Consider this, then, a free bump to bring attention to this once more.

thank you all guys for your time, but at the end I think that this is some kind of physX implementation bug, cause the same script with c_move works great.

Hi 3run,

This kind of problem is quite difficult to solve, as I already encontered it. I think that the problem come from some numerical errors when converting coordinates between gs and physX (Gs values are scaled down when passed to a physX function) and the difference between physX update rate and gs fps. Even some physX 3 demo (vehicle) have jittering problem and they solve this using a lookup table. Perhaps you can also try to change the way you detect the ground. Hope that helps you to find a solution.

Thank you for a feedback man. I faced an other problem (today) when I was trying to make PH_CHAR change it's BBOX size, to make player crawl. I know that I need to unregister entity from the PhysX before changing the size of the BBOX and then, register it back after a frame, that's what I do as well. I used physx visual debugger to see, if my script works. Problem is, that I only change the "min_z" size of the BBOX, but PVD shows me that shape has changed from both size (symmetrically). I've made a picture to show you the problem:

I guess this is some kind of problems you are talking about (converting coordinates between gs and physX). But how could I fix them myself?

edit: reuploaded image!

Hi,

I can't see the picture
What I can tell you is that it is not a problem . When you create an shape for a character controller in physX, you need to :

• AABB : Half forward, half width, half height
• Capsule : height, radius

So, they will always be centered to you actor . One way to overcome this is to add some configurable offset inside the plugin (I added this to the physX 3 plugin), so every time a physX transform is applied to the entity the offset will be used to have the correct position for the rendering entity. Another way, possible with the actual plugin (and also possible in mine) is to use a simple invisible box to be registered as the actor's shape, and use your complex geometry for rendering only, and apply the offset yourself .

I've uploaded image into "imageshack.us", please take a look at it now.
I can't understand this lines, could you please explain them again:
And about this:
That's the way I do it now, I use simple box model (without a skin, and it's invisible, but sometimes I make it transparent for debugging) for collusions, for visuals I attach additional model (it's passable). Then via script I change the BBOX size of that invisible (transparent) model. Before changing the size (I change only "my.min_z", to make player crawl) of the BBOX I unregister entity (PH_CHAR) from the physX and after changing the BBOX I register it back with same parameters (PH_CHAR and PH_CAPSULE). But I get results which I tried to draw on the picture above BTW I've drawn an ellipsoid not the capsule, cause my drawing skills suck

Hi,



I just wanted to say that when you create a shape for a character controller in physX, you only define its dimensions, not the position of its bounding box. GS BB are then used to define the dimensions of the shape. For a capsule, height = (max_z + min_z) / 2. For a Box halfHeight = (max_z + min_z) / 4. These shapes are then always centered. When you modify one value of the bounding box, the two extents will be changed symetrically from the origin(center) of the shape. Hope that is more clear.

Hi

Now I understand, thank you mate. Can you see the picture I've posted above now?

Yes, I can see it.

I've sent an example of this problem to the Support Team. You can also take a look at it here:
Problems with PH_CHAR in 8.40.1