Slot Car Game

[-=Magic=-]

Hi,
I'have a problem. I'm writing a Slot Card game. I'have a car, with a paddle below it.
When tha car moves, the paddles moves inside the slot.
what I would like to have, is that the paddle shouldn't brake the car while colliding with the slot. (but should response to a collision, to allow the car to steer and follow the slot path).

when the paddle hit the slot, how may I preserve the velocity of the car?

(using a material with 0 friction, doesn't solve the issue)

[Norbo]

Given the high speeds of the car and the high degree of tessellation required to preserve smooth turns if using collision detection to guide the car, I would strongly recommend not using regular collision detection and response for this purpose. Even a single contact point with a normal pointing a few degrees off optimal will result in a noticeable jerk with a fast moving object. Given that the simulations progress in discrete timesteps, there's no hope of guaranteeing perfect contacts at every single update. There will be issues with sufficient speed.

This sounds far better suited to an explicit path following approach. Check out the PathFollowingDemo in the BEPUphysicsDemos for an example.

[-=Magic=-]

I will look at the demo, but if I would like to try this route also?
is There a way to preserve the velocity after a collision?

Even at slow speed and with high curve tassellation, the speed of the car slow down.

Other info:
The paddle is a capsule with a radius smaller than the width of the slot. The paddle doesn't collide with the bottom of the slot.
The top of the paddle is fixed to the car body.

[Norbo]

Collisions must try to remove all velocity which is perpendicular to the surface to stop penetration. The degree to which this fact slows the car depends on the track layout.

You may also be encountering damping if you haven't explicitly disabled it. entity.LinearDamping and entity.AngularDamping both default to nonzero values and will sap energy out of the system. Additionally, if the car goes too slow (below space.DeactivationManager.VelocityLowerLimit), 'stabilization' will occur. This is another form of damping meant to allow things to go to sleep faster. You can prevent this by setting the entity.ActivityInformation.AllowStabilization to false.

If you don't want to do explicit path control, you will still likely need to control the velocity of the car. You could apply forces to re-accelerate the car to the desired speed even if it does get slowed down by other effects. This doesn't really 'preserve' the velocity so much as force it to the desired value, but it has a similar effect

[-=Magic=-]

I'll check and try tomorrow. Thanks for the support.

p.s.
Have a look at this: http://www.kjow.net/
He use a full physic engine to move the car. As I would like to reproduce.
he use Newton Physic Engine

[Norbo]

If you're curious, a path-based approach could reproduce the effects shown in the main video. I would not be surprised to hear that it was using a constraint to pull the car around the track, letting it swing and bounce around as it moves.

[I should mention that a path-based approach is still completely physical and uses the physics engine; it just makes the simulation easier. Consider that collision detection just produces a bunch of constraints which very indirectly attempt to guide the car. Simulating the slot using a constraint which directly pulls the car where you want it to go cuts out the middleman while still retaining all the physical effects.]

[-=Magic=-]

For the game on that video, I may confirm that he use the paddle on the slot approach.

About my issue, I found the problem
The wheels doesn't have enough traction when the paddle collide with the slot. So the wheel skids, instead of get traction and continue to pull the car.
I solved, removing the wheel motors, and using a virtual point on the car, where I apply the force. That's all.

Now I'm able to run the car in a similar way of the one of the video.

I've another issue. sometimes, when the paddle collide with the slot, may happens that the paddle hit the intersection between 2 parts of the track. Instead of getting the standard behaviour, the collision is managed as the paddle hit a wall. (hope I explained enough what I mean).

Now a question, about the physic engine:
If I join all the meshes of the parts of the track, from a performance point of view, is better than having X different meshes?
Joining all the meshes, will solve the issue abouve.. but I worry about the performance, becuase the engine cannot partition the collision entities anymore.

Thanks for your supprt Norbo

[Norbo]

Meshes have a dedicated acceleration structure which is marginally faster than the general-purpose one used in the broad phase. Combining the meshes should very slightly improve performance.

To eliminate the edge-hitting, connectivity information needs to exist. In other words, it would not be sufficient to simply put multiple separate chunks into the same mesh without modifying the topology. Surface smoothing across triangle boundaries is performed when the indices define a shared triangle edge or vertex.

[-=Magic=-]

I have a problem with the join of two meshes.
Each mesh is a model of a track part of the slot car game. so each model the "front" and the "back" of the model has the same vertices, so that they can be attacched each other.

Simple Example:
I have two model (two boxes), BoxA and BoxB. for each of them, I used TriangleMesh.GetVerticesAndIndicesFromModel to get Vertices and Indices.
I created two new list (one for vertices, and one for indices), where I put the result of the join.

1) I put the VerticesA into the VerticesList.
2) I append the VerticesB into the VerticesList.
3) I put the IndicesA into the IndicesList.
4) for each Index of IndicesB, if the index refer to a vertex of the "front", I update it with the IndicesA that refer to the relative "back" vertex of the first model. Then I added the index to the IndicesList.

In that way, I haven't changed the order of the index of the models, and I preserved the normals. I haven't changed the shape of the final model, since it is a compound of the two model.

The strange issuethat I have, is that the part of mesh of the resulting model, have the faces inverted. with the DrawerDemo, the seconf half of the meshes is totally black, instead of normally coloured of the same colo of the first half.
I can't figure why.

I compared each vertex/face normal before and after the indices update.. and are the same. the order of the indices isn't changed too.

very simple numeric example:

VerticesA: 0, 0, 0, 1, 1, 1, 2, 2, 2
IndicesA: 0, 1, 2

VerticesB: 0, 0, 0, 1, 1, 1, 2, 2, 2
IndicesB: 0, 1, 2

VerticesList: 0, 0, 0, 1, 1, 1, 2, 2, 2, 0, 0, 0, 1, 1, 1, 2, 2, 2

Now, both of this representation should give the same result, I think:
IndicesList: 0, 1, 2, 3, 4, 5 (simple join of the two indices list)
IndicesList: 0, 1, 2, 0, 1, 2 (join, updating the second indices to the vertices of the previous mesh)

[Norbo]

Sorry, there's nothing there I would have any insider information about since it's outside the bounds of the physics engine. Your guess/investigation is as good as mine

[-=Magic=-]

Ok, I edited the topic subject, so that I'll use this topic for all my questions

Actually, I've a fully functional slot car game. Every track part is a mesh, with the paddle which is inserted into the slot and pull the car around the track.
Even with bigger tracks I haven't any framedrops.
From the union of each track part, I create a single static mesh which represent the track.

Current settings:
- HighStabilitySettings
- TimeStepDuration 1/300
- 60Fps
- 4 car running
- Track test dimension: 98 track parts -> Static Mesh with 56620 vertexes, 112416 indexes, 37472 triangles

Under windows, no issue or framedrops.

--------------------

Now it's time to port it into Xbox 360

I've optimized the track part meshes, reducing and removing all the unusefull geometry (from a physic point of view).

Current settings:
- MediumStabilitySettings
- TimeStepDuration 1/180
- 60Fps
- Track test dimension (same track of above, but with optimized meshes): 98 track parts -> Static Mesh with 35718 vertexes, 63234 indexes, 21078 triangles

I got framedrops due to the narrow broad phase.

There's anyway I may optimize the narro phase? I haven't checked how the narrow phase is implemented. but since there's only 1 mesh, the broad phase time is <1ms, and obviously return with at least collision pair.

Externally from the physic engine, I know in which part of the track, the car is. So I would restrict the narrow phase to check only in that portion of the mesh, instead of checking all the 21078 triangles.

For example, I know that the first track part start from index with offset 0 to index with offset 725, the second one from 726 to 1451, the third one from 1452 to 1817 and so on.

If I know that the car is on the track part #3, I would restric the narrow phase to search collision with the triangles with indices starting from 726 (start of track part #2) to 1853 (end of track part #4).

any suggestion about how may I do it? (possibly without altering the bepuphysic library, so that I havent to port the updates on the future release of the dll)

[Norbo]

Narrow phase between convex objects and meshes does not test every triangle in the mesh. There's already an acceleration structure which prunes the candidates down to those triangles with AABBs which overlap the convex object. If that pruning didn't exist, it wouldn't even run on the PC

It may be helpful to post the full timings. Additionally:

-Is the slowdown consistent, or does it spike?
-If it spikes, does it coincide with collisions in areas of the mesh with denser tessellation?
-What kind of object is colliding with the mesh? Is it a simple box, or is it something more complicated like a mobile mesh?

[-=Magic=-]

The slowdown spikes, and it coincide with collisions in areas of the mesh with denser tessellation (when the car perform a turn).

The paddle is a cylinder mesh, with an ellipsoide as base (instead of circle):
Note: I forgot to simplify its physic model.



Some numbers:
- Paddle: 70 triangles
- Narrow phase, spikes from 1/2ms to around 30-35ms on some turn, at a more elevated speed.
- Solver phase: stay constant at 4-5ms
- Position update phase: from 1ms to 4ms (why???)

Here some examples (Scenario: 1 static mesh, and 2 cars. each car is 1 box + 4 cylinder + 1 paddle):

[Norbo]

Using an actual mesh (presumably in the form of a MobileMesh as opposed to a ConvexHull) for the paddle causes some significant pain. Given the high speeds and dense packing, you could expect almost all of the 70 paddle triangles to be tested against the nearby environment. The portion of the mesh considered to be the nearby environment enlarges as the speed increases. So, if your track has dense geometry and the car is going really fast, you could be looking at thousands of triangle-triangle collision tests even with AABB pruning.

If you have enabled CCD for the car, that would also explain the PositionUpdater time. Mesh-mesh CCD is expensive compared to regular objects.

To avoid this, either use a simpler version of the paddle (preferably as a ConvexHull instead) or, even better, use a squished cylinder:

Code: Select all

            CylinderShape cylinderShape = new CylinderShape(1, .5f);
            TransformableShape transformableShape = new TransformableShape(cylinderShape, Matrix3X3.CreateScale(0.3f, 1, 1));
            var paddleThing = new Entity(transformableShape, 10);

[-=Magic=-]

Using a squished cylinder works a lot better. But not enough.
Which are the params which affect the Narrow phase, for tuning?
Reducing the size of the AABB area, should consume more memory but also should reduce the number of triangles to test. Or not?

I know the size of the paddle, so that it isn't necessary that the AABB area is greater than the surface of the paddle, isn't it?