Actively Check Collision Information of Cage Object

[wadaltmon]

Hello,

Currently, I'm trying to implement a wall-running system, similar to the Titanfall games, in C++. The way I've thought it should work is to create a "cage" for the player (if the player is a cylinder, then create a cylinder slightly larger as the cage) and detect whether it is colliding with/overlapping another mesh, then if so, create an anchor point at the point of collision. Then, I can use a bit of math and raycasting with the normals of the ensuing surface to figure out the direction the player is moving and where they will end up next, but that part comes later.

The main issue I'm having is actually creating these cylinders, and actually finding out the collision information. I can create a model for the player like so: 
 

Model* player = Model::Create();

So, if I wanted the player to be a cylinder, I could create:

Model* player = Model::Cylinder(16);
player->SetPosition(0, 4, 0);
Model* cage = Model::Cylinder(16);
cage->SetPosition(0, 4, 0);

But this doesn't allow me to resize the objects. Furthermore, I'm wondering if Leadwerks has a way to obtain collision information in realtime on-demand. Is there something similar to the Pick system, allowing me to store collision information to a structure to check the point of collision? How would I change the collision type to make sure that my player still collides, but the cage doesn't?

[Thirsty Panther]

This thread is a little old and for Lua but might give you a starting point.

 

[wadaltmon]

9 hours ago, Thirsty Panther said:

This thread is a little old and for Lua but might give you a starting point.

 

This is a bit distinct from my problem, though. Take a look at the wallrunning in Titanfall:

Once you come in contact with a surface, you're essentially attached to that surface for the time being. And this can be done from any direction - right side, left side, front and back (any direction in 360, in fact). I wanted to avoid having to use several raycasts all around the character at all given times, as the performance might be affected.

[Josh]

If you burrow into the shape class you will find the raw Newton objects in there, which do have a lot of collision test features.

[wadaltmon]

19 hours ago, JMK said:

If you burrow into the shape class you will find the raw Newton objects in there, which do have a lot of collision test features.

If I create my player's model by Model::Create(), is the Shape associated with that of a known size and type? Can I use that shape?

If not, how do I change the shape of the collision model for the player without making a visible model that follows the player around all the time? I tried making a Shape* Cylinder of a given size, and using playerObject->SetShape(), but that didn't seem to change the collision model - it only created a separate visible model.

[Josh]

The answer is yes, but you have to do a lot of casting to get the Newton classes and it is not something I can explain easily, since it is not a supported feature. I would probably use ray casting (the Pick functions) to do this.

You gave me the idea to include some functions for user collision testing in the new engine:
http://www.newtondynamics.com/wiki/index.php5?title=NewtonCollisionCollide
http://www.newtondynamics.com/wiki/index.php/NewtonCollisionCollideContinue
http://www.newtondynamics.com/wiki/index.php/NewtonCollisionPointDistance
http://www.newtondynamics.com/wiki/index.php/NewtonCollisionClosestPoint

It's a little tricky for me because this will run in the main thread, instead of in the physics thread, but I think it might be useful for many people to have these commands available.

[Josh]

If you're a beta tester, the new features are now entered into the new docs system. See Physics > Collider.

[wadaltmon]

On 6/24/2020 at 2:08 AM, JMK said:

If you're a beta tester, the new features are now entered into the new docs system. See Physics > Collider.

I am not a beta tester, but if these functions are in the Turbo/LW5 beta, I'd certainly like to be. Is there a way I can opt in?

[Marcousik]

Not sure if it helps but with 4.6 you could use invisible triggers shapes to detect if the player comes to a wall.

The shaped trigger could in realtime detect the player and change the behavior and the animations.

https://www.leadwerks.com/learn?page=API-Reference_Object_Collision

[wadaltmon]

11 minutes ago, Marcousik said:

Not sure if it helps but with 4.6 you could use invisible triggers shapes to detect if the player comes to a wall.

The shaped trigger could in realtime detect the player and change the behavior and the animations.

https://www.leadwerks.com/learn?page=API-Reference_Object_Collision

I think that's what @JMK was referencing above, though directly via the Newton objects rather than through the Leadwerks collision API. Doing it as you suggest wouldn't give me the collision information, though, I believe - I'd still end up having to do multiple raycasts on each side to determine if the player is wallrunning. It seems like with the above mentioned new LW5 functions, I'd be able to know the closest point in the overlapping area of the collision shapes, and enact a single raycast from the center of the player object to that point to get the Face*, find the normal (at least, I'm presuming I can get the normal from a Face easily), and proceed to do the requisite simple vector math to find if the player should be wallrunning or not. Without the API support from the physics system, though, it precludes any avoidance of many raycasts every step (especially if I want to go beyond flat wallrunning and allow them to run on curved surfaces as well - which is a big goal of mine!)

[Marcousik]

For sure those Newton functions look much more advanced and I can imagine technically a step forward.

My suggestion was limited to the actually version of LE