Geometry Nodes

Very early attempt for non-destructive cell fracturing. It’s not the best way possible and really sluggish for real time editing right now

Each Transform node:

  • creates a copy of original Cube
  • scales it down to almost plane
  • rotates “plane”

Each Boolean node, takes “plane” and does Difference operation(cut) on previous result.

5 Likes

Some remarks, copied from ba.org :

Duplicating the group input node (the one built into the modifier node tree, not a user-created group) seems to invalidate the entire tree : my output mesh looks unmodified.

So from first impressions I’m very much missing a simple triplet of float sockets where the vector sockets are. Maybe give both : vector socket aside to the property name (“rotation”, etc), and individual float sockets for each property (x, y, z…). Right now I have to “combine-XYZ” every value I want to input into the transform node’s sockets which seems unnecessary.
Of course I would also want to preview the node tree at any point, ie there needs to be an active preview node specified with a little icon on its header… or something in that vein.

The next thing is… value fields in the node editor could use expressions. It would be a shortcut for what is currently a string of math nodes (most operations take only one, but some take three, and in any case that’s a lot of extraneous nodes in the end). The expression would be embedded in the value field, and able to access only variables in the nodetree (not anything throughout the Blender scene, that’s a job for drivers) and manipulate them just a bit without having to insert a math node in between, which I think is cool because it would show also the actual number in the case of constants (just like in William’s proposal). Of course the relationship would still be shown by a regular noodle between the two (or more) sockets. I guess the value field should be colored or something, so as to make it obvious there’s an operation happening there…

A simple switch node would also be neat !

An overlay to show the output of the active node… in wireframe, unobstrusive, overlaid onto the solid “mesh output”… that’s sparkles I know !

1 Like

I tried to do a basic scattering test but it didn’t work at all. As soon as I add Point Distribute node, the mesh disappears and I get no output. Is this a bug or am I missing something?

you need to do that with a point cloud object

I have a proposal of adding custom properties to a node tree.
The problem is that sometimes trees are growing very big and some properties can be used several times in opposite parts of the tree so you have to add separate value nodes and spread connections from them to all over the tree what is not very convenient.

The proposal is to add node tree properties so any node property could subscribe to their changes and use their values via drivers. This will help to keep tree more clean. Another advantage is that custom properties has more control. It is possible to determine limits and type of the value add its description what value node can’t do.

4 Likes

Without loops or geometry arrays right now, I couldn’t make it so that the number of shelves is dynamic, only their position relative to the bookshelf height. Maybe I’ve missed a possible way to do it ? In effect it is a bit less programmatic than I hoped, but this is still very early : there are almost no modeling operators and those would be my choice for that kind of job, along with a more flexible way to copy things, and the ability to add primitives in the node tree.

What makes it tedious also is we can’t choose the origin of transformation for the transform node. So we have to manually compensate scaling, which always happens relative to the object origin. Ideally there would be a “transformation origin” triplet, or separate “scale origin” and “rotate origin” and a “transformation order” dropdown so that we don’t have to chain several transform nodes.

Right now the geometry is a bit glitchy because the boolean node is used in place of a “merge” node, which in theory would not care about intersecting geometry.

Also, I was trying to distribute books on the shelves, but it felt like I had to add a point cloud object for this to work, and even then my point cloud object would be disconnected from my bookshelf object, because it can’t share the same nodetree and variables that I used. So my point is, all has to happen within the same nodetree. It’s great that we have a point cloud object, but we have to be able to specify points onto which to copy objects within the same node tree (point instance node with two inputs, one for copied geometry, one for points).

Also we totally have to have the ability to add handles (gizmos) connected to properties, to manipulate these things directly in the viewport. That would be awesome.

4 Likes

Or have a control object that is an empty that can contain the tree and then define different targets from inside the node tree, not just as a Geometry input node.

It makes no sense to have a procedural node graph if it´s fully limited to a specific type of object, because we have to be able to mix them all, from meshes to curves, to point clouds, etc…

BTW from your shelves video it seems the performance is a bit awful, is that so?

It´s a pretty simple object that should be super fast to generate, how could we generate complex procedural objects if the performance is so bad with a super simple nearly simple demo object?

3 Likes

In that case it would turn into a scene-wide geometry node tree, and it would make no sense for it to exist as a modifier if it can influence any object, would it ? I’d be all for scene-wide nodes, but centered on set dressing rather than geometry manipulation. What do you think ?

That would be the ten boolean nodes, I think. See for yourself :
https://pasteall.org/blend/b7014c2a7d164ea9bc978ea82477a9f5

Well, as a modifier makes sense in a lot of situations, it’s a super powerful tool, but as non-specific tree could also be useful, now the scene wide, no need too, so you can have several trees per scene too, as “generic tools” :slight_smile:

What I mean by scene-wise is : not attached to an object in particular and able to affect any object. If it was made this way I’m not sure how we would be able to re-use existing node trees ? It seems like there would be no point in adding it as a modifier then, if you can modify any object from a “global” tree.
Honestly the current modifier approach feels a little redundant with node groups, but maybe I’m not seeing the bigger picture.

edit Ok one thing I did miss was the geometry output on the object info node. This is brilliant, now we can pull in any geometry, which is -almost- akin to creating primitives directly in the tree. Sooooo I modeled a quick book (DESTRUCTIVELY) and now I’m trying to put in on the shelves. Yaaaaay !

1 Like

Oh no, referencing other node trees is super important, it’s a way to develop more low level tools, with different input/outputs, and the modifier form is also very important, the other is just an option we may have too.

As a modifier it opens hundreds of possibilities that are not there right now, like linked modifiers for example.

TBH I think the system is prepared for that, it just needs a random input node.

In the end, the system has been in development for quite a long time, probably things are more settled that what we see right now.

As always the only thing that worries me is the performance, 10 Boolean operations are not that much for such a low performance

Sure, but that could also be done with linked node groups. However, I admit that in a modifier form, a geometry node tree is probably easier to make sense of, and use, than its equivalent in nodegroup form. At least it’s higher-level and can easily be inserted between other modifiers.

Agree we’re probably just seeing the tip of the iceberg heheheh

Don’t take my word for it but I think a boolean is super slow compared to a merge, I’m confident it’s just the slowness of boolean we’re witnessing… at least I hope so

1 Like

Yep, me too :slight_smile:

I have a proposal of adding custom properties to a node tree.

You can use the attribute node for that (only in 2.92 since very recently).

Will be a better concept and user experience an empty object that contain the node tree, it’s not incompatible with the modifier idea. In a normal node tree object you can edit node groups (like in the shader) that can be used in modifiers.

Could be also good to have the possibility of edit a vector info like rotation, scale,… with a single vector operation that affect to an attribute of the mesh/points

Am I misinterpreting how these nodes work? I tried a very simple setup and the object disappeared.

Also, the modifier is named “Empty” now. I’m not sure if this was intended.

Add the modifier to a pointcloud object instead and use the object info node to get the geometry to scatter and the geometry to scatter it on. That’s pretty confusing for now, but getting the scattering to work with mesh base objects requires larger changes to modifier evaluation that are probably too risky for 2.92.

Strange thing is that in every video I’ve seen other people use geometry nodes, they apply point distribute/instance nodes directly to the mesh object and it generates points no problem. For example:

Is this some alternative branch or did the functionality change in a recent build?

As HooglyBoogly mentions (who is one of the main devs on the project), this has changed in the last week since that video was captured.

Just use the scatter nodes on a point cloud object as in this screengrab.

2 Likes

What are you supposed to plug into the orange Object type inputs? None of the nodes seems to have an output socket of that type.