a tree of geom transforms

[gsaurus]

I just wanted to make sure this is right.

I want to render a composed object by applying a tree of 2D geom transformations before rendering the leafs (like on VRML, openGL, etc, but only using SFML).
So I'm going to extend a class from Drawable that owns other drawable objects. On the render function I call the draw of the children drawables.
The leafs are sprites, text, etc.
This will work just perfect, right?

[Laurent]

Yes sir.

[gsaurus]

Ok, I have my drawable objects tree, but I got confronted with one thing:

I want to flip my whole tree of drawables by scalling it's root by -1. But sf::Drawable::SetScale methods only accepts positive values.
With this limitation, I'll have to multiply all the drawables translations by -1, change their centers and flip sprite images all over the tree!

We can flip a sprite image, but we can't actually flip a sprite over it's center. To do that we have to flip the image and change the center to size-center.
It's also impossible to flip a sf::String

I wish this positive check doesn't exist and let the user decide whether a negative scale can be useful or not, or give a "Mirror" method to sf::Drawable in case the Scale theoretical concept is being considered to be always a positive thing.

[Laurent]

Negative scales have some bad consequences on coordinates, and may create inconsistencies.

However I'll think about it, negative scale may indeed be very useful in certain situations.

[gsaurus]

Thanks
I'll implement a workaround somehow..

Edit:
I understand about possible inconsistencies (maybe a mirror concept helps?), but what bad consequences on coordinates do you say?

I tried applying my own scale factors on a Drawable derivated class, on the Render method by using glScalef before rendering the children drawables. On first tests it's looking ok.  :roll:

[Laurent]

Yes, it works perfectly fine. The inconsistencies I'm talking about are not visual, it's more about how this will affect the other functions.

I have no example to tell you right now, but I remember that it was why I added this limitation on scales.

[gsaurus]

how this will affect the other functions.

If you remember of something, let me know  :wink:

[Laurent]

Sure

[gsaurus]

Ok, I think I found the problem: the rotation transform (I was suspecting it was that)
If all transforms are set at once on the modelview, the final result with a negative scale isn't symmetric, because the rotation is performed after the scale (or something like that).

This morning I tried to fix it by defining and applying my own matrices, but I still didn't solved it completely. It's working only when the origin is (0,0). But I hadn't much time to work on it yet...
It was a long time since I learnt openGL at univ, so I don't remember well this things and how to solve it. But you should know better than me :wink:

This is also :?, I work on my engine on scare free times, but now I got this limitation to work around, slowing down my project a bit more
I could try to solve it ad hoc, but I'm not sure whether I'll need other methods (like transformToLocal), best would be to solve it once and for all  :roll:

Here, an example:
2 images with origin (0,0), position (100,100), and both rotated by 45º. One has scale (1,1), the other has scale (-1,1)



Left: Applying all transforms at once on the modelview matrix.
Right: Applying everything but rotation first, then rotation. (not working yet for different origins..)

[Laurent]

If all transforms are set at once on the modelview, the final result with a negative scale isn't symmetric, because the rotation is performed after the scale (or something like that).

It is symetric, because rotation is applied after the scale. It works just fine, and I don't think that negative scales will change that.
So what do you mean exactly?

[gsaurus]

Hm, I was expecting the negative scale to perform a symmetry like on the second image, it looks more natural and useful to me.
My characters will be composed of several drawable objects, some of them can be rotated or scaled. When they walk left and right they should act symmetrically.

But, if you say rotation order isn't the problem, what could be the reason for limiting scale to positive values?
Do you think you can give symmetric/mirror methods for drawable objects?  :roll:

[Laurent]

Ah, sorry I misunderstood your previous post. Now I see exactly what you want.

But, if you say rotation order isn't the problem, what could be the reason for limiting scale to positive values?

I don't remember, so I guess I'll remove the limitation and run a bunch of tests -- again

Do you think you can give symmetric/mirror methods for drawable objects?

Unfortunately, with the current API it seems impossible. The only "solution" would be to use a RenderImage (in SFML 2) to render your sprite, and flip it to produce the mirror effect. But that's kind of ugly :lol:

[gsaurus]

The only "solution" would be to use a RenderImage (in SFML 2) to render your sprite, and flip it to produce the mirror effect. But that's kind of ugly :lol:

Yeah, I though that too  
Well, negative scale should already be a good help, makes me no need to redefine scale fields and methods, which aren't protected nor virtual on SFML (makes all sense not to be), so a bunch of ugly changes are needed on my derived drawable class

[Laurent]

Hey, what about using a positive scale + FlipX/FlipY functions to simulate a negative scale?

I really need to find out why I did it that way...

[gsaurus]

Yes, I can do that simulation :wink:, still not great, but better than rendering on a temporary image  
I can use a bool variable on all my drawable tree, and when going to render, if it's flipped I multiply the translation of the node by -1, rotate by symmetric angle, change center/origin to GetWidth().x - GetOrigin().x, and in case it is a sprite node, flip image.
Even if I decide to flip some nodes but not others, I can pass my flip from parents to clildren to actually invert the flip state of the children, so by flipping the root (for instace), I invert all flip states of the nodes. I think I'll have to go with that.
In other words, I do my own symmetric/mirror method

I just was trying to understand if there is a way to do it simply with geometry