I added a z collision check ahead of the final check so that should help it down to 8x checks if I am lucky.

The sphere check would have to be modified to operate in 3 dimensions because my game has cubes which are often elongated in the X,Y or Z direction - so we would probably end up with the same amount of code in the end.]]>

Looking at the code the check_diff, has x4 compares.

Check_collision calls check_diff, so that 24 compares in total.

Try these things out...

(1) put the 'check_diff' definition into a header file to help maximize the chance of it becoming inline.

(2) To optimise 'check_collision' use logical OR '||' not bitwise OR '|', now the second part is only evaluated when the first evaluates to false.

Worst case is still the same, but you can still try swapping the order as this may help if say the second part is true more often. In my example, since check_diff returns 'bool' I've use logical AND '&&' . (I undertand that with some CPU's you can get the compile to do nice things in some cases by avoiding logical compares)

(3) Check_diff same thing as step 2

(4) If your calling code uses structures, pass in pointer of guVector (guVector structure is defined in ogc\gu.h)

(5) If its possible add new box check routine that takes four edges, no need to add/sub the length, width & depth.

guVector Ship1 = {10,10,10}; guVector Ship2 = {15,15,11}; ... bState CheckBoxCollision( &Ship1, &Ship2... CheckBoxCollision( bool CheckBoxCollision( guVector* PointA, guVector* PointB, guVector* SizeA, guVector* SizeB) { return (check_diff(PointA->x, PointB->x, SizeA->x) && check_diff(PointA->y, PointB->y, SizeA->y) && check_diff(PointA->z, PointB->z, SizeA->z) || check_diff(PointB->x, PointA->x, SizeB->x) && check_diff(PointB->y, PointA->y, SizeB->y) && check_diff(PointB->z, PointA->z, SizeB->z) ) ; }

Extra note: The Sphere test has far less overhead - but its a case of swings and roundabouts.

If you get the chance try using a sphere test out on things like small projectiles.

(I find box checking not worth the effort, projectiles can still pass through the box edge depending and the type of math used to track motion)]]>

Quote

**Titmouse**

Sorry Owen – that was a bad joke about you using plain C, I would never have a dig at anyone’s coding skills.

Apologies for poking fun at you; dire attempt at trying to get you to move over to C++

Sorry Owen – that was a bad joke about you using plain C, I would never have a dig at anyone’s coding skills.

Apologies for poking fun at you; dire attempt at trying to get you to move over to C++

No offence taken. The only problem C++ solves for me is dealing with strings. Aside from that I have bigger problems like shadow mapping.]]>

Low detail models derived from the working model sounds a good way to go – that way you can dial it up or down depending on the viewing distance using whatever checking method you believe will work best.]]>

Here is how I do collision check for 2 boxes in 3d, since I'm only dealing with the collision boxs. the fx, fy and fz variables correspond to the scale value of each boxe. (if there is a faster way to do this check then let me know).

bool check_diff(int n1, int n2, int fat) { return ( ( (n2>n1) & (n2-fat]]>n1) ) ); } bool check_collision( int x1, int y1, int z1, int x2, int y2, int z2, int fx1, int fy1, int fz1, int fx2, int fy2, int fz2 ) { //do_draw_box( x2,y2,z2, 0, 0xCAA95F44, fx2, fy2, fz2 ); //show x2 bounding box //do_draw_box( x1,y1,z1, 0, 0xCAA95F44, fx1, fy1, fz1 ); //show x1 bounding box return ( ( check_diff(x1, x2, fx1) & check_diff(y1, y2, fy1) & check_diff(z1, z2, fz1) //check 1st ) | ( check_diff(x2, x1, fx2) & check_diff(y2, y1, fy2) & check_diff(z2, z1, fz2) //check 2nd ) ); }

This method is useful to calculate simple collision, but is not precise enough to complex models, like humans, or something like that. My Idea combine this type of simple calculation with the calculation of multiple spheres around all the model. Is like to make the same model but with low resolution.]]>

As you know its C++ so both of the vessels points are known.

Here’s some example calling code, 60*60 is to get rid of the need for sqrt.

(I just love C++ containers, dam fast and I not had _ANY_ bugs let alone crash bugs in my bolt thrower code, powerful stuff...

for (std::vector

{

if (pPlayerVessel->InsideRadius(iter->GetX(), iter->GetY(),60*60))

{ ... }

...

}]]>

I find

Change it to pass in guVector* and also include z as part of the equation.

It's good for a first step test when you need to find out if it's it in or out the field of view.

// note: The radius param takes a squared value so saves using sqrt

bool Vessel::InsideRadius(float center_x, float center_y, float radius)

{

float square_dist = ((GetX()-center_x)*(GetX()-center_x) ) + ((GetY()-center_y)*(GetY()-center_y)) ;

return ( fabs(square_dist) < (radius) );

}]]>

The problem appears when we try to do an automated procedure to search the limits, because each subelement of a group applies its own transformations over the parent group transformations, and it is recursive in my program. Model can have many levels of depth each one with its own transformation primitives.

I'm programming a function to found the real borders through the application of all nested transformation using matix operations.]]>

The problem appears when we try to do an automated procedure to search the limits, because each subelement of a group applies its own transformations over the parent group transformations, and it is recursive in my program. Model can have many levels of depth each one with its own transformation primitives.

I'm programming a function to found the real borders through the application of all nested transformation using matix operations.]]>

Also its good to have a frame rate counter. Look in this; [www.google.com]

This morning I got a model with 700 faces and my game froze. My game is not the best optimized and I am is drawing directly to the screen but the wii is fast if you keep things simple. Though the wii is NOT super fast. I have to use tricks to limit the amount of points I check, I divide up my game space so that I only do collision checking on things that are near the player or bullet. I also have something like a [en.wikipedia.org] for determining which objects are close to each other.]]>

But my objects have 2000 or 3000 vertex and near to 1000 faces each one, could be Wii fast enough using this method?]]>

Well you can try using the Bullet physics engine ( [en.wikipedia.org] ). or Any of the other free ones available; [forum.wiibrew.org]]]>

That you say is the idea for my first aproximation, but for the next I think I'll need a boolean grid in the space where is located the object.

How do you calculate the collision with non aligned objects? Perhaps you align first the objects and then you rotate them?

You can see a video of my game some time ago:

[www.youtube.com]

From the moment I recorded this video I have added a house, some palms and I programed different points of views for the player (first person, third person, view....) and now I am trying to solve the collision detection in every case. Palms are easy because is only necessary to check them as a cilynder, but the walls of the house are more complex because are not a box.For instance I can contact a wall with 30º, or jump to the ceiling.

I''ll upload some images and a new video of my game soon.]]>

I am currently working on a similar problem with my game [wiibrew.org]]]>

The idea is to divide the space in boxes and set each box solid or not depending on contains a part of the model. Is like to draw the model in low resolution.

The only problem, is necesary to write functions to draw filled triangles in this discrete space and is necesary a big amount of memory to represent the bounding boxes. By other hand is extremely fast to check the collisions.

I'm writing the drawing lines and filled triangles based on DDA algoritm.

I would appreciate a more easy alternative but I don't now if it is possible.]]>

e.g. if x1 > x2 and x1< (x2 + width) then collision=true;

do this for all axis.]]>

including a stage on which the characters are moved.

Now I have encountered the problem of collision detection. I've heard of the bounding

boxes, but that means almost re-draw the model manually without the aid of GX.

Does anyone have any idea how to approach this issue?]]>