Righ-handed co-ordinate system

General Discussion Other

cannibalf..

Righ-handed co-ordinate system

in General Discussion • Other • 1 year ago

Hi all,

I know this question has been asked a number of times, but I have not yet found a conclusive answer. From all available evidence, it is common knowledge that processing uses a left-handed coordinate system. Just to make sure everyone knows what I'm talking about: if you point your left thumb in the x-direction and your index/pointer finger in the y-direction, your middle finger will point to the z-direction. So in this case x-direction is to right, y-direction is downward and z-direction is a outward.

However, for my project, I need the coordinate system to be right-handed. This is so I can maintain consistency with other software that produce the 3D model I use and the analysis software which produces the results I would like to visualize (I have posted about this project here). I am doing some transformations of the input data and I don't want to deal with a different coordinate system (I am having issues understanding what I'm doing in the normal system).

I understand that there is no direct method of changing the coordinate system. I am just wondering if there is an indirect method which is simple and does not mess up my matrix operations.

Your help is greatly appreciated.
Ali

Replies(9)

amnon.owed

Re: Righ-handed co-ordinate system

1 year ago

When I look at the different coordinate systems:

I would say that to go from Processing's to OpenGL right-handed, you need to flip the Y: scale(1, -1, 1);

And generally to change the handed-ness of a coordinate system you flip the Z: scale(1, 1, -1);

But this logic may be flawed (and doesn't address the origin point of respective systems).

calsign

Re: Righ-handed co-ordinate system

1 year ago

You could use scale():

scale(-1, 1, 1);

EDIT: And... amnon.owed beats me to it...

carstentr

Re: Righ-handed co-ordinate system

1 year ago

Hi Ali

I'll [also] have to add a disclaimer on this one. At a time having got to making model-operations, I tried to make a mirror-function. And failed. It puzzled me for a while, but there were so many operations to implement that I just passed on. In a new release of the software i used (directX), I noted that Microsoft announced that they had added 'mirror' to the functions. This announcement reminded me, that it might not have been me that was fowl.

Flipping an axis seems reasonable. The data you have are in 'world-coordinates', so, to have the axis-flip throughout the whole setup, you'll probably have to start out in object-space.

In my last scribblings to your other post I devised a way to get from the world-space to the object-space for each block. In the perspective of the problem you present here, there could be a slight change in my suggestion.

If you subtract the center-vector from the position-vertices of a block [if need be], you have the block centered at (0,0,0). It's the alignment of the object-vectors here that you'll have to 'try' to get right (it's either one or the other way round the axis the object-coordinates should be turned).

As an educated geologist I have spent an embarrassing lot of time on getting to gribs with the 'matrix' thing ... it may take time for you too. In formal terms, you are looking for the inverse of the matrix that brought the object from object-space into world-space. If you keep translations and other transformations apart, the inverse matrix of turning the object alfa degrees around the y-axis is the one that turns the object -alfa around that axis. As for translation,there is the same obvious relationship. As you have noticed: the outcome of using a rotation matrix differs depending on the position [read:applied translation] of the object (in other words, it's a must to bring the object to (0,0,0) before involving the rotations, being it forward or inverse).

EDIT:

What you are up against is the program-need for efficient code. All small matrix operations are simple, but the draw-call can get away with just one transformation if you clamp all matrices into one single matrix before the call. Processing has it's own implementation of this (through the push/pop-matrix)

cannibalf..

Re: Righ-handed co-ordinate system

1 year ago

Well calsign's response works well.

I decided that I shouldn't change the input information. I do all my operations on the original data in the original coordinate system. However, when it comes to presenting it on screen I mirror the results to get the right view. I think this is a good approach. That way I know nothing funny happens when there is a change.

Now I have another problem. I am trying to plot a coordinate axis on the screen so I know my axis directions. I am doing something like:

void drawAxes(float length) {
noStroke();
strokeWeight(3);
stroke(255, 0, 0);
line(0, 0, 0, length, 0, 0);
stroke(0, 255, 0);
line(0, 0, 0, 0, length, 0);
stroke(0, 0, 255);
line(0, 0, 0, 0, 0, length);
noStroke();
}

However, I would actually like to plot this on the bottom left hand side and have it unaffected by zoom or pan operations of peasycam. I just want it to rotate when the rotation of the scene is changed. Is this possible? Can it be isolated? In case my description is not clear, here is what I'm talking about from AutoCAD:

Thanks for all the help.

calsign

Re: Righ-handed co-ordinate system

1 year ago

I don't know a clean way of doing this...

Looking at the PeasyCam source, the following method is used to change the camera position:

public void feed() {
final Vector3D pos = rotation.applyTo(LOOK).scalarMultiply(distance).add(center);
final Vector3D rup = rotation.applyTo(UP);
p.camera((float)pos.getX(), (float)pos.getY(), (float)pos.getZ(), //
(float)center.getX(), (float)center.getY(), (float)center.getZ(), //
(float)rup.getX(), (float)rup.getY(), (float)rup.getZ());
}

You could potentially negate that in translation...
And you can get the position with getPosition():

/**
* Where is the PeasyCam in world space?
*
* @return float[]{x,y,z}
*/
public float[] getPosition() {
final Vector3D pos = rotation.applyTo(LOOK).scalarMultiply(distance).add(center);
return new float[] { (float)pos.getX(), (float)pos.getY(), (float)pos.getZ() };
}

For implementing that, you're on your own...

cannibalf..

Re: Re: Righ-handed co-ordinate system

1 year ago

Hi calsign,

Well I think two things provided by peasycam could be used to achieve this:

1) you can draw things on the screen that would remain unaffected by the manipulation performed by peasycam using beginHUD() and endHUD() commands.

2) you can get the current rotation of the camera (I think it is the camera) using peasycam method getRotations().

Now I used the first tool to draw my three axis. This worked fine. Then I used rotateX, rotateY, rotateZ to use the camera rotations provided by peasycam to rotate my axis. This worked reasonably well.

But the main issue is that I need the axis to be draw in ortho mode, that is to have no perspective. That is because when you are looking down, for example, you should not see the z-axis (or just see the arrow tip). I know I can use ortho to get this to work, but that changes the entire drawing which is not what I want. I just want the axes to be drawn in "parallel projection" mode.

I've been trying to come up with a code that take peasycam's rotations and just draw the axis in 2D and fake their rotation, but I just can't get the right combination of sin and cos to this.

Any ideas?

calsign

Re: Re: Righ-handed co-ordinate system

1 year ago

You can't just call ortho(), draw the axes, and call perspective() again?

cannibalf..

Re: Re: Righ-handed co-ordinate system

1 year ago

I tried that but it wouldn't work. Here is what I tried:

float[] rot = pCamera.getRotations();
ortho();
pCamera.beginHUD();
pushMatrix();
translate(60, height - 60, 0);
rotateX(rot[0]);
rotateY(rot[1]);
rotateZ(rot[2]);
strokeWeight(3);
//x-axis
stroke(0, 255, 0);
line(0, 0, 0, 30, 0, 0);
//y-axis
stroke(255, 0, 0);
line(0, 0, 0, 0, 30, 0);
//z-axis
stroke(0, 0, 255);
line(0, 0, 0, 0, 0, -30);
popMatrix();
pCamera.endHUD();
perspective();

But it not only doesn't plot the axis anymore but also messes up the other drawing as well.

PS: If it makes it easier, I can send you my files. Maybe something I'm doing somewhere else is causing all this pain.

carstentr

Re: Righ-handed co-ordinate system

1 year ago

" Now I have another problem. I am trying to plot a coordinate axis on the screen so I know my axis directions."

The " my axis directions" would be the direction-vector of the camera itself, right?

If you think of the camera as a vertex with position and 'direction' .. it'll only have qualities that you once already has put into it.You should be able to keep track of what's been done in terms of rotations. So, you want to look at the initial world axis-unite vectors after they've been transformed by the camera-rotation.

You ought to be able to make a draw call on it's own, for just this item. If you start out with erasing the screen and not erase it on the next call that draws the other objects then you ought to have the simplest setup.

Alternatively you could let initial unite vectors be drawn at a fixed position relative to the camera.

The only way you can interact with your model while program is running is by way of the camera. You should prepare yourself for some 'real-time' juggling with vectors and quantities that relates to it. You could find the 'forward' vector of the camera, and from that (and the camera-position) find out the position of the unite vectors. If you haven't found out by now, you'll probably find that it's worth keeping the camera-up vector constant.