Requested by @Simon Thommes (simonthommes)

# Diff Detail

- Repository
- rB Blender
- Branch
- master
- Build Status
**Buildable 7177**Build 7177: arc lint + arc unit

### Event Timeline

Don't increase the size of `KernelObject` for this, memory usage matters since we can have millions of instances.

Further, it also wouldn't be correct for motion blur anyway, it needs to use the interpolated matrix.

@Brecht Van Lommel (brecht) I could compute these from the transform matrix or is there another way without extending `KernelObject`?

Euler rotation is a kind of unpredictable rotation.

It depends on the order of the axes which makes it not always look like what is displayed.

I'm not sure if it's a good idea that the rotation type is not the one defined for the object (this can confuse the user a little).

The rotation type should not depend on the object settings, shaders should be reusable for objects with different settings.

WIP changes.

Remove changes to KernelObject and DRW manager and use transform matrix to calculate values.

Mostly this is working but I'm getting different results than before which may be due to either using the wrong function in `math_rotation.c` or negative values.

Reworked, based on the following functions `transform_decompose` from Cycles `util_transform.cpp` and `mat3_normalized_to_eul` from Blender `math_rotation.c`.

This now takes into account negative scaling.

@Simon Thommes (simonthommes) can you test this patch when you get a chance, thanks

I've tested the patch

First off:

Together the scale and rotation always accurately describe the objects transformation.

However, the individual values don't match the transformation input in general, which is confusing to the user.

*Problem:*

It seems that the scale always returns all negative or all positive values for the axes:

Obj. transform >> Node output

- + + + >> + + +
- - + + >> - - -
- - - + >> + + +
- - - - >> - - -

(permutation invariant)

The rotation flips accordingly, so the combined transformation is always accurate.

The absolute of each axis' scale is always accurate.

*Idea:*

Knowing just the sign of any two axes' scale would be enough to deduce the correct scale, making also the rotation insusceptible to being flipped.

*Conlusion:*

I don't see that scale and rotation could be split from the transform matrix with definite result without knowing any additional parameters.

I still think this is an important addition to the Object Info node, as right now there is no way to deduce rotation or scale of an object without knowing one or the other (drivers aside).

So if @Brecht Van Lommel (brecht) does not see this as sufficient reason to increase the kernel size for the minimum of required additional parameters, I would call this implementation a good enough compromise.

The drawbacks should be noted in the manual though.

Big thanks for the implementation @Charlie Jolly (charlie) ! :)

Just tested this briefly and unfortunately this patch breaks shader compilation in Eevee.

After adding Object Info to node tree shader will become pink, except for node tree parts that were previously compiled.

Cycles works properly and functionality behaves great.

@Simon Thommes (simonthommes) Can you elaborate on your use case for this nose? For me it works fine and this rotation flipping behavior is actually ok.

My use case:

With setup above I have local space location but world space rotation and scale. By plugging/unplugging first three outputs I can decide what works in local space and what is world space.

That is pretty much exactly my use case as well. But specifically using only either rotation or scale is not accurate in every case (specifically negative scale values). Not a huge problem as it's only a marginal case but it can be confusing.

Combined they are always accurate, separate there are cases when they aren't. I'm not talking about periodic repetition of the rotation, that's totally fine.