translation

[raft]

hi,

i've figured that, translation info in Object3D's rotation matrix effects where the object is rendered.

for example, this box is rendered at 1,0,0 point

Code Select Expand

Object3D box = Primitives.getBox(1, 1);
box.getRotationMatrix().set(3, 0, 1f);


is this intentional ?

[EgonOlsen]

Yes, that's because it's part of the object space->world space transformaation, which basically is a sequence of matrix multiplications. The translation matrix behaves a little different, but that's just an implementation issue.

[raft]

i see. is it possible to add a method SimpleVector.rotate(Matrix) which only uses the rotation information in matrix ? it would be very handy. otherwise one should copy matrix into a new one, clear translation and call SimpleVector.matMul(Matrix) or make the multiplication himself

[EgonOlsen]

Yes, i can add that. On the other hand...why do you put translations in the rotation matrix? That's not where they belong IMHO.

[EgonOlsen]

Here you go: http://www.jpct.net/download/beta/jpct.jar

Edit: matMul and rotate are also a tad faster in this version, because i've removed the unneeded de-referencing that those methods were doing.

[raft]

i'm converting Ardor3d skeleton to jPCT. it uses Transform's which consist of a rotation, translation and non uniform scale. ignoring the scale, jPCT Matrix is a good fit. it's invert is also used and Matrix.invert also fits that. multiply it with a vector and switch to joint/world space

[raft]

cool, fastest reponses are always here, thanks

[EgonOlsen]

No problem. What's the issue with the scale? As long as you don't assign it as a rotation matrix to an Object3D (the lighting might react a bit strange then for uncompiled objects), it should fit into the rotational part of a Matrix-instance just fine!?

[raft]

no issue for now yet. Ardor's sample does not use scaling and i ignore it for now

[EgonOlsen]

I see. Maybe i should give a little more information about the potential problem that jPCT may have with rotation matrices that include non-uniform scaling. It's only a problem if you assign such a matrix to an Object3D as rotation matrix. If you never do this and use it in combination with Matrix and SimpleVector, it's all fine. If you assign it, it will basically work in the way it's supposed to work, i.e. you'll get a non-uniformly scaled Object3D. What won't work, are two things: You can't use scale() or setScale() any longer, because you'll get strange results. That may not matter, because you are obviously doing the scaling on your own anyway. The second and more important thing is, that the lighting intensities will become wrong. When calculating the lighting, jPCT has to apply a correction factor based on the scaling. If it doesn't know the scaling, the correction just isn't correct and your objects will appear either too dark or too bright. This applies to the software and the default hardware renderer. It will most likely not apply to compiled objects, but i've never tested this.

[raft]

thanks. i will remember these

[EgonOlsen]

If it's really needed to assign these matrices to an Object3D in the future, i can add a work around of some kind for this. I just don't want to break the current implementation of how uniform scaling works in jPCT, because i've no idea how many applications rely on it.

[raft]

indeed, i only use regular SimpleVector.matMul(Matrix) method is deforming mesh. this additional method is required for replicating Ardor's demo in jPCT: programatically position bones and joints

[EgonOlsen]

If it's really needed to assign these matrices to an Object3D in the future, i can add a work around of some kind for this.

I'll quote myself here...i've thought about this some more. There were different options:

• rewrite the whole scaling stuff from scratch
• add the ability to detect the faulty situation and correct it at runtime
• add a method to leave it up to user to decide if the fix is needed or not

The first one is out of question for me, because it breaks too much of the existing code...even if it would have been the cleanest solution of all three. The second one is somehow appealing but also feels awkward in a different way. Plus it would require some extra processing, that usually isn't needed. I decided to add the third option. It's easy to add and if you are in the situation that you are fiddling around with the rotation matrix, you know what you are doing anyway. So this additional method is not that bad. And if you never do such things, you never have to use it.

[raft]

you said this in some post, but couldnt find it now. adding a method Matrix.get(row, column) would also be handy