next »

[jeepndesert]

I have two scenegraph objects, each with a 3x3 rotation matrix and a location point. How do I make the two objects push away from each other and pull towards each other. I figure you want to do a lookAt and translation for both objects. What are the specific parameters to pass to lookAt?

Another thing I had a difficult time coding is zooming on a scenegraph with a root branch group that has 2 rotation matrices and a translation matrix. Then, each object on that root branch group have their own rotation, scale, and translation matrices. Each object in the scenegraph needs to be scaled and then, I need to scale their positions. For some reason I haven't gotten it to work yet.

[Marvin Fröhlich]

I have two scenegraph objects, each with a 3x3 rotation matrix and a location point. How do I make the two objects push away from each other and pull towards each other. I figure you want to do a lookAt and translation for both objects. What are the specific parameters to pass to lookAt?

Do you want to move the two Nodes away from and towards each others? Isn't this a case for a physics engine then? I advise you to tkae a look at JOODE and ODEJava. Both are discussed on javagaming.org.
A physics engine wuold do the translation maths for you and you would only need to apply them to the scenegraph objects.

If you only want to make the Nodes look at or face away from each others, then a transformed look at is the right thing. This means, you to a regular lookat and then transform it with the localtovworld transforms of the nodes.

Another thing I had a difficult time coding is zooming on a scenegraph with a root branch group that has 2 rotation matrices and a translation matrix. Then, each object on that root branch group have their own rotation, scale, and translation matrices. Each object in the scenegraph needs to be scaled and then, I need to scale their positions. For some reason I haven't gotten it to work yet.

Hmm... not sure, if I understood you right. But isn't this a cose for translating the view? Don't move/rotate/scale anyting in the scenegraph, but simply move the view (camera) around.

Marvin

[jeepndesert]

I was trying to stay away such a tool to get a finer grain of control to do things a physics engine doesn't do.

As far as the camera, the player is the camera, so player movement is the root transform group with a rotation, look rotation, and translation. everything else is attached to that transform group with their own rotation, translation, and scale (I scale the models).

My problem with lookAt is that I don't really understand how to get the parameters for it from a translation point and 3x3 rotation.

['n ddrylliog]

I was trying to stay away such a tool to get a finer grain of control to do things a physics engine doesn't do.

That's sensible until you realize you can have control over the physic engine you're using. If the JOODE team would object to the changes you require to have a "beautiful" code (which I believe you want), we can always integrate it in XPAL. What do you think of that ?

[Marvin Fröhlich]

As far as the camera, the player is the camera, so player movement is the root transform group with a rotation, look rotation, and translation. everything else is attached to that transform group with their own rotation, translation, and scale (I scale the models).

Do I get you right, that you transform the whole scene (by modifying the root transformgroup when you actually only want to move the camera? Isn't this overkill, Master?

My problem with lookAt is that I don't really understand how to get the parameters for it from a translation point and 3x3 rotation.

You jut have to keep the parameters separately outside of the matrix. This means: Store three Tuple3f with the lookAt information separately and manipulate them as you want. Then use them as lookAt parameters. But never discard them and try to read this information directly from the 4x4 matrix. This is the easiest, fastest and most performant way.

Marvin

[jeepndesert]

I was trying to stay away such a tool to get a finer grain of control to do things a physics engine doesn't do.

That's sensible until you realize you can have control over the physic engine you're using. If the JOODE team would object to the changes you require to have a "beautiful" code (which I believe you want), we can always integrate it in XPAL. What do you think of that ?

The game is the end product and we'll only be beautiful enough for me to maintain it.

I guess you gave me the idea to look at JOODE to see how they implemented certain physics that I'm having problems implementing.

[jeepndesert]

As far as the camera, the player is the camera, so player movement is the root transform group with a rotation, look rotation, and translation. everything else is attached to that transform group with their own rotation, translation, and scale (I scale the models).

Do I get you right, that you transform the whole scene (by modifying the root transformgroup when you actually only want to move the camera? Isn't this overkill, Master?

My problem with lookAt is that I don't really understand how to get the parameters for it from a translation point and 3x3 rotation.

You jut have to keep the parameters separately outside of the matrix. This means: Store three Tuple3f with the lookAt information separately and manipulate them as you want. Then use them as lookAt parameters. But never discard them and try to read this information directly from the 4x4 matrix. This is the easiest, fastest and most performant way.

Marvin

I'm more of the submissive type, but the thing that confuses me about lookAt is the up vector. How do I get the up vector from the transformation matrix?

[jeepndesert]

And regards to over-kill, I did shamefully over-kill in that the objects have two sets of transformations, one for global translations (between star systems) and local translations (within a star system). I need to switch everything over to global and divide global by 100,000 miles for local translations.

[Marvin Fröhlich]

I'm more of the submissive type, but the thing that confuses me about lookAt is the up vector. How do I get the up vector from the transformation matrix?

I'm not totally sure. But wouldn't it suffice to multiply a (0, 1, 0, 0) vector from the right by the 4x4 transformation matrix, or a (0, 1, 0) vector by the 3x3 rotation matrix (which is a little slower, since you first need to extract the 3x3 matrix from the 4x4 one)? Maybe you first have to invert the matrix. But I think, you don't.

But hey, you're of a submissive type. So isn't submitting your separately held tuples to the lookAt() method, what you want?

Marvin

[Marvin Fröhlich]

Hey, and isn't there a getter in the View class to directly retrieve the up-vector? If I remember right, I once added three getters to request the up-, facing- and right-vectors. Check it out.

Marvin

[jeepndesert]

Thanks for the help. I'll check into it. I'll just have to work at it until I figure it out.