#84835 - iainprice - Wed May 24, 2006 10:55 pm
I'm on the beg...
I have been trying to write a 3d racing engine for ages now.
I started from scratch and imported models poly by poly and did proper physics with colision detection and plane sliding on contact (with sphere distance optimisation) but far to slow.
I tried using a simple md2 program and adding physics so that the models would be sphere bound and quick to load ... too slow
I have even tried converting quake source to nds...
And writing bsp tress from scrtach but I get lost....
I'm just not having any luck... I have some coding ability, some 3d models, some textures, some free time and lots of ideas and enthusiasm but I really need some help.... anyone?
#84884 - mike260 - Thu May 25, 2006 9:45 am
What bits do you have working ok, and what areas are you looking for help with?
_________________
"Ever tried? Ever failed? No matter. Try Again. Fail again. Fail better."
-- Samuel Beckett
#84919 - iainprice - Thu May 25, 2006 6:48 pm
For a racing game a high visible poly count has always been an issue...
but that aside the speed of the collision detection and plane sliding is bad whenever I alow for gravity etc...
#84920 - ecurtz - Thu May 25, 2006 6:59 pm
You shouldn't be doing enough sphere collision testing to really be taxing the DS. It sounds like you need to use some sort of spacial division on your world data.
Racing engines are generally considered "2d" worlds, so I'd try something like a QuadTree.
Wikipedia QuadTree
#85033 - iainprice - Fri May 26, 2006 4:36 pm
Any good tutorials hanging around?????
#85040 - mike260 - Fri May 26, 2006 6:32 pm
| Quote: |
| Any good tutorials hanging around????? |
Try looking into OBB (oriented bounding-box) trees. They're quite costly in terms of memory, so you need to keep your collision-mesh as low-poly as possible, but it's quite easy to implement and perform well. Plus, if memory does turn out to be a problem then there are lots of ways to reduce their size.
The basic idea is, to partition your collision mesh up a tree, where each node looks something like this:
| Code: |
//NB: Ridiculously wasteful of memory
typedef struct OBBNode
{
vec3 bbox[2]; //the OBB of this node and all its children
bool is_leaf;
triangle *tri; //only valid if is_leaf
struct OBBNode *children[2]; //only valid if !is_leaf
}
OBBNode;
|
To build an OBB tree, you first create a node for each triangle in your collision-mesh. Now you repeatedly find the pair of nodes whose obb's are closest/most overlapping, and who both don't yet have a parent, and you create a parent node for them. When there's only a single parentless node left, you've got a complete OBB tree.
To test a sphere against an OBB tree, you do something like this:
| Code: |
void sphere_obbnode_test( sphere *s, OBBNode *node )
{
if( !sphere_overlaps_bbox(s,node->bbox) )
{
//this node and all its children are irrelevant
return;
}
if( node->is_leaf )
{
//this should do the actual collision-detection
sphere_triangle_test( s, node->tri );
}
else
{
//Recurse to both children
sphere_obbnode_test( s, node->children[0] );
sphere_obbnode_test( s, node->children[1] );
}
}
|
_________________
"Ever tried? Ever failed? No matter. Try Again. Fail again. Fail better."
-- Samuel Beckett
#85093 - lazmike - Sat May 27, 2006 12:39 am
Make sure you're not using floats so it will be faster. A few floats hasn't been a problem for me, but they start taking their toll eventually; just a heads up. There are hardware fixed point functions (div, mul, sqrt, etc) - check those out in libnds.
_________________
-laZmike-
http://lazmike.nintendev.com
#85144 - iainprice - Sat May 27, 2006 12:59 pm
Cheers, I'll let you know how it goes.
#85305 - Payk - Sun May 28, 2006 9:07 pm
So i would always recommand precalculation what can be precalculated.
For example u have that street and some trees arround it.
So why not making an array for colision.
bool Map[256][256];
When starting map u should precalc for the racefield which parts are "driveable" and which not. Then store that in that array.
When driving u just have to read thoose parts out of that array
which are arround the car.
Deepending how good your precalc is and how big your array is i can get a very good result and its much faster then cheking some displaylists...
#85378 - silent_code - Mon May 29, 2006 4:50 pm
i haven't read all posts, but displaylists are BAD!!! EVIL!!! like doc. evil... you know ;)
an array may not be the best choise, but it's definitely better than disp lists (EVIL). there are some data structures that may be better, smaller and faster than the array approach. i can imagine situations where the quadric nature of array elements won't be able to represent certain cells of the track, so you'll have to limit the angles of the traks like in 90 or 45 degree stepps and storing the type of the current cells track layout as an enumeration that looks like:
NORTH_SOUTH,
NORTH _SOUTHWEST...
WEST_NORTHEAST...
etc.
all possible connections in just 8 directions... it's like the restrictions you had in wolfenstine 3d, where everything needed to be in 90? angles. i hope you get it.
then according to that you can determine if a car hits off road or if it's in a "legal" position on track.
but if you want to got for real "free form" tracks rather than the tile based approach, then you'll perhps be better off with some hierarchy. like a simple 2d "line splitting" bsp tree. you'll have to check that out and decide for yourself how restricted you want the art to be.
good luck!