I’m dynamically generating a 3D track, which includes a floor which can potentially tilt. (FYI: once generated, the floor does not move)
Im using the CollisionFloor handler, which works fine. But when I generate a slanted floor (imagine something like a hill going up and down), because my floor collision objects are basically bounding squares, with little square ground models, the car falls through the cracks sometimes.
Questions:
Is there a way to make a finite plane, similar to the CollisionPlane; but this time such that the planes are bounded between 4 lines, and behind the plane is considered collision?
Is there a smarter way for me to generate my racetrack instead of using this method?
Hmm… What about a heightmap? As long as there are no overhangs, a heightmap should provide a reliable definition of “above” and “below” the surface, and I would imagine would lack those gaps between polygons.
I’m not sure, I’m afraid–it’s not something that I’ve worked with very often myself. I think that both Bullet and Panda’s collision system have height-field shapes (the latter being mentioned in the manual), but whether the latter works with CollisionFloorHandler I don’t know. (The former almost certainly won’t, being of a different physics system.)
There may also be information in other threads on the forum, for that matter!
Otherwise, I’m afraid that I bow out for now, leaving the matter for those more familiar with working with heightmaps in Panda3D.
Height maps are not currently supported with the collision system in the latest revision, but this is in the works. If you wanted to use height maps, you would need to manually check the height at a given position to see if something is below the terrain.
Are you currently using CollisionPolygon? The downside of this solid, as you may be describing, that polygons are infinitely thin and therefore less reliable than a plane.
Hmm… With a box, it might be worth carefully testing movement across boundaries, as the shape of the corners might produce some undesired movements under certain circumstances.
Yes I am actually currently using a tilted collision box… I did try to make the bottom part of the box bigger but for some reason the collision box could not be initialised properly… I’ll try again perhaps with a bigger size
Another thought: Is it ever valid for the player-character to be placed below the track? And are there instances in which tracks overlap? If not, then you might be able to simply use a ray-cast for height-detection, and then just ignore any case in which the ray doesn’t hit anything, leaving the character at its previous height.
Due to my (dumb) implementation of ground creation, possibly.
Actually, I would probably need a better way to generate the floor for the tracks. Currently what I do is to generate the bounds of the track, i draw crates in a straight line from defined points to another defined point.
This is done with the appropriate yaws and tilts. This is working perfectly fine.
But the corresponding ground generation is a little stupid. The bottom of each crate is a ground model object with a collision box surrounding it that extends to the left and right off the crate and this forms the ground. For now, everything works pretty well, so long as the heights do not differ by too much.
Ah, I see. Hmm… It seems to me that, with such simple underlying geometry, you might be able to define the height at a given point mathematically: after all, it’s just a point on a plane, defined by the location and orientation of the box. As long as you know which box the player-character is in at a given moment, you should be able to figure out the appropriate height for the characters location!