Quote
Titmouse
tueidj - I see, thanks for the info.

Sorry Owen, hitting your thread a bit hard now wth off subject matters ;)

No problem I got the answers that I were looking for, my enemy ships are flying along a nice flight path now. All I have left to do now is draw the paths.



Edited 1 time(s). Last edit at 02/13/2012 05:12PM by owen.

I plan to do enemy patterns similar to these; [www.youtube.com]

Owen, have a think about using C++ & STL containers - lends itself well to things like that.

Quote
Titmouse
Owen, have a think about using C++ & STL containers - lends itself well to things like that.

I am still hacking away at c. Not ready to make the C++ jump yet. I'm trying to keep everything nice and tight so I'm going to put the flight paths/patterns in an array of structs.

Owen, my mind is probably playing tricks with me – think a while back you said you might use the C++ compiler on plain C code to get nice things like strings for free, that sounded like great plan for starters.
( when you feel ready giving containers a go - honestly you would love them, saving huge amounts of time buy using them and they cut down on bugs! Arrays really are nasty things of foul ilk. )

Hey guys, how you all are well. I came across another problem while I was doing collision detection. The function (shown below) works well when rotating around X and Y. It works by moving the position_vec z around the center point by rot_deg_x and rot_deg_y.

However if I try to rotate around the Z it fails. What happens is that the Z rotation is ALWAYS around the same direction axis. I want the Z/roll rotation to be around the NEW direction which is created by the X, Y rotation.

guVector rotate_vec_to_angle( guVector position_vec, guVector center_vec, float rot_deg_x, float rot_deg_y, float rot_deg_z ) {
	guVector orig_direction = position_vec;

	Mtx m,om;
	guMtxIdentity(m);
	guMtxApplyTrans (m, om, -center_vec.x, -center_vec.y, -center_vec.z);

	guMtxRotDeg(m, 'x', rot_deg_x); // rotate around y axis
	guMtxConcat(m, om, om);
	guMtxRotDeg(m, 'y', rot_deg_y); // rotate around x axis
	guMtxConcat(m, om, om);
	guMtxRotDeg(m, 'z', rot_deg_z); // rotate around z axis
	guMtxConcat(m, om, om);

	guMtxIdentity(m);
	guMtxApplyTrans (m, m, center_vec.x, center_vec.y, center_vec.z);
	guMtxConcat(m, om, om);

	guVecMultiply(om, &orig_direction, &position_vec);

	return position_vec;
}

I tried moving the Z rotation to below the VecMultiply but I can't figure out how to get it to ROLL around the new direction.

Owen, Not sure if you are aiming for the thing as the example I gave in this same thread (posted January 28, 2012 12:10PM)

Keep in mind you can simplify your code - remove the first guMtxIdentity and last guMtxConcat (and use something like single param guMtxTrans so no need for identity)
Note that guMtxApplyTrans and guMtxTransApply do not do the same thing. (is guMtxApplyTrans what you need?)

Maybe you just need to call guMtxTransApply once after the rotations. (or do you really want to translate, rotate and translate again in that order, looks odd to me) Also not sure why you are using the guVecMultiply?

Take another look at my example - I think that's what you’re after.

@Titmouse you the function works, it solves a different problem. This function is moving points - not calculating angles.

Here is a video of the problem; [youtu.be] in the video; The cyan boxes are the things that I am rotating (for collision detection). In order for the my simple collision detection to work properly I have to be able to follow the roll animation of the plane as close as possible. If you look closely at the plane you will see that it is rolling around an axis which is created when it faces its direction vector. The error now is the Z roll is not using the same axis.

I see, think I have something close. Take a look at my bolt thrower code, void GameLogic::GunTurretLogic()
look for something like // use bone points for both turret barrels. Allows shots to fired out the end of the barrel in 3D.
GameLogic::GunTurretShotsLogic does the detection (I use radius detection) this does 2D detection, ignores z. But the shots are moving on screen in 3D its just final logic check that ingores the z part since the bad ships are on a flat plan and I can optimised it be ignoring z.
(I placed some extra points into my 3d model dedicated to detection - in my case firing from barrel end. You can see the turrent in the intro or latter on in the game)

@titmouse I see your rotation code but its not encapsulated, its doing too many things at the same time. I am currently coding up a small demo so you can see how I am using the code. The function is ONLY doing barrel rolls on the -Z access (http://youtu.be/L5uTi3xs9EY). I need barrel rolls on the axis that the model is facing. I think I need to do the barrel roll after I calculate the new position_vec but I am not sure how to hack the matrix functions to achieve it.

whats the difference between guMtxRotAxisDeg(); and guMtxRotDeg(); ? they seem like the same thing with different parameters.

#define guMtxRotDeg(mt,axis,deg) guMtxRotRad(mt,axis,DegToRad(deg))
#define guMtxRotAxisDeg(mt,axis,deg) guMtxRotAxisRad(mt,axis,DegToRad(deg))



Edited 3 time(s). Last edit at 03/15/2012 09:01PM by Titmouse.

Yes the GameLogic::GunTurretLogic() has gotten big, don't think encapsulation it the right word (as the function makes use of classes). More a case of me being lazy and not breaking up the complexity, it is in need of a refactor (but that will never happen). It was originally under 1/2 the size – then I added bullets because it reused calculations and saved having to iterate the list all over again.

Forget most of what you see in my code, just hunt for the “gu” calls, since it’s all piled into one function it should in this case be easier to pull apart. Granted if you’re not use to seeing container access via iterators it can look odd.

For the bullet I use the same rotations as the original 3d turret object.
guMtxConcat(mat,mat2,Model); .. gives me the model rotation matrix
guVecMultiply(Model,...) give this your point you need checking (relative to the model) <-- this part is the key
move it to your needed world position .... so by the time I call pShot.AddPos( ...) I have the needed coordinates to fire from no matter where it faces.

Agreed my code is not the best place to pick up tips. ( nice vid - you clean that room! )

(did you say you will be releasing some code with the same example - that would help)

Took me forever to hack together the demo showing the problem but I am pleased to say I have it for download here; [www.box.com]

Its a devkitpro grrlib project with 700 lines of C code. When you run it you will see a white box and a red box. The red box is the target which you can move. The white box is always facing the red box. I draw a green box at each end of the cube by using the function rotate_vector_to_angle() to dynamically determine where the corners of the cube are based on the rotation values of the player cube.

The problem shows up when you press 2 and I start to apply a Z roll to the white box. X, Y rotations are OK. However Z roll is not working as I hoped. ANY help with fixing the rotate_vector_to_angle() function will be appreciated.



Edited 2 time(s). Last edit at 03/16/2012 04:08PM by owen.

With the final touch by Titmouse. I think that after 2 months it is finally working! with z roll and everything! I am going to have to create a neat little demo and put it on wiibrew. Just a little more bug testing to do!

here are the raw functions;

guVector rotate_vector_to_angle( guVector player_target, guVector player_position, float angx, float angy, float angz ){

	static  guVector  _GRRaxisx = (guVector){1, 0, 0}; // DO NOT MODIFY!!!
	static  guVector  _GRRaxisy = (guVector){0, 1, 0}; // Even at runtime
	static  guVector  _GRRaxisz = (guVector){0, 0, 1}; // NOT ever!

	Mtx g_ObjTransformationMtx;  //hack ... moved into gloabal space
    Mtx m, rx,ry,rz;
    Mtx mv, mvi;

    guMtxIdentity(g_ObjTransformationMtx);

	//if((scalx !=1.0f) || (scaly !=1.0f) || (scalz !=1.0f)) {
        guMtxIdentity(m);
		guMtxScaleApply(m, m, 1,  1, 1);   //no need to scale.  scale is always 1
        guMtxConcat(m, g_ObjTransformationMtx, g_ObjTransformationMtx);    
	//}

    if((angx !=0.0f) || (angy !=0.0f) || (angz !=0.0f)) {
        guMtxIdentity(m);
        guMtxRotAxisDeg(rx, &_GRRaxisx, angx);
        guMtxRotAxisDeg(ry, &_GRRaxisy, angy);
        guMtxRotAxisDeg(rz, &_GRRaxisz, angz);
        guMtxConcat(ry, rx, m);
        guMtxConcat(m, rz, m);
        guMtxConcat(m, g_ObjTransformationMtx, g_ObjTransformationMtx);
	}

	//if((player_position.x !=0.0f) || (player_position.y !=0.0f) || (player_position.y !=0.0f)) {
		guMtxIdentity(m);
		guMtxTransApply(m, m, player_position.x, player_position.y, player_position.z);  //always done
		guMtxConcat(m, g_ObjTransformationMtx, g_ObjTransformationMtx);
	//}

	guVector orig_direction = player_target;
	
	guMtxApplyTrans (g_ObjTransformationMtx, g_ObjTransformationMtx, -player_position.x, -player_position.y, -player_position.z);
	guVecMultiply(g_ObjTransformationMtx, &orig_direction, &player_target);
 
	return player_target;  //returns the new location of the target location

}

guVector tracker_get_degrees_to_face_target(guVector current, guVector target ) {
	//it calculates the angle needed for the [model] to face the target from current_position
	
	float dx=target.x-current.x;
	float dy=target.y-current.y;
	float dz=target.z-current.z;

	float hyp = sqrt(dx*dx + dz*dz);

	float rx= atan2(dy, hyp);
	float ry= atan2(dx, dz);

	rx= rx * 57.2957795;
	ry= ry * 57.2957795;	
	
	return (guVector){rx, ry, 0};  //no z necessary
}	

I always get distracted when I get some new code to play with, lol, but I am making a centipede/snake demo game using the code (not finished yet). I also wrote a blog post describing how I use the function for simple AABB collision detection.
I will upload the centipede demo and source to wiibrew as soon as I finish it.

finally managed to put the code to some good use; [wiibrew.org]