Add flip convenience method to transform

[Lubba-64]

Objective

• Add convenience methods for flipping the transform scale for animations and the like for all axes.

Solution

• Add flip_x, flip_y and flip_z to Transform

Testing

• Doctests are included

[janhohenheim]

Nice idea! Some comments:

• The API looks a lot as if dir was the mirroring axis, i.e. "flip around this axis". But that's not quite true, dir simply says which coordinate vectors to flip. This probably a naming issue, and I unfortunately don't have an immediate solution in mind.
• Looking at rotate_axis, we probably should also offer flip_y, flip_x, and flip_z as convenience.
• If this API accepted Vec3 we could do the following call, which reads kinda neatly:

transform.flip(Vec3::Z + Vec3::X);

Lastly, I don't think this fixes #4930, as this does address the hierarchy aspect. Flipping a sprite by Vec3::Y will still break all existing Z offsets on descendants.

[janhohenheim]

@NthTensor @mweatherley maybe you or some other mathy people can chime in on whether my naming worry regarding the mirroring axis is justified.

[Lubba-64]

Darn i did not consider that just inverting the scale would not be enough to get this to work. Unfortunate. For my use case in animation these would probably work fine despite that. I will unmark this as fixing that, and make all the other good suggested adjustments

[mweatherley]

@NthTensor @mweatherley maybe you or some other mathy people can chime in on whether my naming worry regarding the mirroring axis is justified.

Yeah, I think that's reasonable. I think that taking Dir3 as an input is also probably just over-engineered; a general direction doesn't seem to have a particularly natural interpretation. To me, my_transform.flip_x().flip_z() seems completely fine.

[Lubba-64]

transform.flip(Vec3::Z + Vec3::X);

I like this but I am now thinking that just transform.flip_x().flip_y() is better than the over engineered solution I had. I think maybe only those methods and not including flip is a good idea.

[janhohenheim]

@Lubba-64 completely valid :)

[IQuick143]

I like this API much more.

[mockersf]

I don't think this needs to be built in in Bevy. they are convenience but very niche, and taking the name only it's not obvious what they do. just inverting the scale is simple enough and what most people will try anyway without looking for dedicated functions in my opinion

[NthTensor]

Yeah, I haven't been following this but I of agree. It looks like this was originally a different change which was cut down, and while it is mergeable it doesn't really seem justified. I do appreciate you working on this, can you explain what you are going for here?

[janhohenheim]

(Not OP, but I've been following along)
@NthTensor originally, this tried to address #4930, but it does not handle cascading (flipping Z on a parent leaves all child-sprites with wrong offsets).
Agreed that it has fairly limited usefulness, that's why I did not approve it yet. I want to note however that multiplying by a negative scale is not something that plays well with method chaining, so there is some potential here.

[Lubba-64]

I think based on the discussion I need to revisit my implementation and close this PR as it does indeed not solve the target issue.