Movement Controller Intermittent Physics Issues + Slope Handling Problems

[vega]

Hello,

I've been running into some issues with the physics/movement controller and wanted to report them along with a reproducible example in hopes that we can get this fixed:

Issue 1: Intermittent Physics Breakdown on Game Start
Roughly every fifth or so launch of the game, the movement controller completely breaks down, and characters ignore or clip through walls and slopes. Restarting the game usually fixes it, but it keeps happening.

Issue 2: Slope Handling Causes Ground State Flickering
On moderately steep (but still walkable) slopes, like clipped stairs, the controller rapidly bounces between "on ground" and "in air" states. This causes jittery movement and breaks any logic that depends on a stable ground check.

Steps to Reproduce:
I've attached a stripped-down version of my project source code that demonstrates both issues. For Issue 1, you may need to restart the game a few times to trigger it. For issue two, just run the game and try to walk on the taller, steeper slope.

Any insight or help would be greatly appreciated. Happy to provide more details if needed.

Thanks!

mesa - stripped.7z

[Josh]

Thanks for the detailed report, will investigate this...

[Josh]

Some strange things about this:

• It seems to happen only with wedge shapes.
• If one wedge shape fails, they both fail, always.
• A box shape in the same scene never fails.
• The player bounces up and down on large ramps, but a smaller ramp with the same shape has no problems.

Is this consistent with what you have seen? I think the most likely explanation is the Newton physics convex hull class is calculating an erroneous bounding box.

 

[Josh]

Is there anything special about the large wedge? Was it made using the carve tool? I tried creating a new wedge the exact same size, and that one works perfectly. If I step on your wedge, the player bounces up and down and I hear the footstep landing sound, but my own new wedge works fine. 

[Josh]

This will take some more time to figure out...

[vega]

Can confirm that:

- The smaller wedge is fine and does not produce issue 2.

- If issue 1 occurs, both wedges break.

- The wedge was created using the “Create” menu like normal, there shouldn't be anything special about it.

I’m not sure if this only happens with wedges, but i assume so. Will test this in an hour or so when i get on my PC. 

[Josh]

You don't need to do any more testing for now. I found where the problem is, but I don't see why it is happening yet. Will continue work on this tomorrow.

[Josh]

I was able to produce the error once when compiled from source, in a simple program, so that eliminates a lot of possible causes.

The problem is with the wedge itself, not the player, because I added code to recreate the player when I press a key, and the new player has the same problem...

[vega]

That sounds very odd. I hope it's not going to be an endless goose chase ^^

[Josh]

I will find the cause. Updating Newton now, and if I have to file a report with Julio I will.

[Josh]

The slope standing issue seems to get fixed just by recreating the wedge. That doesn't explain why it is happening of course.

The disappearing collision issue is much more serious. I recompiled Newton Dynamics as a DLL, which is its default configuration, instead of compiling the source code straight into the engine. Then I ran my test app 100 times and couldn't produce the error.

Originally one of my goals was to eliminate DLLs, but I don't think that's a very good goal. Stay tuned for an update.

Pasting my test code here for later use:

#include "Leadwerks.h"

using namespace Leadwerks;

int main(int argc, const char* argv[])
{
    //Get the displays
    auto displays = GetDisplays();

    //Create a window
    auto window = CreateWindow("Leadwerks", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR | WINDOW_HIDDEN);
    auto ui = CreateInterface(window);
    ui->background->SetColor(0,0,0);
    window->SetHidden(false);
    window->Activate();
    ui = nullptr;

    //Create a framebuffer
    auto framebuffer = CreateFramebuffer(window);

    //Create a world
    auto world = CreateWorld();
    world->SetGravity(0, -30, 0);
    world->SetAmbientLight(0);

    //Create the player
    auto player = CreatePivot(world);
    player->SetPhysicsMode(PHYSICS_PLAYER);
    player->SetMass(10);
    player->SetCollisionType(COLLISION_PLAYER);
    
    //Create a camera    
    auto camera = CreateCamera(world);
    camera->SetClearColor(0.125);
    camera->SetPosition(0, 1, -8);
    camera->SetFov(70);
    camera->SetPosition(0, 1.6, 0);
    camera->SetPosition(player->position + Vec3(0, 1.7, 0));
    camera->Turn(0, 180, 0);
    camera->SetMouseLook(true);
    
    auto scene = LoadScene(world, "Maps/Testing.map");

    Vec3 camrotation = camera->GetRotation();
    Vec2 mouseaxis = window->GetMouseAxis().xy();
    const float lookspeed = 200;
    const float movespeed = 3.5;
    const float maxaccel = 40;
    const float maxdecel = 15;
    const float mousesmoothing = 3;
    const float runspeed = 2;
    const float jumpstrength = 12;
    const float lunge = 1.5;

    window->SetCursor(CURSOR_NONE);

    //Main loop
    while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false)
    {
        if (window->KeyHit(KEY_SPACE))
        {
            //Create the player
            player = CreatePivot(world);
            player->SetPhysicsMode(PHYSICS_PLAYER);
            player->SetMass(10);
            player->SetCollisionType(COLLISION_PLAYER);
        }

        if (ActiveWindow() == window)
        {
            //Camera look            
            camrotation = camera->rotation;

            //Movement 
            float accel = maxaccel;
            Vec2 movement;
            movement.y = (window->KeyDown(KEY_W) - window->KeyDown(KEY_S));
            movement.x = (window->KeyDown(KEY_D) - window->KeyDown(KEY_A));
            if (movement.x != 0.0f and movement.y != 0.0f)
            {
                //Adjust speed on each axis if both are in use
                movement *= 0.7071f;
            }
            movement *= movespeed;
            float jump = window->KeyHit(KEY_SPACE) * jumpstrength;
            bool crouch = window->KeyDown(KEY_C);
            if (player->GetAirborne()) jump = 0;
            if (crouch == false and window->KeyDown(KEY_SHIFT) and !player->GetAirborne())
            {
                movement *= runspeed;
            }
            if (jump > 0 and crouch == false)
            {
                movement *= lunge;
                accel *= 100;
            }

            //Set input
            player->SetInput(camrotation.y, movement.y, movement.x, jump, crouch, accel, maxdecel);
        }

        world->Update();

        //Adjust camera position
        float eyeheight = 1.7f;
        if (player->GetCrouched())
        {
            eyeheight = 1.8f * 0.5f - 0.1f;
        }
        camera->SetPosition(Mix(camera->position.x, player->position.x, 0.5f), MoveTowards(camera->position.y, player->position.y + eyeheight, 0.1f), Mix(camera->position.z, player->position.z, 0.5f));
        camera->SetPosition(player->position.x, MoveTowards(camera->position.y, player->position.y + eyeheight, 0.1f), camera->position.z);

        world->Render(framebuffer);
    }
    return 0;
}

 

[Josh]

I am replacing the convex hull primitive that brushes use with a polygon mesh collision shape, which should solve both the problems here. Stay tuned...

[Josh]

I may have found the cause, although it's not a complete explanation.

The most problematic shapes are wedges with the pivot point outside of the convex hull:

A wedge by default will have the pivot point right along one of the faces, which might occassionally cause collision to fail, if there is a problem like this.

This explains why your wedge was failing frequently, but a new wedge did not have the same problem.

This is still a bug. I don't have a complete answer yet. But I believe I am on the right track now.

 

[Josh]

The Newton developer has confirmed there may be an issue here...

[Josh]

Here is a demonstration that proves the cause:

 

[Josh]

Another video demonstrates how to reliably create the error: