Kart racing physics projectile problem

Development World Creation
, , ,
1

Hi, I’m working on a fun Kart Racer project at the moment. I’m relatively new to unreal engine and visual scripting but I would say my skill level is early intermediate.

I wanted to make a projectile similar to how the green shells operate in Mario Kart.

This would be bouncing off steep > 70 degree walls while climbing or descending anything less than this and maintaining all X/Y axis velocity until it either collides with another destructible or bounces a certain number of times.

I have the projectile spawning from an arrow attached to my player pawns forward orientation at a speed that will always be greater than the players max speed.

The projectile itself is using the static mesh shape_taurus that comes with the engine for the time being.

To this I have added the following components;

ProjectileMovement,
Rotating Movement,
InterpToMovement,
Physics Constraint,
Sphere Collision.

While some of these may not be needed for the behavior I want for this example I do want a master projectile object that will act as the template for the behavioral needs of all of the other projectiles that I add to the game.

I have not done any scripting for it so far as a lot of the functionality I need is already included in these components. However I have been unable to limit the Z axis movement of it. Currently the projectile will bounce in any axis keeping the momentum in whatever angle it bounces. Limiting it’s Z axis movement would stop it climbing the various heights of the level.

Would I be correct in assuming I need to use walkable slope behavior for the object to decide whether it bounces or climbs? How do I get it to stay close to the ground and unable to bounce off it while maintaining it’s X / Y velocity? I tried a Hover component but it doesn’t work in combination with the projectile movement component. Maybe a physics material applied to walls and not floors with hits generating bounces?

Also would I better off using the static mesh for collision detection or would the sphere be more efficient? High accuracy is not important.

Any help would be greatly appreciated. Thank you.

-edit-
Having played around with physics materials I pretty much got the desired effect by having separate physics materials for the wall, floor and projectile. The floor now has 0 friction and 0 restitution with the projectile while the wall has 1 restitution so I get no bounces or friction on the floor now and 100% energy conserving bounces with walls. The only thing left to fix is the projectile ramping into the air off small slopes and lips which I assume can be fixed with walkable slope and some sort of z axis modifier. Still any input welcome here. I assume the above method would have very little performance overhead? I will obviously have to apply these physics materials to all materials in the scene which I would have to have done anyway to get different friction surfaces for the vehicle. Luckily there is a separate variable for friction with tires.

-edit2-
I just thought of a potential future problem for this method. If, in the future I want to combine the static meshes and materials of all static objects in the scene to reduce draw calls, will this method still work?

2

I think if you want a Mario Kart sort of approach, the Projectile is somewhat always linked to the ground. So I’m not too sure how the physics would work that way.

I’d almost be tempted to say to not use projectile component and instead treat that projectile like a character with an AI component as it needs to stay on track, hop off bumps and still hover the ground mostly. With a good movement component set up, no friction and an AI controller it should be doable.

As for the collision, a sphere is more efficient than a complex static mesh collision (and just as much fun).

3

Hi , thanks for the reply.

I have edited my original post since. I have it semi working for now. If you read the edits you will see how.

I had thought of using ai for it but I haven’t delved into this area yet. I’m trying to keep it as simple as possible but the desired behavior isn’t that simple I guess. I’m just trying to keep it as efficient as possible avoiding ticks if I can.

Here are the edits to save you looking.

-edit- Having played around with physics materials I pretty much got the desired effect by having separate physics materials for the wall, floor and projectile. The floor now has 0 friction and 0 restitution with the projectile while the wall has 1 restitution so I get no bounces or friction on the floor now and 100% energy conserving bounces with walls. The only thing left to fix is the projectile ramping into the air off small slopes and lips which I assume can be fixed with walkable slope and some sort of z axis modifier. Still any input welcome here. I assume the above method would have very little performance overhead? I will obviously have to apply these physics materials to all materials in the scene which I would have to have done anyway to get different friction surfaces for the vehicle. Luckily there is a separate variable for friction with tires.

-edit2- I just thought of a potential future problem for this method. If, in the future I want to combine the static meshes and materials of all static objects in the scene to reduce draw calls, will this method still work?

4

If your track is flat, you could check that the projectile is going too far high off the ground and bring in back. If the track is hilly, the other option is to shoot a vector from the projectile downward (Z) and check that the distance is never more than X otherwise apply a downward force. That should keep your projectile somewhat low.

Method will still work the same with a track that would be made of a complex collision. As long as the flat part is one piece and everything else is another. By the way you’re probably better off having the same big rocks replicated and rotated rather than one gigantic track size rock.

5

Appreciate your input.

The tracks will not be flat. There will be large variances in the Z axis. Hills, ramps etc. The driving/projectile surface will generally be flat or sloped though, not bumpy. I’ll try using a vector to push it down if it goes too high. That’s the opposite of what I was trying to do earlier to get it to hover so it will be an easy edit of my hover component. It still means adding a tick to every one of these projectiles which I was trying to avoid. There will also still be a loss in velocity as some x/y velocity is getting converted to z velocity and pushing it back down is not going to fix this. I suppose I could run a simple check for the current velocity and reset it if it drops too low but this would involve adding another tick. Am I being too cautious of adding ticks? There will be many that are needed, I’m just trying to avoid ones that aren’t.

Forgive my noobiness but I was under the impression that for performance reasons you were better off designing the entire map in a 3d program or unreal, use your meshes to build, add your materials, then merge all the meshes and materials to create one huge level mesh and 1 huge material to cover it which drastically reduces draw calls and improves performance and loading times. I haven’t researched this much as it’s for the later stages.

6

yes with some caveats: See answer here Static mesh draw calls? - Asset Creation - Epic Developer Community Forums