You know shaders, you could always use the well documented matrix math or quat math methods to do a rot scale trans on data. Or write the same in gl.pix, or a matrix operator. Google, math libraries, etc are all your friend. e.g. http://gamedev.stackexchange.com/questions/61473/combining-rotation-scaling-around-a-pivot-with-translation-into-a-matrix

However, if you want to keep from writing your own code and just use native objects and attributes, what if you sent only the xyz plane values to a gl.mesh and used the rot scale trans attribs on it + a matrixout to do your work. Then you can merge those 3 plane back into the other planes of data as needed with a jit.concat

True - i forgot mesh takes in matrices, and can also output them. Obvious in hind sight. Thanks!

I didn't want to manage my own transforms because this should be 'out of the box', and that stuff is subtle, row/column order nuances and all sorts of shit.

Thanks though!

Hrm. Some quick experimentation indicates that jit.gl.mesh isn't actually changing any geometry that is input. Have you tried this before?

Yea, jit.gl.mesh does *not* handle matrix output

Time to manually hack matrices I guess.

a simple jit.gen will do the trick:

if you need to create transform hierarchies, you can use jit.anim.node. build your tree structure, and then at the leaf nodes simply query worldpos, worldquat and worldscale, and send those values to the jit.gen parameters in the above patch. if that doesn't make sense, let me know.

Thanks. I had finished implementing scale and translate earlier and was looking into rotation. You beat me to it. :)

Appreciate it Rob :)

Sorry about that Vade. It seemed so natural to me for jit.gl.mesh to have the standard behavior. Glad gen could help you instead.

No worries. I came across a few old threads lamenting the fact. I apparently had purged that small factoid from my mind. That and the fact that jit.gl.model won't load vertex colors got lost.