|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391607
01/14/12 07:37
01/14/12 07:37
|
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB
Expert
|
Expert
Joined: Feb 2008
Posts: 3,232
Australia
|
Excellent... looking really good. Question though... HOW did you get it going in the end? Or did you re-build your "rotate_on_surface" function? [EDIT] HERE is MY version of the code MrSmith posted. Its BASICALLY the same, Ive just compacted the code a lot, and done some minor bug-fixes, AND Ive made the functions more 'controllable' with added parameters... Enjoy... Hopefully someone may find some useful tidbits in there of use or interest...
Last edited by EvilSOB; 01/14/12 14:20. Reason: broken link fixed
"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
|
|
|
Re: rotation around a sphere
[Re: EvilSOB]
#391627
01/14/12 13:29
01/14/12 13:29
|
Joined: Oct 2008
Posts: 513
Carlos3DGS
OP
User
|
OP
User
Joined: Oct 2008
Posts: 513
|
The link dosn't work. Oh and I barely had to change the code to get it to work, just a couple tweaks and also setting the water POLYGON flag.
void align_to_surface(ENTITY* Planet, ENTITY* Vehicle)
{
VECTOR start_trace;
VECTOR Temp_Vec;
//get the surface position
vec_set(start_trace,Vehicle.x);
vec_sub(start_trace,Planet.x);
vec_normalize(start_trace,vec_length(start_trace)*2);
vec_add(start_trace,Planet.x);
me=Vehicle;
c_trace(start_trace, Planet.x,IGNORE_ME|IGNORE_PASSABLE);
//DEBUGGING
//draw_line3d(start_trace,NULL,100);
//draw_line3d(start_trace,COLOR_RED,100);
//draw_line3d(Planet.x,COLOR_RED,100);
//draw_point3d(hit.x,COLOR_RED,100,16);
//place vehicle on surface
//(taking into account vehicle min_z)
vec_set(Temp_Vec,hit.x);
vec_sub(Temp_Vec,Planet.x);
//DEBUGGING
DEBUG_VAR(vec_length(Temp_Vec), 100);
vec_normalize(Temp_Vec,vec_length(Temp_Vec.x)-Vehicle.min_z);
//DEBUGGING
DEBUG_VAR(vec_length(Temp_Vec), 120);
vec_add(Temp_Vec,Planet.x);
vec_set(Vehicle.x,Temp_Vec);
//rotate towards planet core
vec_sub(Temp_Vec,Planet.x);
alignToVec(Vehicle.pan, hit.nx, vector(0, 0, 1), 1);
alignToVec(Vehicle.pan, hit.nx, vector(0, 0, 1), 1);
alignToVec(Vehicle.pan, hit.nx, vector(0, 0, 1), 1);
alignToVec(Vehicle.pan, hit.nx, vector(0, 0, 1), 1);
alignToVec(Vehicle.pan, hit.nx, vector(0, 0, 1), 1);
}
There are several alignToVec calls at the end to speed up the rotation smooth a little. Don't know if there is a better way to do it... And on monday I will also take a look at the code and try to optimize the calculations and simplify my code. and here is the movement code:
c_move(vehicle,vector(key_w-key_s,0,0),nullvector,IGNORE_MODELS);
ang_rotate(vehicle.pan,vector(key_a-key_d,0,0));
align_to_surface(Planet[1], vehicle);
I'm also thinking of tweaking the movement code. that c_move bothers me since I'm not really going to use collision detection (hence the IGNORE_MODELS) for the "planet overview" in my game, I just use c_move to get the movement forward/back aligned with the vehicle orientation. So I might think of doing those calculations myself in a custom function to get it working faster than a standard c_move.
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391633
01/14/12 14:19
01/14/12 14:19
|
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB
Expert
|
Expert
Joined: Feb 2008
Posts: 3,232
Australia
|
THIS link is fixed... damned typos! Yeah, the bugs I fixed WERE very minor ones. Is it REALLY worth replacing c_move with non-engine calculations? Is cpu-usage THAT critical? I cant see custom-coding that has no collisions actually ending up much faster. Take a look at my code, (now that you can), as I have already done some optimising...
"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
|
|
|
Re: rotation around a sphere
[Re: EvilSOB]
#391636
01/14/12 15:06
01/14/12 15:06
|
Joined: Oct 2008
Posts: 513
Carlos3DGS
OP
User
|
OP
User
Joined: Oct 2008
Posts: 513
|
I guess removing c_move is not really important, it was just a thought. But its probably not worth the trouble. I took a look at you code and was wondering if embedding instructions into eachother improves speed or not. If they don't, even though your code looks alot more compact it has the same count of instructions:
ITEM MY YOURS
vec_set 3 3
vec_sub 3 3
vec_add 2 2
vec_length 2 2
vec_normalize 2 2
c_trace 1 1
* 1 1
- 1 0
+ 0 1
local_vars 2 1
external_vars 2 3
Note: I didn't take into account the extra if and return your function has, since I think its a nice safeguard and will incorporate that into mine (and didn't count the extra debug instructions in mine since they will be removed). I'm still thinking how to reduce the amount of instructions needed though (It may not be that critical, but I'm usually very strict with my code's speed and efficiency), function by function little ineficient code can end up acumulating to something noticeable. I am used to first getting things to work and then revising it's speed efficiency (even where aparently not necessary), but it will have to wait, have to see my gf now, and go to my father's birthday later tonight.
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391646
01/14/12 15:25
01/14/12 15:25
|
Joined: Apr 2007
Posts: 3,751
Canada
WretchedSid
Expert
|
Expert
Joined: Apr 2007
Posts: 3,751
Canada
|
The only thing that really is cost intensive is the c_trace, everything else doesn't really matter. And even the c_trace() won't have any noticeable performance impact unless you do it a thousand times/frame.
Shitlord by trade and passion. Graphics programmer at Laminar Research. I write blog posts at feresignum.com
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391650
01/14/12 15:49
01/14/12 15:49
|
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB
Expert
|
Expert
Joined: Feb 2008
Posts: 3,232
Australia
|
I am stating the following MOSTLY from experiences, rather than written facts.
I BELIEVE the embedded commands give a small improvement.
And some of them more than others. I do the embedding as a personal
preference towards compact code more than speed.
I'll use the example of 'vec_normalize' to SUGGEST there is some speed
improvements to be gained by embedding.
'vec_normalize' CAN be embeddind in other commands, but you will see that
I never do so. That is because OCCASIONAL compiles will generate a
'empty pointer' error at run-time at the 'output' time of the vec_normalize.
I suspect that the embedding is 'out running' the commands ability to update the data.
Whereas exactly the same code JUST with the 'vec_normalize' NON-embedded works fine.
This SUGGESTS that the embedded code is running faster.
I have never actually tried any time-elapsed tests...
But I know for a FACT that creating/destroying LOCAL vars does slow things down.
Thats why you will often examples of my code around that use STATIC local vars.
These only get created once, but CAN cause problems if more that one instance of
that function is running, cause they will "share" thar var... AND that var will
remain set at the SAME value it was at when the last instance of the function ended.
And accssing GLOBAL vars is no faster OR slower than local ones.
If you truly want to scorch you brain with optimising at the expence of readability,
look at ALL the VEC_??? functions being used. If you check the manual, you
will find many of them show the actual CORE algorithms they use.
Replace those VEC_??? calls with its intrinsic algorithm and you WILL gain speed.
Also, in some situations you may see you dont actually need the WHOLE algorithm,
and so you can leave some off. More time saved.
BUT, some of the VEC_??? commands do have some error-protection you will lose,
and others have data type-casting 'adptatability' that you will lose.
And none of this is mentioned in the manual, so its hard to say what you are
losing, and you aint going to be gaining THAT much...
Oh... and the 'readability' of you script will go to hell, AND you will find it
hard going to find people willing to help debug something like that... let alone able...
And another thing to think about.. Youve spent DAYS generating the code,
and spent WEEKS debugging the bastard...
And NOW you want to take your pretty tested code and butcher it into an
un-recognisable mess that will need de-bugging ALL OVER AGAIN!! And this time
most of the code will be un-intelligble algebraic gibberish.
And all to gain 3 or 4 FPS?? At best?? Nuts! IMHO.
But ... each to their own.
"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
|
|
|
Re: rotation around a sphere
[Re: EvilSOB]
#391720
01/15/12 11:24
01/15/12 11:24
|
Joined: Oct 2008
Posts: 513
Carlos3DGS
OP
User
|
OP
User
Joined: Oct 2008
Posts: 513
|
Thanks for the info and tips! I'll start to work on the next part (at least for a couple hours I have free today). Making it walk to places (no fancy pathfinding or anything complicated, just simple "look towards objective - move forward"), either to another object on the planet surface or to a mouse click on the surface... Shouldn't be too hard. If the object is aligned according to its spherical co-ordinates rather than the normal beneath it, you can just translate the destination into a position relative to the object's orientation (vec_rotateback) and rotate the object's pan (relative to its z axis) towards that point. Since you use actual surface normals, we can set up a temporary angle that uses the spherical co-ordinates instead. I'm kinda confused, so I will try to start planning it all out and see if along the way it all starts to make more sense to me.
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391737
01/15/12 14:06
01/15/12 14:06
|
Joined: Oct 2008
Posts: 513
Carlos3DGS
OP
User
|
OP
User
Joined: Oct 2008
Posts: 513
|
I have been giving it some thought and after several diagrams (more than I would like to admit), I think I have finally understood what you said. Would it be something like this?:  (p)=point (V)=vector I'm still kind of stuck figuring out how to calculate how to rotate it... -I assume the vector being rotated would be Real_Path=(Destination-Moving_Vehicle). -And the rotation would be centered around Moving_Vehicle (giving me Temp_Path as the result). -Then I could calculate Temp_Destination=(Moving_Vehicle+Temp_Path). But I am still not sure how to calculate by how much I want Real_Path to be rotated. And I am completely lost about the last step: how to calculate the local pan for Moving_Vehicle looking towards Temp_Destination EDIT: I think I got the first part figured out:
void look_at(ENTITY* Vehicle, VECTOR* Destination, ENTITY* Planet)
{
VECTOR V_Nrml;
VECTOR V_Path;
ANGLE Rotation;
//get our vehicle's normal to the planet
vec_diff(V_Nrml,Vehicle.x,Planet.x);
//get the direction to our destination
vec_diff(V_Path,Destination,Vehicle.x);
//translate the destination to our plane
vec_to_angle(Rotation,V_Nrml);
vec_rotateback(V_Path,Rotation);
//make our vehicle look towards the new path
//???
}}
Edit2: Or mabe I'm just stuck cause I have not understood you correctly and am going in the wrong direction...
Last edited by Carlos3DGS; 01/15/12 18:26.
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391971
01/17/12 19:40
01/17/12 19:40
|
Joined: Oct 2008
Posts: 513
Carlos3DGS
OP
User
|
OP
User
Joined: Oct 2008
Posts: 513
|
I have been stuck on this problem for the last few days and cannot seem to get it working correctly. Any help would be great. I have gone through various different aproaches to the problem, this is my current one:  Transforming the positions:-First I take the position of my origin (vehicle to be moved) and calculate the angle I would need to rotate that vector by if I wanted it at the center (north pole). -then I rotate the destination by that same angle. Calculating angles:-In a temporary variable I store the pan our vehicle would have if it was looking at our new destination from the center. -In another temporary variable transform our vehicle's current angle to what it would have if it was stating straight (aligned to north pole). Calculating the final result:-I subtract the pan of our two stored (temporary) angles to get the difference between the two. -I ang_add() the difference of both pans to our vehicle's angle (to get a pan rotation aligned to it's local axis). Current code:
void look_at(ENTITY* Vehicle, VECTOR* Destination, ENTITY* Planet)
{
VECTOR Dest;
VECTOR V_Nrml;
ANGLE V_Ang;
VECTOR V_Path;
var Displacement;
ANGLE T_Ang;
//get our vehicle's normal from the planet core
vec_diff(V_Nrml,Vehicle.x,Planet.x);
//get vehicle's absolute angle from core
vec_to_angle(V_Ang,V_Nrml);
//transform it to angle from the top of our planet
V_Ang.tilt=90-V_Ang.tilt;
//translate Path
vec_diff(V_Path,Destination,Planet.x);
vec_rotate(V_Path,V_Ang);
//get our absolute pan angle towards new path
vec_to_angle(T_Ang,V_Path);
//get our vehicle's absolute pan angle
vec_set(V_Ang,Vehicle.pan);
alignToVec(V_Ang, vector(0, 0, 1), vector(0, 0, 1), 1);
//get the difference in angles
Displacement=V_Ang.pan-T_Ang.pan;
//rotate vehicle's local axsis
ang_rotate(Vehicle.pan,vector(Displacement,0,0));
}
|
|
|
Re: rotation around a sphere
[Re: Carlos3DGS]
#391998
01/18/12 03:49
01/18/12 03:49
|
Joined: Mar 2006
Posts: 3,538
WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
I was thinking something like this:
void look_at(ENTITY* Vehicle, VECTOR* Destination, ENTITY* Planet)
{
VECTOR V_Nrml;
ANGLE V_Ang;
VECTOR V_Path;
// copy my angle
vec_set(V_Ang, Vehicle.pan);
//get our vehicle's normal from the planet core
vec_diff(V_Nrml, Vehicle.x, Planet.x);
// orientate temporary angle as if on a perfect sphere
alignToVec(V_Ang, V_Nrml, vector(0, 0, 1), 1);
// get destination position relative to the vehicle's orientation
vec_diff(V_Path, Destination, Vehicle.x);
vec_rotateback(V_Path, V_Ang);
// convert to an angle
vec_to_angle(V_Ang, V_Path);
// now, V_Ang's pan is our angle
ang_rotate(Vehicle.pan, vector(V_Ang.pan, 0, 0)); // maybe ang_add?
}
That's kinda what I had in mind. Not really tested, but hopefully the idea comes across.
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Moderated by mk_1, Perro, rayp, Realspawn, Rei_Ayanami, rvL_eXile, Spirit, Superku, Tobias, TSG_Torsten, VeT
|
