ok so i have been thinking about this for a quite of time, some people said that i should convert given vector to euler angles, it may be the solution but i tried to check the raw results

i know this drawing is not really helpfull but at least it shows the inital axes for the simulation for now. and those other lines which should show the direction in which force is acting additionally they are placedin the proper positions of force acting) welp only rudder force is translated way to high my mistake on the drawing sorry

Firstly simple explenation i have an aircraft that should get rotations when defflecting some surfaces

after deflecting one of surfaces i will call something like

var t3dpoint Torque = D * F; //RxF R - the position relative to center of mass, F the froce vector

var t3dpoint AngAcc = Torque / MOI; //get the angular acceleration

var double dt = 0.10; // time between frames

var t3dpoint AngVel = AngAcc * dt; //ang velocity

var t3dpoint AngMov = AngVel * dt; //actual change in angle

i checked it for elevator placed at the tail it returns the vector X, 0, 0 which is a correct result (as far as i understand that)

i checked rudder too and it returns 0 Y 0 vector which is correct too since x component of vector represents rotation around x axis, y around y axis, and z around z axis

problems occurs when i try to simulate airlieron on left wing it returns 0 Y Z instead of 0 0 Z and this is my problem maybe i am doing everything wrong and i was lucky to get these past two correct values.

they key are these two variables:

var t3dpoint D = <>(); which is R <- position relative to center of mass

and

var t3dpoint F = <>(); which is F <- force acting vector

code may be hard to read this is because i used my script for that (it saves a lot of time to check some things) instead i will have to recompile the project over and over and over even to change a vector which would take too long syntax is horrible too but keep in mind that i wrote that scripting lang in fw hours.

void ELEVATOR_CHECK()
{
//this function simulates one elevator on the tail where center of pressure is on the tail 45 

degree deflection in the direction of front and up if that returns x component to be non zero then 

 the pitching moment is around x axis

var t3dpoint D = <>(0#0#10);
exec[CALC_MOI];
var t3dpoint F = <>(0#2#-2);
}



void AIRLIERON_CHECK()
{
//this function simulates one airlieron on the left side 45 deg deflecction front up direction
roll moment should be returned around z axis

var t3dpoint D = <>(-10.0#0.0#0.0);
exec[CALC_MOI];
var t3dpoint F = <>(0#2#-2);
}


void RUDDER_CHECK()
{
//this function simulates one rudder on the tail 45 deg deflection front left direction
yaw moment should be returned around y axis

var t3dpoint D = <>(0.0#0.0#10);
exec[CALC_MOI];
var t3dpoint F = <>(-2#0#-2);
}


void CALC_MOI()
{
var double R = magnitude(D);
var double R^2 = R * R;
var double MOI = mass * R^2;
}

void main()
{
var double mass = 1.0;



?exec[ELEVATOR_CHECK]; returns ok vector 0.019 0 0

exec[AIRLIERON_CHECK]; returns 0 0.019 0.019 should return 0 0 0.019

?exec[RUDDER_CHECK];   returns ok vector 0 0.019 0


// ? actually means a comment not //



var t3dpoint Torque = D * F; //RxF

var t3dpoint AngAcc = Torque / MOI;

var double dt = 0.10;
var t3dpoint AngVel = AngAcc * dt;
var t3dpoint AngMov = AngVel * dt;

var double result = ShowMessage(AngMov);
}

var t3dpoint Torque = D * F;

Multiplication <*> is not the same as a vector cross-product.

From only the diagram you posted, and a description of the action of one control surface, I would expect rotation about both the Y and Z axes. As you provide no other information, I suggest you use actual numbers, a pad and pencil or calculator, and prove/disprove to yourself that 0 0 Z (whatever you mean by that) is correct.

buck the multiplication you posted is actual a vector cross, because when multiplying two vectors * operator returns vector cross product.

By actual numbers do you mean calculate everything with a proper mass proper inertia moment and distances, and proper forces?

a pad and pencil or calculator

thats why i used that script to speed up the calculations.

As you provide no other information,

i would really like to know what do else you want me to show.

every function sets up different D and F (to calculate Torque = D x F;)

in this case elevator should change pitch

airlieron roll

rudder yaw.

everything except airlieron returns one rotation.

you know

i set airlieron at -10, 0 ,0 from the center of gravity so the R vector is -10, 0, 0

i apply a force to it which is 0, 2, -2 a force that is directed in up front direction uhm uhm now i see that it can produce two rotations but since i did something similar for elevator how could i achieve one rotation on airlieron

i would really like to know what do else you want me to show.

Information that might help others help you determine the problem you're having.

You've posted in the Math and Physics forum. Math and physics are much like any languages - discussions can only take place if all participants share and accept a common understanding of the meaning of symbols used in the discussion - e.g., <*> is multiplication, </> is division, etc. Because gamedev also supports programming in several languages, that set of symbols is often extended to symbols and functions from those languages. Those symbols are accepted and meanings understood because syntax is well-defined and standardized, and the libraries for those languages have been proven - "proven" in the sense that users accept and understand that functions such as "XMVector3Cross" work correctly and, if applied correctly, will return correct results. That is, use of that function is likely not the source of problems.

For example, the following does not fall into the category of accepted error-free code:

multiplying two vectors * operator returns vector cross product.

For a program to work correctly, both data and code must be correct. Not only must code by syntactically correct, that code must be the correct sequence of operations to produce the desired results - i.e., the algorithm must be correct. Your code apparently uses custom classes and overloads that are not "proven" or accepted in the sense described above, so the data and code in your program may well be causing problems. There's no basis to assume that your data and code execute correctly.

Further, you wrote a "script" to perform calculations. There's no reason to accept that the results of that unknown method are correct, either.

I'm not saying that your script, code or data are incorrect, only that they may be incorrect. If so, and you're trying to determine if your code works correctly, that's not a math or physics question.

As you posted in the Math and Physics forum, for the reasons above, I ignored your code, and addressed just the physics- and math-related portion of your post.

I suggest you learn some debugging techniques to narrow down the problem. You need to verify that the data, the code and the algorithms in your program are correct.

ok i get your point however your first post was totally in 100% correct i just was using one airlieron to determine the rotation which obvious produce yaw moment too.

i added second airlieron to the code and it produces now correct roll without yaw,

math was good. code was good too :P

I ignored your code,

HOW COULD YOU ? :P

ok i get your point however your first post was totally in 100% correct i just was using one airlieron to determine the rotation which obvious produce yaw moment too.

i added second airlieron to the code and it produces now correct roll without yaw,

math was good. code was good too

I ignored your code,

HOW COULD YOU ?

for the reasons above

EDIT: And thanks for posting the resolution.

;]