Cascade of transformations inheriting from Drawable?

[nitram_cero]

Hi, I'm willing to implement cascading transformations for a skeleton system.

Children joints would have to be transformed as the parent previous to their own transformations.
This will allow me, for example, to have a translated hat as a children of the head joint, but when applying a rotation to the head... the hat would rotate acordingly and be correctly positioned.

If I draw a sprite inside my joint's Draw() function (derived from Drawable), is there a way to make it multiply the transformation matrix (glMultMatrix) instead of loading it (glLoadMatrix)?
Same goes for any drawable (as I will be drawing a Joint tree structure having Sprite's for leafs)

Thanks
-Martín

[Imbue]

It already works that way. Anything drawn inside of a Drawable's Draw function has its matrix multiplied.

The problem you'll run into next is Z order. OpenGL would handle that too, for free, but I don't know of a good fix with SFML. I found it odd that SFML supports shaders (which my target audience won't have support for) but not Z buffers (which has been supported for-nearly-ever).

See:Manually setting Z-order

Another problem you may have is transforming mouse coordinates down several hierarchy levels. Although SFML has functions for this, they're broken after one level.

IMHO, SFML's biggest limitations for graphics right now is no Z order support and no matrix abstraction. I've found straight OpenGL a viable alternative for specific applications (characters) and SFML's sprites good for general purpose stuff.

Just my two cents.

[Laurent]

It already works that way. Anything drawn inside of a Drawable's Draw function has its matrix multiplied.

Correct.

The problem you'll run into next is Z order. OpenGL would handle that too, for free, but I don't know of a good fix with SFML. I found it odd that SFML supports shaders (which my target audience won't have support for) but not Z buffers (which has been supported for-nearly-ever).

There are three simple reasons why SFML doesn't use Z-Buffer:
- It's not necessary
- It can be disabled explicitely by user on window creation
- It may not be supported; even if probability is very low it is not acceptable to base a core feature on it.

Another problem you may have is transforming mouse coordinates down several hierarchy levels. Although SFML has functions for this, they're broken after one level.

Maybe it's going to be improved in SFML 2.0, who knows

[nitram_cero]

Thanks a lot for both of your comments!

No problems with z ordering, I'll have two branches for each Joint, one branch will be drawn before (back) and the other after the joint's own sprite (front).

No need for mouse functions, they're just for drawing.

Thanks again!
-Martín