View Full Version : packing rotations per vertex

04-19-2006, 07:16 AM
using quaternions for rotations would save memory, but comes at a higher instruction cost.

I wonder if it makes sense to just send 2 axis vectors as shorts and compute the third via xpd and a multiplication for proper direction.
and creating the rotation matrix from those

would be less instructions I think.
This is for particle system and ARB_VP hardware.

04-19-2006, 08:11 AM
#1: what is xpd ?
#2: I haven't looked at it deeply but it seems that quaternions make rotation in a faster way than matrices.
#3: it seems this topic should best stand in the math & algo forum.

04-19-2006, 08:11 PM
For a particle system, I'd be inclined to store the camera basis in constants, then just deal with the billboard origin and a vector scale per vertex. Like a 4-vector that's zero every where but for the position of interest. That'll be 2 4-vectors per vertex, I think, plus the extra computations.

It seems to be the classic space-time tradeoff.

04-20-2006, 03:25 AM
xpd is teh cross-product i guess

Rotating with a matrix would be cheaper if you are not CPU-bound :-) You will have to send more data in, though...

04-20-2006, 05:43 AM
well I got vprogs for screen aligned billboards and global aligned billboards, but now wanted to have each particle have its own orientation. However still being able to rotate them around their "center".
so far I pack rotation as cos/sin per vertex along with index into offset array (four corners for quads or three corners for tris particles) and a scale factor, as well as center position.

I guess I have to test how much speed sending one more shortaxis costs compared to sending just one short quaternion and do rotation with it.
has anyone experience using quaternion rotation in their vertexprograms/shaders ?

04-20-2006, 12:00 PM
If you put your billboard radius in your position selector vector element, that leaves the billboard origin.w for the rotation angle, with the camera basis still in the constants. I might do the rotation on a texture matrix, unless the texture is visually bound to the geometry somehow and would lead to artifacts under rotation. In that case you could rotate the camera vectors in your shader. I'm just shooting for minimizing bandwidth usage here, so perhaps I've missed something in the bigger picture.