Nodes to convert between cartesian/spherical coordinates #94722

New Issue

Simon Thommes · 2022-01-07T18:36:15+01:00

Simon Thommes commented

2022-01-07 18:36:15 +01:00

There should be nodes to convert between spherical and cartesian coordinates in a standardized way.

This point came up when discussing D12746 .

They are multiple design aspects to be figured out:

Node layout
Naming and Scope
Units
Value Ranges

There should be nodes to convert between spherical and cartesian coordinates in a standardized way. This point came up when discussing [D12746](https://archive.blender.org/developer/D12746) . They are multiple design aspects to be figured out: - Node layout - Naming and Scope - Units - Value Ranges

Simon Thommes commented

2022-01-07 18:36:15 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Simon Thommes commented

2022-01-07 18:36:15 +01:00

Added subscriber: @SimonThommes

Simon Thommes commented

2022-01-07 18:39:07 +01:00

For usability I would suggest the following definitions:

Node layout:
- Like Separate/Combine XYZ
Naming and Scope:
- Components: Radius/Zenith/Azimuth -> R/Theta/Phi
- Maybe this could also be solved with more generic Combine/Separate Vector nodes that can have different 3D coordinate modes. E.g. Cartesian (X/Y/Z) (->default), Spherical (R/Phi/Theta), Cylindrical (Rho,Phi,Z)
Units: Radians, shown as deg for the UI (same as e.g. Vector Rotate)
Value Ranges: Phi [-pi, pi], Theta [-pi/2, pi/2]

Math:
x = R*cos(Phi)cos(Theta)
y = Rsin(Phi)cos(Theta)
z = Rsin(Theta)

Behavior like in this file:
separate_combine_vector.blend

For usability I would suggest the following definitions: - Node layout: - Like Separate/Combine XYZ - Naming and Scope: - Components: Radius/Zenith/Azimuth -> R/Theta/Phi - Maybe this could also be solved with more generic `Combine/Separate Vector` nodes that can have different 3D coordinate modes. E.g. Cartesian (X/Y/Z) (->default), Spherical (R/Phi/Theta), Cylindrical (Rho,Phi,Z) - Units: Radians, shown as deg for the UI (same as e.g. Vector Rotate) - Value Ranges: Phi [-pi, pi], Theta [-pi/2, pi/2] Math: x = R*cos(Phi)*cos(Theta) y = R*sin(Phi)*cos(Theta) z = R*sin(Theta) - > Behavior like in this file: [separate_combine_vector.blend](https://archive.blender.org/developer/F12793103/separate_combine_vector.blend) ![image.png](https://archive.blender.org/developer/F12793099/image.png)

Paul Larson commented

2022-01-07 19:32:54 +01:00

Added subscriber: @GeorgiaPacific

Charlie Jolly commented

2022-01-08 05:09:16 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2022-01-08 05:09:16 +01:00

WIP patch here: D13772: (WIP) Node: Add Vector Convert node

WIP patch here: [D13772: (WIP) Node: Add Vector Convert node](https://archive.blender.org/developer/D13772)

Trung Phạm commented

2022-01-08 08:45:42 +01:00

Added subscriber: @zNight

Paul Szajner commented

2022-01-08 16:05:27 +01:00

Added subscriber: @sozap

Hans Goudey commented

2022-01-31 19:37:04 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-01-31 19:37:04 +01:00

Testing D12746, I started to think that this is really the more important node to include short term.

Node Layout

The three inputs and an enum for the conversion make sense to me.

Node Name
Calling the node "Combine Vector" sounds too general in my opinion. Combining the "Combine XYZ" functionality with something like converting to spherical coordinates doesn't seem ideal, since one is very simple, and one is a much more complicated operation.
The name then wouldn't tell you much about what the node does.

I would suggest a name like "Convert Vector" or "Spherical Coordinates". The former is nice because it fits with cylindrical coordinates and it's phrased like an action.

Socket Names
For naming, I also think there's no need to use math variable names like Phi and Theta, we should just use the proper terms directly-- "Radius", "Zenith", and "Azimuth".

Units/Ranges

Everything Simon proposes here makes sense to me too.

Testing [D12746](https://archive.blender.org/developer/D12746), I started to think that this is really the more important node to include short term. **Node Layout** The three inputs and an enum for the conversion make sense to me. **Node Name** Calling the node "Combine Vector" sounds too general in my opinion. Combining the "Combine XYZ" functionality with something like converting to spherical coordinates doesn't seem ideal, since one is *very* simple, and one is a much more complicated operation. The name then wouldn't tell you much about what the node does. I would suggest a name like "Convert Vector" or "Spherical Coordinates". The former is nice because it fits with cylindrical coordinates and it's phrased like an action. **Socket Names** For naming, I also think there's no need to use math variable names like Phi and Theta, we should just use the proper terms directly-- "Radius", "Zenith", and "Azimuth". **Units/Ranges** Everything Simon proposes here makes sense to me too.

Simon Thommes commented

2022-02-01 11:30:32 +01:00

Hm. This might be personal bias due to my physics background, but to me combining a vector socket from 3 components is fundamentally the same operation regardless of the used coordinate system.
Sure, in the code the cartesian system is used for everything, but I personally would prefer if a more agnostic approach.

This ties into the fact that conceptually there is no such thing as a cartesian vector or a spherical vector. A 3D vector can just be represented in different coordinate systems. So coming from that, to me it makes most sense to have general combine/separate vector nodes where the system can be chosen. Rather than having multiple nodes that have fundamentally the same purpose with very different names.

Hm. This might be personal bias due to my physics background, but to me combining a vector socket from 3 components is fundamentally the same operation regardless of the used coordinate system. Sure, in the code the cartesian system is used for everything, but I personally would prefer if a more agnostic approach. This ties into the fact that conceptually there is no such thing as a cartesian vector or a spherical vector. A 3D vector can just be represented in different coordinate systems. So coming from that, to me it makes most sense to have general combine/separate vector nodes where the system can be chosen. Rather than having multiple nodes that have fundamentally the same purpose with very different names.

Charlie Jolly commented

2022-02-01 15:19:23 +01:00

I've been looking at Sverchok recently and they use Compose/Decompose for this. For coordinate system, this could also be other data types like color e.g. HSL
So question is if the node should be generalized into a compose/decompose vector type node with different modes or if we have pairs of nodes for each conversion?

Edit:
@HooglyBoogly @SimonThommes
Due to discussion in D14034: Geometry/Compositor/Shader/Texture Nodes: Add general Combine/Separate Color nodes, shall I change D13772: (WIP) Node: Add Vector Convert node so that it just expands functionality of existing separate/combine xyz by adding modes and call it separate/combine vector? Or is this one of those nodes that should be shipped as an asset bundle?

I've been looking at Sverchok recently and they use Compose/Decompose for this. For coordinate system, this could also be other data types like color e.g. HSL So question is if the node should be generalized into a compose/decompose vector type node with different modes or if we have pairs of nodes for each conversion? Edit: @HooglyBoogly @SimonThommes Due to discussion in [D14034: Geometry/Compositor/Shader/Texture Nodes: Add general Combine/Separate Color nodes](https://archive.blender.org/developer/D14034), shall I change [D13772: (WIP) Node: Add Vector Convert node](https://archive.blender.org/developer/D13772) so that it just expands functionality of existing separate/combine xyz by adding modes and call it separate/combine vector? Or is this one of those nodes that should be shipped as an asset bundle?

Hans Goudey commented

2022-02-10 01:12:49 +01:00

but to me combining a vector socket from 3 components is fundamentally the same operation regardless of the used coordinate system.

This is getting a bit theoretical, but I don't think this is the way typical users will think about these operations. Spherical coordinates are much more complicated, they're the "other", the "non-standard", and I think it would be expected that this is reflected in the UI.

This ties into the fact that conceptually there is no such thing as a cartesian vector or a spherical vector.

This might be technically true, but at every point in a node tree, doesn't a certain vector have a semantic meaning as well? That would include its coordinate system. Node link data is useless without that semantic meaning, so I'd personally consider it "part of the data", at least that's how it ends up working practically.

I like the names "Compose/Decompose" that @CharlieJolly mentioned above. "Decompose Vector" and "Compose Vector" sound reasonable. But if we end up calling this "Combine Vector", well it's certainly not the end of the world :)

So question is if the node should be generalized into a compose/decompose vector type node with different modes or if we have pairs of nodes for each conversion?

Personally I think that would be taking the generic typed node idea too far, beyond what's actually useful conceptually. Combining colors and vectors are quite different.
If we end up adding a 2D vector socket, I think that could still be included in this node, but IMO a color node should still be separate.

>but to me combining a vector socket from 3 components is fundamentally the same operation regardless of the used coordinate system. This is getting a bit theoretical, but I don't think this is the way typical users will think about these operations. Spherical coordinates are much more complicated, they're the "other", the "non-standard", and I think it would be expected that this is reflected in the UI. >This ties into the fact that conceptually there is no such thing as a cartesian vector or a spherical vector. This might be technically true, but at every point in a node tree, doesn't a certain vector have a semantic meaning as well? That would include its coordinate system. Node link data is useless without that semantic meaning, so I'd personally consider it "part of the data", at least that's how it ends up working practically. I like the names "Compose/Decompose" that @CharlieJolly mentioned above. "Decompose Vector" and "Compose Vector" sound reasonable. But if we end up calling this "Combine Vector", well it's certainly not the end of the world :) --- > So question is if the node should be generalized into a compose/decompose vector type node with different modes or if we have pairs of nodes for each conversion? Personally I think that would be taking the generic typed node idea too far, beyond what's actually useful conceptually. Combining colors and vectors are quite different. If we end up adding a 2D vector socket, I think that could still be included in this node, but IMO a color node should still be separate.

Simon Thommes commented

2022-02-10 12:32:10 +01:00

@HooglyBoogly I'm getting a bit lost in what you are proposing. It seems to me that while we are disagreeing on the reasoning an a fundamental level, we are combing to the same conclusions on what this node should look like. That makes it a bit confusing to me.

Maybe we can just clear up the confusion in a meeting and get back to this thread. I'll put the topic on the agenda.

@HooglyBoogly I'm getting a bit lost in what you are proposing. It seems to me that while we are disagreeing on the reasoning an a fundamental level, we are combing to the same conclusions on what this node should look like. That makes it a bit confusing to me. Maybe we can just clear up the confusion in a meeting and get back to this thread. I'll put the topic on the agenda.

Hans Goudey commented

2022-02-10 17:30:03 +01:00

Copying from the meeting nodes here:

We had a long discussion (with some misunderstandings) about how vectors should still be stored in cartesian coordinates, and vectors shouldn't become a "bag of floats"

Color and vector should be separate nodes

Rename "Combine/Separate XYZ" to "Combine/Separate Vector"

Add "Cartesian", "Spherical", and "Cylindrical" options to both nodes

Socket Names: "Radius", "Azimuth", "Zenith"

Zenith has a soft range from -π/2 to 0 (at the horizon) to π/2.

Azimuth has no soft range (but for the output is wrapped from -π to π)

Radius has a soft limit of zero, but negative radii are flipped.'

Don't change the node ID names, since they're still basically correct and are probably used in a lot of scripts.

Copying from the meeting nodes here: >* We had a long discussion (with some misunderstandings) about how vectors should still be stored in cartesian coordinates, and vectors shouldn't become a "bag of floats" >* Color and vector should be separate nodes >* Rename "Combine/Separate XYZ" to "Combine/Separate Vector" >* Add "Cartesian", "Spherical", and "Cylindrical" options to both nodes >* Socket Names: "Radius", "Azimuth", "Zenith" >* Zenith has a soft range from -π/2 to 0 (at the horizon) to π/2. >* Azimuth has no soft range (but for the output is wrapped from -π to π) >* Radius has a soft limit of zero, but negative radii are flipped.' >* Don't change the node ID names, since they're still basically correct and are probably used in a lot of scripts.

Johnny Matthews self-assigned this 2022-08-09 21:51:01 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Nodes to convert between cartesian/spherical coordinates #94722