0
$\begingroup$

I'm making a first person view game, and I have a big low-poly hilly terrain. Occasionally while testing, my character falls through the ground. What is the best way to fix this? I've heard that increasing the physics steps can help but I don't believe it has.

$\endgroup$
6
$\begingroup$

Set the physics type on your ground to triangle mesh. That should fix it, But if it doesn't not, you can also turn up the margin or extrude the ground down in edit mode.

enter image description here

It is possible that your ground is not calculating the collisions correctly, and changing the collision bounds on the ground should fix it.

If your problem still happens, you can also try changing the collision bounds on your character. If you are still unsure what the problem is, you can activate "Physics Visualization" to show exactly what is or is not working.

enter image description here

Notice the difference between these pictures. The first is using triangle mesh collisions on the ground. The second one is using box collision type.

enter image description here

enter image description here

Although there is normally no problem with box Or triangle mesh, sometimes there is still an error and the collision bounds will not detect properly. In this case it is normally a good idea to try a different type, or increase the margin.

enter image description here

$\endgroup$
1
$\begingroup$

The issue here seems to be caused because the BGE renders quads differently from the way the blender Viewport display renders them, using different vertices to split the quads into tris. This means that although the physics collision mesh is generated before runtime using the Viewport renderer's mesh, the realtime BGE generated mesh has the quads split into tris differently, leading to collision which does not match the mesh.

Blender Viewport render Blender Game Engine render (notice the quad is split into tris using different vertices than the Viewport

This can be easily fixed using the Triangulate modifier (to stop the BGE from generating its own tris at runtime) or like Anson Savage discovered using the subdivision surface modifier (which also triangulates the mesh and stops the BGE from generating its own tris) Triangulate Modifier

Viewport render BGE render. since it is no longer generating its own tris the BGE rendered mesh matches the Viewport mesh and so the collision does too.

$\endgroup$
0
$\begingroup$

for very fast moving objects, I have found 'floating' a object on a ray, and then using it to draw a object on the mesh is handy.

I also distort the ray end point using the linear velocity, and use this to align to the normals AHEAD of the car, as you hit them this way you can go as fast as you want ,

$\endgroup$
  • 1
    $\begingroup$ He said this was an FPS not a racing game... $\endgroup$ – X-27 wants to Reinstate Monica Mar 14 '15 at 1:03
  • 1
    $\begingroup$ Well, it would work with sonic as well. :D $\endgroup$ – BluePrintRandom Mar 14 '15 at 2:38
0
$\begingroup$

the problem could be that: if a surface is very large, its geometric center could be out of camera. you can note that if the origin of an object is out of camera it simply disappear. a similar process could be present with physics, if our character lands on a surface, and this surface got a face with origin out of camera view, simply the physic calculate is not processed. Adding more faces just help the camera processing to compute two or more sure face / object collision

$\endgroup$
-1
$\begingroup$

What fixed my problem was applying a subsurf modifier to my ground. I tried the options given to me in the first answer, but none of them seemed to work.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.