Geometry Nodes: remove experimental option for matrix socket and nodes #120539

Jacques Lucke · 2024-04-11T18:50:04+02:00

Jacques Lucke commented

2024-04-11 18:50:04 +02:00

This makes the matrix socket and initial set of corresponding nodes non-experimental. That means, they'll be part of the next release.

Todo:

Make the conversion from matrix to rotation not hit an assert in a setup like this:
- Implicit conversion
- Separate Transform node
Try to merge #120572 before to avoid search regressions.

This makes the matrix socket and initial set of corresponding nodes non-experimental. That means, they'll be part of the next release. ![image](/attachments/a574ae84-64dc-4da3-8563-fa68c789fa9b) Todo: * Make the conversion from matrix to rotation not hit an assert in a setup like this: ![image](/attachments/3ce07152-2919-498c-ae2e-c109e2ac54ae) * [x] Implicit conversion * [x] `Separate Transform` node * [x] Try to merge #120572 before to avoid search regressions.

image.png

34 KiB

image.png

47 KiB

👍 2 🎉 3

Jacques Lucke added 1 commit 2024-04-11 18:50:14 +02:00

d057766fca remove experimental option

Jacques Lucke requested review from Simon Thommes 2024-04-11 19:02:01 +02:00

Jacques Lucke requested review from Hans Goudey 2024-04-11 19:02:02 +02:00

Hans Goudey reviewed 2024-04-12 23:11:41 +02:00

source/blender/nodes/function/nodes/node_fn_combine_transform.cc Outdated

						
				@ -20,13 +20,6 @@ static void node_declare(NodeDeclarationBuilder &b)

				  b.add_output<decl::Matrix>("Transform");

				}

				static void search_link_ops(GatherLinkSearchOpParams &params)

Hans Goudey commented

2024-04-12 23:11:37 +02:00

Could you also remove the NOD_socket_search_link.hh include for cases like this?

Could you also remove the `NOD_socket_search_link.hh` include for cases like this?

JacquesLucke marked this conversation as resolved

Jacques Lucke added 2 commits 2024-04-14 12:57:30 +02:00

06212d491f Merge branch 'main' into matrix-experimental-remove

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

23ec41e123 remove unnecessary includes

Jacques Lucke commented

2024-04-14 13:00:42 +02:00

@blender-bot build

Jacques Lucke added 1 commit 2024-04-16 13:09:53 +02:00

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

f50c4d97a8 Merge branch 'main' into matrix-experimental-remove

Jacques Lucke changed title from ~~WIP: Geometry Nodes: remove experimental option for matrix socket and nodes~~ to Geometry Nodes: remove experimental option for matrix socket and nodes

2024-04-16 13:11:56 +02:00

Jacques Lucke commented

2024-04-16 13:15:47 +02:00

@blender-bot build

Hans Goudey approved these changes 2024-04-16 13:39:22 +02:00

Simon Thommes approved these changes 2024-04-16 14:17:28 +02:00

Simon Thommes left a comment

I think this is good to go!

I have a few comments, none of which are really in the way of merging this. Just want to have these topics mentioned and get an idea what the current plan is regarding them:

There is currently quite some inconsistency when a transform socket is used in favour of separate rotation, translation and scale. Imo the way it is done currently (only really use the new socket on new nodes/nodes with an explicit type switch) is good to make the introduction seamless, but I'm wondering if there is a plan to make things more consistent in the future.
There are for example Object Info and Transform Geometry, where the individual transform components could be combined into one socket and there are the instance transform nodes that could even be combined into a single node.
Imo we should keep it as is and change this once there is an implementation for a expandable transform socket that the user can easily expose in the UI. Im just wondering if that is already the plan or not.

I think it totally makes sense to limit the application and current toolset for matrices to spatial transformation, since that is the most prominent use for geometry operations, but eventually we'd want to be able to use them more generically. That starts with being able to creates a general matrix with certain values from scratch and accessing the values of a matrix at a certain index. Right now I don't see any actual way of doing this, not even as a kind of workaround.
Imo this is fine, but I'm wondering what the next steps would be. Would this rely on an implementation of dealing with generic arrays or is there the plan to support something in the nearer future?

I think this is good to go! I have a few comments, none of which are really in the way of merging this. Just want to have these topics mentioned and get an idea what the current plan is regarding them: There is currently quite some inconsistency when a transform socket is used in favour of separate rotation, translation and scale. Imo the way it is done currently (only really use the new socket on new nodes/nodes with an explicit type switch) is good to make the introduction seamless, but I'm wondering if there is a plan to make things more consistent in the future. There are for example Object Info and Transform Geometry, where the individual transform components could be combined into one socket and there are the instance transform nodes that could even be combined into a single node. Imo we should keep it as is and change this once there is an implementation for a expandable transform socket that the user can easily expose in the UI. Im just wondering if that is already the plan or not. I think it totally makes sense to limit the application and current toolset for matrices to spatial transformation, since that is the most prominent use for geometry operations, but eventually we'd want to be able to use them more generically. That starts with being able to creates a general matrix with certain values from scratch and accessing the values of a matrix at a certain index. Right now I don't see any actual way of doing this, not even as a kind of workaround. Imo this is fine, but I'm wondering what the next steps would be. Would this rely on an implementation of dealing with generic arrays or is there the plan to support something in the nearer future?

Hans Goudey commented

2024-04-16 14:38:10 +02:00

Thanks for writing those thoughts!

Imo we should keep it as is and change this once there is an implementation for a expandable transform socket that the user can easily expose in the UI

Yeah, that's basically the plan. Not sure when we'll work on the expandable socket idea. But it seems good enough for now anyway.

That starts with being able to creates a general matrix with certain values from scratch and accessing the values of a matrix at a certain index

I think these would just be a few more nodes with float/vector/matrix inputs and outputs.

Thanks for writing those thoughts! >Imo we should keep it as is and change this once there is an implementation for a expandable transform socket that the user can easily expose in the UI Yeah, that's basically the plan. Not sure when we'll work on the expandable socket idea. But it seems good enough for now anyway. >That starts with being able to creates a general matrix with certain values from scratch and accessing the values of a matrix at a certain index I think these would just be a few more nodes with float/vector/matrix inputs and outputs.

Simon Thommes commented

2024-04-16 16:40:10 +02:00

@HooglyBoogly okay, sounds good 👍

I think these would just be a few more nodes with float/vector/matrix inputs and outputs.

Then imo this shouldn't drag behind for too long if possible, since this would bring a lot of generic functionality, there isn't currently a workaround for it and there is no real reason to delay this a lot if it doesn't rely on another topic.
Would be nice to at least have a design task already, could you create that?

@HooglyBoogly okay, sounds good 👍 > I think these would just be a few more nodes with float/vector/matrix inputs and outputs. Then imo this shouldn't drag behind for too long if possible, since this would bring a lot of generic functionality, there isn't currently a workaround for it and there is no real reason to delay this a lot if it doesn't rely on another topic. Would be nice to at least have a design task already, could you create that?

Jacques Lucke referenced this issue from a commit

2024-04-17 10:34:28 +02:00

Geometry Nodes: remove experimental option for matrix socket and nodes

Jacques Lucke merged commit c00c1b8e23 into main

2024-04-17 10:34:28 +02:00

Jacques Lucke deleted branch matrix-experimental-remove

2024-04-17 10:34:31 +02:00

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry Nodes: remove experimental option for matrix socket and nodes #120539