worldspace -> objectspace

Isn''t that just the inverse matrix? (Math people feel free to smack me down if I''m wrong.)

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

of course it is, but calculating an inverse matrix is expensive, an i have to do it several times per frame, i thougt maybe somebody knows a faster way (considering that the matrix contains only tranformation, scaling and rotation)
one idea i had was just store tranformation, scaling and rotation seperate, and than compute the inverse from that...but this will cause other problems. maybe I should explain the whole problem:
i'am using a 2d and a 1d texture to fake 3d textures on gf2 (using register combiners) for per-pixel-atentuation. because this is not a true 3d texture i can't use the 3rd dimension in the texcoords (and the texture matrix), so i have to transform the texcoords in software. it would be much faster to transform the lightsource to object space, but i have to inverse a matix for that...witch is slow. a faster way to do this (maybe in hardware) would be great.

[edited by - 123cs on June 1, 2002 11:57:47 AM]

[edited by - 123cs on June 1, 2002 11:59:58 AM]

Well, if your matrices only store 3x3 rotations, you could simply take the transpose. Doesn''t work with translation and scaling though. But since you''re doing the transformation on the CPU, you could simply multiply by the transposed rotation matrix and apply the scaling/translation afterwards (or before, depends on your matrix setup). This would be reasonably fast for lightsources.

/ Yann

well the idea is good, but i don''t have access to to world translation/scaling, because my objects are organized in a scene-graph, and a node only stores translation/scaling/rotation relative to its parent, and the world tranformation matrix(4x4), witch is calculated during graph updating.