Decide how rotation socket type should be stored #92766

New Issue

Hans Goudey · 2021-11-03T00:03:09+01:00

Hans Goudey commented

2021-11-03 00:03:09 +01:00

A rotation socket type could be exposed to the used with an Euler rotation when exposed to nodes whether or not they are actually stored as Euler rotations. That begs the question, how should rotation attributes / intermediate results be stored?

Quaternions
- Benefits: More foolproof rotations, ...
- Downsides: More storage space, ...
Euler:
- Benefits: Aligns to what users are used to better
- Downsides: Gimbal lock, etc.

A rotation socket type could be exposed to the used with an Euler rotation when exposed to nodes whether or not they are actually stored as Euler rotations. That begs the question, how should rotation attributes / intermediate results be stored? - Quaternions - Benefits: More foolproof rotations, ... - Downsides: More storage space, ... - Euler: - Benefits: Aligns to what users are used to better - Downsides: Gimbal lock, etc.

Hans Goudey commented

2021-11-03 00:03:09 +01:00

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

Hans Goudey commented

2021-11-03 00:03:09 +01:00

Added subscriber: @HooglyBoogly

Paul Larson commented

2021-11-03 01:38:22 +01:00

Added subscriber: @GeorgiaPacific

Jarrett Johnson commented

2021-11-03 02:46:07 +01:00

Added subscriber: @Jarrett-Johnson

Jarrett Johnson commented

2021-11-03 02:46:07 +01:00

I figured that the user would still be interfacing with euler but the internal representation of the rotations would be quaternion (impl detail hidden from user).

Daniel Salazar commented

2021-11-04 22:35:45 +01:00

Added subscriber: @zanqdo

Jacob Merrill commented

2021-11-05 03:07:41 +01:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2021-11-05 03:07:41 +01:00

I would also allow matrix input into graphs from object info node,
edit nodes - object info - output - matrix

new node - from local to world space
input1 - pointer to bpy object
input2 - Vector3
output = object.matrix_world @ input2

new node world space to local space
input1 - pointer to bpy object
input2 - Vector3
output = object.matrix_world.inverted() @ input2

new node - transform - rotate - scale - offset - matrix - wraps mathtutils matrix class

this is the meat and potatoes of procedural generation

to get a objects X axis, we can use ob.matrix_world.col- [x] #x axis

'Decompose matrix to rot, scale, and pos, and X axis, Y and Z vectors'

we can rotate a matrix , then align to it, it's VERY handy.
@Ton

I would also allow matrix input into graphs from object info node, edit nodes - object info - output - matrix ![image.png](https://archive.blender.org/developer/F11722816/image.png) new node - **from local to world space** input1 - pointer to bpy object input2 - Vector3 output = object.matrix_world @ input2 ![image.png](https://archive.blender.org/developer/F11722907/image.png) new node **world space to local space** input1 - pointer to bpy object input2 - Vector3 output = object.matrix_world.inverted() @ input2 new node - transform - rotate - scale - offset - matrix - wraps mathtutils matrix class this is the meat and potatoes of procedural generation to get a objects X axis, we can use ob.matrix_world.col- [x] #x axis 'Decompose matrix to rot, scale, and pos, and X axis, Y and Z vectors' we can rotate a matrix , then align to it, it's VERY handy. @Ton

Jacob Merrill commented

2021-11-05 03:12:01 +01:00

Added subscriber: @Ton

Hans Goudey commented

2021-11-05 05:09:52 +01:00

Removed subscriber: @Ton

Hans Goudey commented

2021-11-09 18:22:44 +01:00

Currently we've settled on quaternions as the internal way to store rotations, unless some other reasoning we haven't though of comes up.
They're relatively small compared to 3x3 rotation matrices, and don't suffer from gimbal like Euler rotations.

Currently we've settled on quaternions as the internal way to store rotations, unless some other reasoning we haven't though of comes up. They're relatively small compared to 3x3 rotation matrices, and don't suffer from gimbal like Euler rotations.

Hans Goudey commented

2021-11-09 18:24:55 +01:00

@JacobMerrill-1 Working on storing rotations doesn't mean we can't add support for transform matrices later. In fact, even if matrices were the main way of passing around rotations, we would still want to store rotations as a way to build transform matrices from more user friendly components.

The discussion about world space transforms, etc. is unrelated. Geometry nodes works in the object's local space by design.

@JacobMerrill-1 Working on storing rotations doesn't mean we can't add support for transform matrices later. In fact, even if matrices were the main way of passing around rotations, we would still want to store rotations as a way to build transform matrices from more user friendly components. The discussion about world space transforms, etc. is unrelated. Geometry nodes works in the object's local space by design.

Jacob Merrill commented

2021-11-09 18:44:33 +01:00

we can convert points relative to a object and then pass them into a texture for instance,
(similar to texture cord node in eevee shaders / cycles)*

we can apply forces in local space, acceleration etc using matrices

we can create our own parent like relationships using

local = object1.worldTransform.inverted() @ object2.location
rot_diff = object1.rotation_matrx.inverted @ object2.orientation_matrix

1 time, then each frame after

object.location = someOtherObject.matrix_world @ local
object.rotation = someOtherObject.rotation_matrix @ rot_diff

it's very powerful math that can do all sorts of stuff, that you intend and otherwise.

currently it's not easy to access a objects Axis Vector either*
angle = someObject.rotation_matrix.col- [x] #objects X axis
angle = someObject.rotation_matrix.col- [x] #objects Y axis
angle = someObject.rotation_matrix.col- [x] #objects Z axis

we can convert points relative to a object and then pass them into a texture for instance, (similar to texture cord node in eevee shaders / cycles)* we can apply forces in local space, acceleration etc using matrices we can create our own parent like relationships using local = object1.worldTransform.inverted() @ object2.location rot_diff = object1.rotation_matrx.inverted @ object2.orientation_matrix 1 time, then each frame after object.location = someOtherObject.matrix_world @ local object.rotation = someOtherObject.rotation_matrix @ rot_diff it's very powerful math that can do all sorts of stuff, that you intend and otherwise. currently it's not easy to access a objects Axis Vector either* angle = someObject.rotation_matrix.col- [x] #objects X axis angle = someObject.rotation_matrix.col- [x] #objects Y axis angle = someObject.rotation_matrix.col- [x] #objects Z axis

Vladislav Macíček commented

2021-11-20 01:13:17 +01:00

Added subscriber: @Aeraglyx