I want to make a minibike game! Anyone who has ever ridden one of these will know how much fun it is! If you haven't, imagine a go kart with half as many wheels and twice as much fun. I was wondering what the best implementation of weight and collision detection would be, i.e., how to keep the bike on the ground. My guess was to find which triangle the wheel was colliding with, find the normal of it, rotate it 90 degrees according to which direction the wheel was facing, and move the wheel along that vector until it reached another triangle. I was going to use one point in the middle of the bike's wheelbase to test for collision with the ground and a box to test for collisions with other stuff. If anyone has any better ideas on how I might do this, please tell me, otherwise I will go with this idea. edit: I want to make a minibike game because I am finally purchasing my own and not bumming a ride on my cousin's. It seems like my pogo stick game was a bust. Pogo sticks - sort of fun, but not really. Halfway through the code I got bored with it because it just wasn't fun to play. No matter how many special things it had, it wasn't fun. Doesn't that suck. "Donkey, if it were me, you'd be dead." I cna ytpe 300 wrods pre mniute. [edited by - duncanbojangles on July 24, 2003 3:04:47 AM]

G''day! I''m new to these forums so please bear with my n00bness...

This is how i would do it. You dont need to bother with rotating normals of polygons or anything, since you should already know which direction your wheels are facing in. Just give the bike a velocity and update it every frame using the velocity (using time based movement, of course).

There was an article written somewhere on nehe about getting the point on a triangle plane.. you could use that for collision detection with wheels (given that you know the height and (x, z) coordinates of the "contact point", you could plug the (x, z) coords into a formula to get the height of the terrain, and compare them). I would use two points on the minibike to test for collisions with the terrain (both wheels), and given the height difference in the landscape you could rotate the bike accordingly.

Hope this helps!

You need to think about how you are going to implement your road/track or indeed your entire landscape. I can identify 3 options:

1) Use a heightmap (see Nehe lesson 34) - this is the simplest to implement but doesn''t give a particularly nice looking landscape (at least in its most basic form). The height at any particular point can be read from the heightmap data for any x,y co-ordinate (using interpolation to find the height of a point if it is between grid points). Result - Quick to generate landscape, easy to implement heigh readings...but ugly, basic landscapes.

2) Make a 3DS or MS3D landscape. This will of course be much prettier, since you can apply textures (or multi-texturing if you''re feeling adventurous!) and other eye-candy such as trees, billboards etc. (Basically you''re not limited to having only one poly in the height-direction.) However collision detection is trickier. since you need to find the polygon you are on-an exhaustive search through all polys in the landscape is clearly going to be way too much, so you''d need to look at space-partitioning (e.g. BSP/Quadtree/Octree (see gametutorials.com for some tutorials (although they''re nowhere near as good as NeHe''s! ;-] ))). This way you only need to search the polys in the node your test point is in. Result - Much harder to implement, but the limits of how good your landscape can look are only limited by how much time you are prepared to put into making them. (See why commercial games need so many people now?!)

3) Some sort of hybrid approach. You could make the landscape in a modelling program as in (2), but then make (either manually or somehow get the computer to generate) a heightmap that matches the landscape to simplify collision detection. This combines the simplicity of method 1 with the looks of method 2 (although you might well still need space partitioning to draw the landscape if it''s got a high poly count).


Of course I''m pretty amateur at all this, so there may be better ideas out there, but I''d guess fps and driving games use something like method 2. (Unless anyone can tell me differently?!)

All very good ideas, but since I''m not all that great at the calculus stuff yet , I''m using ColDet, which is a DLL and lib and header file, (don''t know what to call it). It has a function that will return which triangles have collided if there is a collision. Using this information, I can find the angles of the current triangle I am on, thus rotating and moving the bike accordingly. I was going to only use one point to test for collisions because this would be an initial version, improved later. To implement BSP, I''d like to do it on my own so that I can have total control. I was thinking of dividing the world into large cubes, all the same size. Each cube would be a different model( not the best way, but initial version). Check for collision in current cube, draw current cube and 8 cubes surrounding current cube. The height map idea is good, though. I''d like a VERY large heightmap so that clipping wouldn''t be much of a problem. Thanks for your ideas, I guess I''ll get started on 3 versions!

@alex:
I dont think dispacement maps are that ugly, they can look quite nice with some extra effort: check out the tutes on gametutorials(featuring texturing / multitexturing / volumetric fog / skybox).

If you want a really great terrain engine, you''d need some sort of algorithm to create coarse geometry in the background and detailed geometry in the foreground. Static BSP trees are no good for this, and I dont think Octrees are much better. I think ROAM implements features like this using a triangluar bintree. I''m trying to implement a bintree in my own landscapes - its surprisingly easy (and fast!).

Maybe the coarse background and detailed foreground can be implemented with mipmaps. Unless what you''re saying is that the detail of the actual terrain changes, and not just the textures. If each cube of the space partition were a different model, then just use the low detail model for the background, and the high detail model for the foreground.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Yeah, I meant that the actual triangle mesh adapts to the level of detail required, not just the textures. But yeah, im sure using your approach with different models would work just fine.

@Juggers...

Yeah, that's a good point, multitexturing can brighten things up a lot. It gets a bit complicated when you need different textures tho, e.g. track(road), grass, rocks etc in different areas, which is where a 3D model comes in....ah yes, and you can't have bridges/flyovers if u use a basic heightmap-something some games need! Remember the old Dooom games? 3D? No!-you couldn't go above or below another walkway (bridges/tunnels) hel, you couldn't even jump! - They basically removed the third dimension to keep things simpler, so it was basically a 2D game. Things like trees/grandstands etc (i.e. objects to make the scene look nicer) can be built into a 3D model but not implemented on a heightmap, although as they are literally "objects" they can be defined separately and added later I guess.

I like the idea of using different cubes for each bit of the landscape....sort of like a manual simplified quadtree/octree.

You'd need to be careful when choosing the size of your cubes tho-2 small and you'll have massive overhead. assuming your landscape is relatively flat(i.e. x,z range much larger than y range) you might not want to have 3 layers of cubes in the y (up/down) direction, surely 1 will do? There won't be anything above or below the track (at least that's not already contained within the current cube)...

[edit]

Ah I just saw you said 8 surrounding cubes, that means you are already thinking of doing it in 1 stack-good man! Ok, how about you only draw the cubes in view, rather than the 8 surrounding cubes? Surely up to 3 cubes could be behind the camera? It'd be quite easy to check which cubes are in the viewing frustum and just draw them (same principle as in Octrees, see gametutorials.com). You can always use fog to hide popup if you choose to use a close far-clipping-plane (to limit the max no. of cubes drawn).

Good luck!

[edited by - alex997 on July 25, 2003 7:48:33 AM]

Juggers: Could you point me to some info/tutorials on the ROAM algorithm/bintrees? Yes I could google it, but I figure if you''re finding it easy maybe you have a good source of info!

My source of info: I googled it and went to the first thing I saw.