Page MenuHome

Shading: Add rotation and scale outputs option Object Info Node
Needs ReviewPublic

Authored by Charlie Jolly (charlie) on Thu, Mar 12, 1:03 PM.

Diff Detail

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

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.Thu, Mar 12, 1:07 PM

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

This revision now requires changes to proceed.Thu, Mar 12, 1:07 PM

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?

You need to compute them from the transform matrix.

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

Remove unused function.

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) ! :)

Bartosz Moniewski (monio) requested changes to this revision.Sat, Mar 14, 8:08 PM

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.

This revision now requires changes to proceed.Sat, Mar 14, 8:08 PM

@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.

Attempt to fix GLSL bug.

Fix GLSL compile on Nvidia, somehow it worked on other compilers!

@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.