Geometry Nodes: Implicit Conversion from Color to Rotation Not Working #124797

New Issue

Simon Thommes · 2024-07-16T17:20:26+02:00

Simon Thommes commented

2024-07-16 17:20:26 +02:00

System Information
Operating system: Linux-6.8.12-gentoo-x86_64-AMD_Ryzen_9_5950X_16-Core_Processor-with-glibc2.39 64 Bits, X11 UI
Graphics card: NVIDIA RTX A6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.90.07

Blender Version
Broken: version: 4.2.0, branch: blender-v4.2-release, commit date: 2024-07-16 06:20, hash: a51f293548ad
Worked: (newest version of Blender that worked as expected)

Short description of error
Since color to vector and vector to rotation work implicitly and the implicit conversions should be transitive where possible, color to rotation (and vice versa) should work just as well.

Exact steps for others to reproduce the error

add new Geometry Nodes node-tree
connect color socket to rotation socket

**System Information** Operating system: Linux-6.8.12-gentoo-x86_64-AMD_Ryzen_9_5950X_16-Core_Processor-with-glibc2.39 64 Bits, X11 UI Graphics card: NVIDIA RTX A6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.90.07 **Blender Version** Broken: version: 4.2.0, branch: blender-v4.2-release, commit date: 2024-07-16 06:20, hash: `a51f293548ad` Worked: (newest version of Blender that worked as expected) **Short description of error** Since color to vector and vector to rotation work implicitly and the implicit conversions should be transitive where possible, color to rotation (and vice versa) should work just as well. <img width="876" alt="image" src="attachments/8e748ca2-dba3-4051-ab03-20dd39f78613"> **Exact steps for others to reproduce the error** - add new Geometry Nodes node-tree - connect color socket to rotation socket

image.png

66 KiB

Simon Thommes added the

labels 2024-07-16 17:20:27 +02:00

Iliya Katushenock commented

2024-07-16 18:25:41 +02:00

Rotation in any case will be just 1.0 for scalar. This means that we just can not support all possible types, there is just no geometrycal mean for that.

Hans Goudey commented

2024-07-16 22:46:31 +02:00

I don't agree that all implicit conversions should be transitive. Things will get much less defined as we propagate that logic. It would mean we would have boolean to rotation conversions, for example.

Simon Thommes commented

2024-07-17 10:50:13 +02:00

Things will get much less defined as we propagate that logic. It would mean we would have boolean to rotation conversions, for example.

Yes. I guess this is something to be discussed, but imo there is no reason not to fall back to the most reasonable conversion when there is a simple vector representation of a socket that we already do implicit conversion for.

> Things will get much less defined as we propagate that logic. It would mean we would have boolean to rotation conversions, for example. Yes. I guess this is something to be discussed, but imo there is no reason not to fall back to the most reasonable conversion when there is a simple vector representation of a socket that we already do implicit conversion for.

Iliya Katushenock commented

2024-07-17 10:55:42 +02:00

What the point of using Euler angle (with range [0.0, pi * 2]) as color (with range [0.0, 1.0])? Or there should be some other way to convert quaternion to color?

Simon Thommes commented

2024-07-17 11:26:28 +02:00

With nodes you don't always care about exact values, especially in cases where you would rely on implicit conversion. My specific use-case here would be to use an un-normalized noise texture to drive a rotation for randomization based on a texture.

The color socket does not imply the range [0,1] anyways.

With nodes you don't always care about exact values, especially in cases where you would rely on implicit conversion. My specific use-case here would be to use an un-normalized noise texture to drive a rotation for randomization based on a texture. The color socket does not imply the range [0,1] anyways.

Iliya Katushenock commented

2024-07-17 11:49:08 +02:00

Is there is some obvious difference between Rotation data type and Transformation one in such use-case? I mean, this is not trivial data types and any time you try to apply simple logic like Color->Rotation this mean that we have to choose some non-trivial way to do that. Basicaly, we even can use random to peform such convertion in such use case, there is no some an mathematical well defined rule or convention in the programming to choose something certain\

Simon Thommes commented

2024-07-17 12:52:42 +02:00

I mean yea. That's where we need to apply reason and make choices that lead to useful and understandable behavior. I don't think only ever sticking to what is mathematically well defined gets us anywhere in terms of good UX, we need to make reasonable decisions whenever something isn't and stick to it.
Not saying that's easy or always possible but at least we need to have a discussion about it.

Here imo, since vectors and colors are treated largely as interchangeable, it's reasonable to do the same implicit conversion via Euler rotation.

I mean yea. That's where we need to apply reason and make choices that lead to useful and understandable behavior. I don't think only ever sticking to what is mathematically well defined gets us anywhere in terms of good UX, we need to make reasonable decisions whenever something isn't and stick to it. Not saying that's easy or always possible but at least we need to have a discussion about it. Here imo, since vectors and colors are treated largely as interchangeable, it's reasonable to do the same implicit conversion via Euler rotation.

Pratik Borhade commented

2024-08-02 10:17:05 +02:00

What the point of using Euler angle (with range [0.0, pi * 2]) as color (with range [0.0, 1.0])? Or there should be some other way to convert quaternion to color?

Hi, If adding [0, 180deg] works with another vector, then why not to convert "rotation to color"? 👀
Looking at geometry_node_tree_validate_link, case for SOCK_ROTATION --> SOCK_RGBA is missing.
I wonder where is the code for implicit conversion (type_conversion.cc?)
Confirming for now.

> What the point of using Euler angle (with range [0.0, pi * 2]) as color (with range [0.0, 1.0])? Or there should be some other way to convert quaternion to color? Hi, If adding [0, 180deg] works with another vector, then why not to convert "rotation to color"? 👀 Looking at `geometry_node_tree_validate_link`, case for SOCK_ROTATION --> SOCK_RGBA is missing. I wonder where is the code for implicit conversion (`type_conversion.cc`?) Confirming for now.

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry Nodes: Implicit Conversion from Color to Rotation Not Working #124797