Hey I did some mockups / have a few calls into question
about the workflow design,
when i see the @dfelinto designs the workflow is working with mainly geo data that is passed around. and attr data only available as inputs
if we want a flexible workflow, shouldn’t we be able to separate attr from geo and do attr manipulation from the attr types?
Aren’t attributes mostly just floats or vectors ? (even point positions and normals ?)
@HooglyBoogly even if the math nodes are within a special for_each attribute values box?
so from the user perspective, it would be visually the same experience, even if the code of the nodes need to change once inside the box.
I believe it’s quite important/basic to introduce loops to users if we are working with arrays of values
*assuming the workflow would let the possibility of separating attr from geo ofc
@SteffenD well, yes, you get the same performance problem, but the thing is that as a user I don’t know if the culptrip is the viewport or the new geometry nodes, but there is a big performance problem here, and keep in mind that this is a new system being developed for more than a year from the ground up.
The same happens if you enter in edit mode in a mesh with 1 million vertices, and we cannot speak about a 10 million vertices mesh, you will suffer A LOT, and that must have a relation with Geometry Nodes, so I doubt it’s a viewport related problem.
THB I think the pebbles example it’s a bit cheat-loner, it’s a super small plane, who could want to scatter pebbles in such a small area?
The pebbles example should have been a big area, like 100m x 100m, and there you can see if the scatter solution works or not, without that kind of test it’s like a proof-of-concept, but not a properly designed, production ready tool IMHO.
IMHO the sprint scenes should aim to a higher standard, not to a comfortable one, I mean, the target may not change, but you won’t see the same doing a 2x2 plane scatter than a 100x100 plane scatter, the sprint target is the same, and the scene is “the same”, but you will be much more near a production situation than a paper/developer-art situation.
I’m not saying that the nodes are purely responsible, but the resulting performance is bad, as a user you don’t care if the performance problem comes from the nodes theme selves or if it comes from the underlying operations.
In your test you just did an action that gives awful performance too, but that does not mean that the same underlying operation is happening behind the scenes, or maybe it is.
Take as an example the subdivision surface node, it’s the same as the modifier, but it’s not the same, there is a new node that had to be implemented, I don’t know whats happening behind the scene of the instancer node, but what I know is that the resulting performance is bad, and if the Geometry Nodes system and effort has to show it’s power, it needs to have performance, maybe some performance problem have to be fixed before the nodes project can go ahead or something like that.
The only thing I can see right now is that in a production situation of instancing a million pebbles, as I said nothing too fancy, performance is awful, not sure there is the bottle neck, but it’s a bottle neck that should be fixed before this can be considered production ready, specially when we are talking that the first/main target of the sprint was scattering, right now it’s not a good solution for scattering I’m afraid, the reason on why is that happening is something that developers, doing a proper performance investigation can discover, but just adding nodes that do things is not going to be useful, we need to have those nodes AND performance.
I insisted in the performance part since the beginning of the particle nodes / everything nodes project, it’s key, without performance this will be useless in production.
The initial goal of the geometry nodes project is to be used in production (Sprites Fright). If performance becomes a showstopper we will find a way of prioritizing it.
I’m glad to hear that, I hope the sprints can also take bigger scenes for their development and testing, that will help to ensure, at least, a part of the performance
I’m not sure I can give the best answer to this question-- there was a fair amount of design discussion before I was involved in the project. But it’s a good question so I’ll try.
Honestly, I think splitting attributes from their geometries will cause more problems than it fixes, then you have to also keep a mental model about which geometry the attribute is from, then you’re keeping track of two things when you could just keep track of one thing. For example, in the screenshot you’ve provided, where there was once a fairly simple progression of nodes, now there is an extra node, and two paths you have to follow to understand the node tree.
This doesn’t mean there can’t be powerful ways to transfer attributes from one geometry to another. Using nodes and a more generic attribute system will give us an opportunity to rethink the functionality of the data transfer modifier, which will hopefully be a nice improvement. It might be a bit before the team gets to work on that sort of thing though, we’ll see.
I think eventually we might want such a system, especially for more complex deformation in nodes. But we’ve decided that working on the attribute level where every node modifies the geometry in some complete way makes more sense for the basic design of the system. One reason is that Blender already works this way-- a node is sort of analogous to a change you make to an object in edit mode or with an operator. My hunch is that will be useful in the future. Another reason is that in a data-flow system like we have, having such a “box” would introduce a separate paradigm, making the system harder to learn.
I don’t understand the need of a separate attribute editor. The attribute, normally, will be a extra info for point/vertex/face/object like for example:
That you can edit like position, normal, group,… and it’s not needed to be separate of the geometry. Maybe the problem is to think in a “geometry” data instead of a simple flow data that contain different type of “primitives” like point/vertex/face each one with some type of integer/float/vector data attached to each value
Thanks for taking the time to talk about this design decision
I completely understand this decision, but then, why is there attr nodal inputs?
Not sure, but it seems that this is a workflow incoherence then? maybe there’s a plan to support both data-flow later in time?
Seeing attr types input directly inside the node editor implies to user that it’s possible to manipulate attr directly, operations such add and extract attr from their geo as i illustrated above. personally i wanted to do that instinctively, just because i saw these inputs.
Maybe it’s best to hide attr from user (just like the image above), until a functional attr data-flow is implemented?
As i strongly believe showing the attr inputs may misleads users into wanting to separate attr from their geos
Maybe to be able to expose the attribute name to the modifier ui? Just guessing though.
Indeed, but they could hide the inputs, that’s not a problem.
I wonder what would be the usage of these inputs, if the data-flow wasn’t meant to use them
Does Geometry Nodes plan to design a Scripts node?To run the script directly on the node module, whose properties can interact with the slider on the node.Use scripts to create points, edges, and faces, and control the position, size, rotation, and scaling of points, edges, and faces.Nodes can pass and compute data from one node to another, which is what I want most.
The only problem I see with such a node is that it may break performance, because it won’t be the same to use Python than the native nodes based on the new evaluation system developed by @jacqueslucke AFAIK
Yep, that’s why it’s my only concern.
In the end AFAIK the idea behind all this is that you will be able to do “the same” with nodes, and encapsulate it inside a high level node so it maintains the benefit of nearly native c++ performance (AFAIK) and not have the Python penalty
Personally, I’d like to work on a script node eventually, we have not talked about it in our meetings yet though. A script node is more of a long term goal, because it might not be necessary for any specific use cases we are working towards in the near future. It will have to be implemented in a way that does not hurt performance too much of course.
As for the language, there are multiple options: use Python, or another already existing language or develop our own domain-specific-language. All of these have pros and cons. Maybe picking more than one of these options is also possible.
Tl;dr: A script node would be nice to have, I would like to work on it, but it is not on our roadmap yet and might not be for while.
Might be silly, but seeing nodes being neatly color-coded now gives a nice feel, like it’s taking shape (https://developer.blender.org/D9682). There’s also talk of point groups (for specifying a set of elements to operate on), which are essentially just… a boolean attribute. I suppose we’re going to need that concept for pretty much any modeling operation : extrude ? surely you want to have a say in which face to extrude. Bevel ? gimme some edges, human.
