As a utter and complete layman, I wonder how that sort of thing isn’t handled at the library level that Blender uses (TBB, if my memory serves correct). But I probably wouldn’t understand the answer, so carry on
(and yes! such a good improvement)
1 horse pulling a cart, cart moves at 1 MPH.
2 horses pulling a cart, cart moves at 2 MPH.
1000 horses - cart likely not moving in a way one would want.
1 Like
Is there any reason why tools should be visible in search when the node editor is in modifier mode? They can’t be used as normal nodes, like the error message says. They just kinda clutter up the search…
4 Likes
Is there support for using udims in geometry nodes for 4.2 or 4.1 latest release?
I’m hoping the new way to transform instances will work the same way doing rotations work now (it looks a lot more complex on the outside, but everything just converts behind the scenes), matrices are no joke for the vast majority of people (which is what a transform is).
#120344 - Geometry Nodes: Make as deprecated old nodes to access instance transform - blender - Blender Projects
In addition to this from the same developer is patches that start to insert the transform socket in more places.
1 Like
If I’ll ever have to think about matrices when I’m doing art I’m out of Geometry Nodes and wish the rest of you good luck. It’s one thing for it to exist as low level thing, but to need to deal with matrices when you want to scale an instance is kind of an impressively bad idea.
4 Likes
I do hope that this helps with doing various tasks like randomly rotating instances because, right now I have found that more challenging than most anything else that I’d consider “general everyday thing” in nodes.
Every time I set something new up, I have to open up an old file and stare at it for about 10 minutes and remember how it works.
The new rotation socket stills allows you to think in Eulers as opposed to a 4-axis quaternion, so I would guess the Transform socket would work the same way.
Though the patch does deprecate a node which saw the introduction of a rotation socket just a release or two ago, I truly hope that Geo Nodes will not fall victim to a pattern of constantly breaking both established knowledge and working scenes in the name of ‘design’ (thereby proving why a lot of people would rather use Maya and Max if not for their unfriendly and expensive licensing system). I know the BF loves to think about design, but it needs to be noted that without users there would not be a Blender to design in the first place.
1 Like
The socket’s name is transform, not matrix. Even when you used “Rotate Instances”, it involved matrices and yet, most likely no one thinks about it like that.
2 Likes
Yeah, I’m not sure why these input nodes are deprecated at all, they seem like a good way to access individual transform components without having to decompose the matrix first. @HooglyBoogly can I ask if you discussed that?
3 Likes
I know what they are. And transforms are matrices. That means if I want to adjust one component of transform I have to use Separate Transform. Every single time when I want to adjust anything about instances I have to use that. It’s atrociously bad design. This is sub-atomic level. At one point making node tree into math exercise needs to stop.
Feel free to point me to sources indicating that there won’t be simple ways to rotate/translate/scale?
Or feel free to point me to evidence that this is going to be merged in the first place?
Is this community now going to micromanage individual pull requests?
I said “If”. I’m not expecting it to get merged. Iliya’s ideas are too far-fetched too often. He likes math. Luckily there are other developers who realize users don’t.
1 Like
Well first of this patch is a proposal and we will know if it’s thought as a good idea or not …
Personally I’ve got mixed feelings, as in one way it’s nice to remove redundant nodes, even if it adds the complexity of splitting transforms. But that doesn’t look like a big deal in the end.
As for the evolving design, at least having legacy/deprecated nodes might be a way to do a soft transition…
I think also working with transforms/matrix in geonode looks relatively intuitive and at least we have instant feedback. When working with them in python I always mix-up the order of operations, or tend to struggle a lot, but here I got the feeling that it’s going to be much easier.
In the meantime, currently it’s pretty tricky to do advanced transforms operations, as many time it’s far from intuitive to cancel transforms, to do the operations and set it back after the fact.
Basically what I did there : Growing flowers with geometry nodes
Which probably looks quite complex for a newcomer can probably be made much simpler using transforms.
1 Like
Speaking of ease-of-use it would be nice if we saw the return of the old ‘transfer attribute’ node and have normal data be a built-in attribute again (because as far as I know there isn’t anything in the code that limits how many types of nodes there can be). I know you can still create ‘custom normals’ for use in shaders but it does not show up in Workbench. Perhaps some obscure modifier does this?
Though if the team really began to work on node group assets and had transfer attribute (or some other equivalent of the data transfer modifier) there instead that would be fine as well. We were also supposed to get assets for particle simulation with nodes but so far nothing has shown up.
You have this odd habit of asking people if we can predict the future, and prove a negative.
1 Like
I guess Transfer Attribute node can be remade as asset when built-in enum menus can be exposed with sockets so you can change data type and geometry type from outside node group.
That’s kind of the issue that developers make changes with future workflows in mind, which are adequate, but then those workflows take years to arrive, and we’re left with bad UX for a long time.
Like they refused Easing node, but node groups didn’t have enums back then. Now they do, but they can’t have icons. At one point they might, but if that’s the case just wait until they do before you add/remove something.
1 Like
This is first and foremost a rhetorical question.
And proofing a negative in this case works, because the meaning is that there are no plans to to that. And in order to proof it, one might point to a developer discussion where it is mentioned that no further nodes are needed.
Edit: And in regard of predicting the future, apparently people are predicting the worst and feel the need to ask developers. It is just a pull request and we have essentially no context…
1 Like
Case in point
Curve-to-Mesh Node “Even Thickness” Feedback Thread - Feature & Design Feedback - Developer Forum (blender.org)
A patch for a solution that otherwise requires quite a bit of math to do, but it was turned down because of supposed plans to support this amid a larger design change.
The catch, this is supposed to happen at some unspecified point in the future, and based on analogs with other BF projects that time might be 5 years or more yet. Unless the change is so intrusive that it makes future refactoring a lot more difficult, then I do not see why users have to be left hanging out to dry and use a far more difficult method instead. I know you can just make a node group, but we do not have a comprehensive cookbook that give these away at the moment.
I thought one of the whole points of fields was to make Geo Nodes more approachable and friendly to artists (since it now a lot more like Cycles and the compositor), turning down patches like that with no alternative plan in place does not help that. Perhaps an official cookbook where you just download what you need into your asset folder will help if it means we can have things like this without introducing too much of a blackbox problem.
3 Likes