Does anyone know if there’s a performance benefit of using a heightfield collision shape in Bullet?
I know that you can exploit the regular spacing of heightfields to calculate normals quickly, and I wondered if perhaps that holds true for collision detection as well. On the other hand, it could just be a convenience method for generating a collision mesh. I’m currently in the planning phase of a project, and might build the game world differently based on performance considerations. Thoughts?
The main benefit os heightfields is performance, as from images it’s easy to create collision meshes in respect to LOD and it’s easier to create tiling terrains. Oh and I’d suspect that a greyscale image loads faster than any mesh of similar detail.
I have no measurements of performance, but the heightfield is expected to perform better for collision detection than a triangle mesh. Not only because of the regular grid spacing, but also because of the “2D” nature. If you can get along with a heightfield - i. e. you don’t need holes or overhangs - then you should use a heightfield and not a triangle mesh.
OK, height field it is. It’s for a racing game with a randomly-generated street network, so having a 2D grid from which to work makes generation easier as well as collision. I think I can do without bridges and tunnels for now.
Hmmm… just a few ideas why triangle mesh might be better in your case:
1.) If it is not an off-road racing game then the race is over once you leave the road. 90 percent or more of your terrain will never get in contact with a car. So why checking for collisions off the roads?
2.) The heightfield you use might have 1024x1024 pixel, but this is still very coarse grained for a game which virtually depends on interaction between tires and ground. And the edges of the heightfield triangles are all rectangular aligned. Using a triangle mesh your level designers could create more “realistic” terrains, and smoother transitions from one triangle to the next.
3.) As far as I know we have not exposed a way to define per-triangle materials for heightfields. so all of your terrain will have a single material.
I have seen that you want to create random tracks. So hand-modelling the tracks is not an option for you. Still I would consider doing this for the first track, to see what factors have influence on the vehicle simulation, and tweak until you are satisfied with the results. Then start working on a generator for collision meshes.
Finally, one of the first things you should check is if the Bullet vehicle dynamics suit your needs, since we have not exposed a way of “customizing” them, e. g. by modifying tire/ground contacts inside callbacks. I have tried to setup simple vehcile demons both with Bullet and PhysX, and never have been satisfied with the results. Maybe I just don’t find the right tuning parameters, but using ODE I did not have such problems.
Hey enn0x, thanks for the advice. My thoughts are:
I want people to be able to take shortcuts. Part of the reason for random levels is to force people to make quick navigation decisions in an unfamiliar environment.
Yeah, that is a problem, and I haven’t yet decided how to deal with it. I’ll either generate a heightmap and carve roads out of it, or generate a road mesh and triangulate the intervening regions.
My gut instinct would be to make the entire terrain one material, and set the friction/speed of the vehicle depending on whether it’s in the vicinity of a road (as defined by the heightmap).
Yeah, I have tried Bullet vehicles before and they tend to be a bit squirrelly. Whether or not I can get them to work will determine how I build the levels, so I want to get the vehicle physics squared away before diving into any hardcore geometry.