hallo, i would like to create a racing game. u drive across hills. i know the normal of the hitted surface at corrdinate [x,y]. i need to know, how to rotate a field that it`s x-angle and y-angle do match the x/y-angle of the hitted surface. i am using matrizes to do the 3d-tranformations. if i calulate the x-angle of the given normal, and rotate the field everything is allright. is i calculate the y-angle of normal and do the y.rot, everything is also right; but both rotations in serial ---> crooked.

Could you explain your game in a bit more detail? I''m unsure of your specific definition of "x-angle" and "y-angle." A bit more information will help us find the answer!

Do you mean that you want the xy plane of the vehicle (the xy plane being the plane of the wheels) to be aligned with the hill surface (i.e., the plane of the vehicle is always perpendicular to the normal of the hill)?


Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

I''m not ignoring your question. I just haven''t come up with a quick way to describe the solution yet. Hopefully soon.

Also, since you have a registered user name, please do not post as an Anonymous Poster.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

here u can see the deasaster...
http://www.cs.uni-magdeburg.de/~sodeike/temp/RotApplet.html

OK,

Seeing your code helps me better see what you''re trying to do! The process of getting the normals to line up is actually the easy part. Maintaining the direction of orientation in the xy plane (your zrot angle) at the same time makes it tricky. I have some comments on how you''re rotating the square to line its normal up with the triangle normal. We''ll deal with zrot later.

I''m not sure what Java API you are using for your 3d math. I assume that OM.xrot() means "take the current orientation of the object and rotate it about the x axis by the given angle." Is this true? (Another interpretation is that OM.xrot() means "set the rotation angle about the x axis to be the given angle.")

Here is why I believe you are unable to get the square''s normal to line up with the triangle normal when you try to do both x and y rotations. I believe you''re ignoring the fact that the normal of the square *changes* when you do the OM.yrot(). The normal of the square will actually be different after yrot() than before yrot(). Thus, if you are using the original values for normalSquare when you finally do OM.xrot(), your value of ddx is either too large or too small, and you aren''t rotating by the correct angle. The order of rotations is also important. You will get a different result if you do OM.xrot() first and then OM.yrot() second. Your approach may work if you grab the updated normalSquare before calculating ddx and doing xrot().

Is it possible in your 3D API to specify an angular rotation about an arbitrary given axis, perhaps as a quaternion? If so, you can do the following to the square to line it up with the triangle using one rotation:

1) Find the cross product of normalSquare and normalTriangle. Make it a unit vector. The resulting vector defines the axis to rotate about.

2) Find the angle between normalSquare and normalTriangle. Don''t worry about separating xrot and yrot. Just get one angle using the following formula:

dda = normalSquare[0]*normalTriangle[0] + normalSquare[1]*normalTriangle[1] + normalSquare[2]*normalTriangle[2]
angle = Math.acos(dda);
angle_in_degrees = angle * 180/Math.PI;

3) Do the rotation about the axis determined in step 1 with angle angle_in_degrees. If your API requires that you specify this as a quaternion, then the quaternion would be:

cos(angle/2) + i(ax*sin(angle/2)) + j(ay*sin(angle/2)) + k(az*sin(angle/2))

Where (ax, ay, az) is the unit vector found in step 1.

Note that the quaternion requires the angle in radians so don''t use angle_in_degrees for this.

4) After step 3, the normals should be lined up perfectly even when you rotate the triangle arbitrarily.

If your API cannot support rotation about an arbitrary axis, or if you don''t follow this approach, then can you list the code for doing *both* rotations on your sample web page? I can then help you adjust your code to get it to work.

Also, since your goal is to merely make sure the vehicle is always perfectly aligned with the surface, yet pointing in the direction of travel, there is an easier way to do the whole process, but it requires that your API be able to directly set the transformation matrix for the vehicle/square.


Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

i love the net:
http://www.cs.uni-magdeburg.de/~sodeike/temp/rot_better.html

Excellent!!!!! I'm happy to see it is mostly working.

About the remaining artifact. You'll notice that the normal is actually flipping too, so the polygon face is flipping 180 degrees and not just rotating within its plane. I have an idea about what's going on. Lets analyze it.

The square and triangle are always very close to aligned, and the correction of the square at each frame never needs to be a very large correction. The dot product, dda, for example, is probably always positive (unless the frame rate drops significantly or perhaps at the first step). In fact, if the normals are unit vectors then dda is usually going to be close to 1.0. That means your rotation angle will always be zero or slightly positive, since acos returns only zero or positive values from 0 to pi. So there's no weirdness going on with the dot product calculation, and the angle of rotation. The rotation angle will be small, so you wouldn't expect the normal to flip 180 degrees---and yet it does.

Lets look at the calculation of the axis of rotation, (ax, ay, az). Now *THIS* could be the cause of trouble. Consider that the triangle and square normal may be very close to one another in some cases. If they are, then it could be that the computed length of (ax, ay, az) is very nearly zero, and we don't really have a usable vector at all. Roundoff error in the quaternion calculation could result in some terms of the transformation matrix being zero when they aren't *really* zero. The behavior of your quaternion would be eratic in that case. I suggest you check and if fabs(length) < 1.e-6 don't do any rotation for that frame.

My guess is that the weirdness is occuring when normalSquare and normalTriangle are essentially parallel as described in the preceding paragraph. The only other thing I can think of is that perhaps your normalSquare and normalTriangle are *not* unit vectors. If they are not unit vectors then you are getting garbage out of acos and so your quaternion is bad. But since the thing is working most of the time I don't think this is the problem.

It seems to me you may have one remaining issue. How to orient the square so that it is pointing in the direction it is moving, while at the same time maintaining the normal alignment that you now have working. Is this still an open issue, or do you have the information you need?




Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Edited by - grhodes_at_work on July 9, 2001 1:40:40 PM

1.
well, u''re right, the anormal rotation happens when angle between the 2 normals becomes to close, but i can avoid this by initalising the square by a nice direction (sorry for my terribly engl. u know what i mean) and at least angle of surface will never become critical.
2.
quaternion -> rotation about an arbitrary axis (hmm, the normal of square :->)
3.
there is one more problem (i think the last one for this). please download this , extract and double-click to Cruzo.jar, or enter at shell java -jar Cruzo.jar . u''ll need the java JDK 1.3 to run it.
make sure num-lock is activated. use 4,6,8,2 at num-pad to move car (dont worry about stupid movement, just for testing). move it over a mountain. why does the car rotate about z-axis? (Car.java at:122-144) s.getNormalAtCoordinates(x,y) returns the unit-normal of surface hitted at (x,y - the green plane). i did everything as above mentioned. i''m perplexed a little bit.
4.thanx

sorry, the link does not work, try this or take it from http://www.cs.uni-magdeburg.de/~sodeike/temp/Cruzo.zip.