Geometry Nodes

asams · 2021-05-30T08:07:28.832Z

Hello,
I had this idea for a while but could not implement it in Blender somewhat easily. With new geometry nodes I thought that finally it could be done. So what I want to do: I need to have an object which contains voxels in some way, colors of which could be accessed by Cycles volume shader.
The idea is to have some quite low-res 3D texture stored internally in blender object, which can be generated based on other geometry in the scene, etc. Think of it as of some modifier, so that during rendering this voxel data is fixed and has to be only read from the object and not calculated for each sample in shader. This kind of precomputation can significantly reduce render times if used correctly.
The simplest use-case is some distance field to several objects which you calculate only when objects are changed and in shader you just sample this distance field with some kind of interpolation.
This 3D voxel texture can be than combined with complex volume shader which through this texture can “interact” with objects etc.
As an example of how you could use it, you could generate a volumetric cloud using mix of noises in shader nodes and for color of this cloud you would use color of the closest voxel, color of which has been calculated as a mix of colors of nearby objects. In that case you can fake indirect lighting from these objects in a volume shader but without actually calculating any scattering. I hope that I made it clear

What I’ve tried to implement this kind of behaviour:

Creating voxels as a bunch of cubes where for each cube all its verticies have the same vertex color. Then I can access this voxel data via Point Density Texture node. With correct values of resolution and radius it could be rendered truly as voxels.
Problems with this approach: Vertex colors have to be painted manually or generated through python script, so this method is not interactive, which is unacceptable for my needs. I guess that there is a bug with Point Density Texture node or Geometry nodes which does not allow to use them together. Any geometry generated via Geometry nodes is not displayed properly by Point Density Texture
Another way is to use Points to Volume node. From the user point of view it generates a very similar results to Point Density Texture - for each vertex it creates a sphere with some radius filled with volume. This approach seemed advantageous to me at first, as it ties with Geometry Nodes nicely. The problem with this approach is that there seems to be no way to generate custom attributes which can be used in volume rendering; and also as this node generates Volume object there is no way to render it as a usual mesh, so volume is only rendered where density is non-zero. But I also want to control density via some 3d texture which can not be done in that case.

So I really hope that anyone can help me and come up with some idea to implement this.
Thanks in advance

Hadriscus · 2021-05-31T20:37:49.132Z

https://developer.blender.org/rB3da0ad6bb232bf2d3407f0c70c38f05fe621f6b7

does this refer to the loop into which components are evaluated by the network ? in what order are they by the way ? is the order stable ? by index ?

AlexisBenoit · 2021-06-01T07:35:13.994Z

Hi,
I’m looking for a way to bake “Selected to Active” (selected being an object with a geometry nodes modifier instancing all sorts of little objects, Active being a low poly version of that object), without breaking the procedural workflow.
When I bake with cycles right now, all the instances cast shadow on the “emitter” but their actual geometry/shader is not rendered. Also the normal bake simply ignores them.
This would greatly improve my “Geo nodes to real time engines” workflow, so I’m wondering if it is planned for this coming release, or if I should hold off on geo nodes for this particular project for now.

Thanks in advance

HooglyBoogly · 2021-06-01T20:17:55.082Z

That refers to the often-requested “index attribute”. Basically people want to know the index of the element in the array without using a hack like the line node. Exposing that as an attribute doesn’t really make sense since the index isn’t data stored on geometry, it’s more inherent. Since the attribute processor is per-element, it’s a natural place to expose this.

That’s the idea anyway, it’s more of an experiment at this point.

Hadriscus · 2021-06-01T20:26:02.303Z

I see. So is this index value stable across a mesh changing topology over time ? can we expect a vertex to bear the same index from one frame to the next when there’s creation and deletion of mesh elements as part of the gn network ?

Miro_Horvath · 2021-06-03T12:20:36.395Z

Hi guys, here’s my new video on making instances to follow a curve + short advert for bLandscapeTools at the end

jamez · 2021-06-05T04:02:41.417Z

I created the “Ripple Dreams” geometry nodes demo on https://www.blender.org/download/demo-files/ . A few people mentioned to me that it just gives a 404 error when trying to download it. Just tried to download it myself and found this to be true.

Would be great if someone could fix this!

xitnowl8r · 2021-06-09T01:11:25.360Z

So I realized I messed up my render but I’m impatient so I’m just going to post the imperfect version and re-upload later or something.

First: Thank you devs for all your hard work implementing GeoNodes and putting in the features that are getting requested. I have seen many clear use-cases presented and posted in this thread and all over the internet but didn’t see this specific one so I thought I’d share.

Interactive Procedural Greeble/Kitbash:

GGen-Future-1-4-11920×1080 404 KB

GGen-Future-1-4-21920×1080 315 KB

This is 95% of my node setup, pretty small and simple compared to what I’ve seen others post

Screenshot from 2021-06-08 21-12-531747×583 253 KB

I used geometry nodes to procedurally scatter various meshes, then the functionality that has been non-existent before: I could actually join the mesh, apply boolean, and bevel the result such that it truly appeared as a single complex mesh. I even used some wireframe modifier tricks to add some complexity. I did quite a bit of instancing and had to turn off the boolean while making changes, but I will say. Attempting this in 2.93 is not possible, whatever was done to speed up the boolean node in Blender 3.0 worked AMAZINGLY (at least 20x speed improvement on my computer, and actually multi-threading). I also used the material replace and material assign nodes to test them out. This was a total of 16 objects (including the boolean-only objects) to generate this in a very short amount of time. (I used Jsplacement for the greeble type material for almost all of the objects, and I also used Animation nodes for some of the animating)

Positive: -Boolean in 3.0 is so much faster and makes so much possible that was impossible. -Being able to randomize and shift greebles procedurally and see instant updating with incredible control is also amazing. -Group Nodes and the switch nodes became a lifesaver once I started implementing the boolean nodes. Even though it works within a second, if I need to edit the meshes I could just flip the exposed switch attribute and switch to the faster version of my mesh, and easily flip back when I’m done, all from the modifier tab!

Needs improvement: -I could not replicate the instancing/array modifier work in geometry nodes. When I use geometry primitives to try to scatter points that have been instanced already it simply won’t work. I tried many, many workarounds but could not get the functionality I was looking for. Not sure if it is a bug but I might do a bug report that further clarifies the issue.
-Material switching seems to be hard to predict/control, I ended up using the material_index attribute with attribute proximity nodes instead for some aspects, but still couldn’t control something like “turning lights on/off fully procedurally using geometry nodes”.

Requests: Please allow distributing primitives just like other geometry, it may just be me not understanding or using things correctly but there is something not-intuitive about the instancing nodes that prevented me from fully taking advantage of this. The switch node (and all booleans I would guess) gets exposed as a “1” or “0” in the modifier, if it could be a checkbox that would be cool!
Please please please expose attributes to EEVEE shaders, for motion graphics purposes, even if my final render is in Cycles it would solve so many problems to be able to use attributes directly in EEVEE for preview and test animation renders.

Thank you for the hard work, this is just my first test, and I’m excited to push this to the limits.

P.S. I can’t post without mentioning how great it would be to add particle nodes onto this procedural workflow, even the functionality that made it to the functions branch was enough, I just wish I could use it in Blender 3.0

Thanks again (here is a loop I made using a fly-through, but accidentally had the boolean turned off)

spencer.egart · 2021-06-09T18:24:12.075Z

One thing that I’d like to be able to do with geometry nodes is to instance something and modify the inputs of any of its geo node modifiers. Example: I’m instancing a bunch of greebles or something via Point Instance, each of which have their own Geo Node setup, but want to randomize the seed of each of them. Current workflow seems to be “create a bunch of instances manually in a collection with different seeds”, would like to be able to just grab/modify the input values of that child geo node setup on the instanced objects and set it that way. This would also allow for recursive/iterative setups.

Baardaap · 2021-06-09T20:16:36.755Z

That would be extremely cool to have indeed. No idea how hard it would be. The instanced geometry would probably no longer be instanced then, but turn into ‘real’ geometry. But even with that in mind it would be very useful to have.

Bobo_The_Imp · 2021-06-09T20:33:00.855Z

Question for the devs about selection, if permitted.

“Will we be able to control our selections with domain types?”

I was trying out some tests with the material nodes and ran into some issues.

Bevel1036×527 18 KB

Here are some pillars with a red material. I want to use the material assign node with a selection to create a pillar with some horizontal bars in a different material, blue here. Using the bevel node I could control the number of cuts aka, how many bars there will be, and with a secondary bevel node I can control the size of the bars.

1 is the desired result I am going for.

My though process starts at 2, have some pillar with some horizontal edge loops. I want to store the horizontal edge loops in a vertex group and then use the bevel modifier to create some little “bars” with a different material, just like you can see in 1. Unfortunately this method leads to 3 because vertex groups are just that, vertex based, so the selection whether I like it or not covers the whole “middle” of the pillar. That is why the bevel weight function exists for edge data. In this case I’m not even using the material assign node because this geometry won’t work.

So the next attempt uses 4 as a base mesh. I has twice the cuts as 2, and half of them are put into the vertex group. Because of this you can see there are “bars” separated by a single edge loop meant as a buffer to keep the selection from grabbing everything in the middle like 3. Using the material assign node with the vertex group, however, still leads to the whole middle section being grabbed because the vertex selection requires at least two edge loops to have a face. This means we need more than one edge loop as a buffer.

Finally in 6 I’ve creates a pillar with many many cuts, and about 1/3 of them in the vertex group for proper spacing. This finally works, but it defeats the purpose. I’ve manually created all these loops, so I can’t keep it procedural, as well since it is still vertex based, you can’t control the width of the blue bars, it is bound to the distance to the next edge loop:
Bevel

These issues stem from the fact that there is no edge groups or face groups. For material selection it’s most useful to assign using faces. In the case of beveling, as I mentioned we have bevel weight to circumvent this selection issue, but I have always felt it is more of a work around then a full fledged solution (at least stepping into the geometry nodes era).

I think there are still some discussions about selection, and if I’m not mistaken I think Jacques Lucke took some exception with relying on edge and face groups, and rather fully utilizing attributes for selection. I’m not necessarily against this, but I do wonder how these kind of selection issues will be handled then. They are super common in procedural modelling, and the current Delete Geometry node also suffers from this sort of problem, as currently you cannot delete JUST a single face, it will operate like “delete vertices”.

It really feels like we need domain type for selections. I was wondering if there is any thoughts on this.

HooglyBoogly · 2021-06-09T21:00:43.721Z

Actually, what are referred to as selections in geometry nodes are just boolean attributes, so they can be on any domain. And nodes like the delete geometry node already alter their behavior depending on the domain of the input selection.

A few problems remain though:

There is no way to assign persistent selections in edit mode yet. The solution here is to allow editing generic attributes of any domain and type in edit mode.
Nodes need to output proper selections. This isn’t really a problem right now, but something to consider for the future. Nodes like the bevel node will optionally output selections like a mask for all of the generated faces, or a boolean node could output a selection for the intersection edges, etc.

Bobo_The_Imp · 2021-06-09T21:38:25.859Z

HooglyBoogly:

There is no way to assign persistent selections in edit mode yet. The solution here is to allow editing generic attributes of any domain and type in edit mode.

I think I understand what you mean by this, and that would fix this kind of thing I believe. I’ll look forward to that when that rolls in. Vertex groups are so passé * scoffs high classedly *

HooglyBoogly:

Nodes need to output proper selections

Combined with this seems perfect to me.

Thanks for the response

Hadriscus · 2021-06-09T22:36:23.677Z

This idea is very thought-provoking. By letting the point instance node access modifier-exposed properties maybe ? link attributes to properties this way ? say… the instanced object is a patch of grass and has a GN property called “curl” (yes grass curls sometimes), the point instance node could sport a string input for the property’s name “curl” (it would have to be typed in), and allow the user to connect a curl attribute to that socket.

I imagine it’s getting less of a point instance, maybe more like a point spawn or something… because obviously this would break instancing

Maybe make it a separate node with all the controls, and leave the point instance node be just an instancer like it’s claiming to be. Then the point spawn node could also access object properties…

Hadriscus · 2021-06-10T14:27:05.184Z

The mirror node (⚙ D9969 Geometry Nodes: Mirror node) has, like the modifier, options to move and orient the symmetry plane. In the video the developer shows it is possible to plug an object’s position and rotation outputs to the mirror node, making and ad-hoc controller in the form of the object in question… and I want to imagine a node that when selected shows a gizmo overlay with a handle that you can move freely and snap to things. No extra objects

Mikhail_Rachinskiy · 2021-06-10T14:52:12.700Z

Is there a reason why Boolean node is limited to Exact solver?

xitnowl8r · 2021-06-10T18:02:48.090Z

I think the biggest thing that I think would be a relatively universal feature would be having a “Mask” or “Selection” attribute (possibly just a regular boolean attribute type) output that could be created for all of the geometry operators in geometry nodes. It seems like this would be useful in so many different workflows and use-cases, and could provide really quick manipulation by multiplying with other masks to get fine-detail “selections”

EitanSomething · 2021-06-10T18:40:03.241Z

Currently, the plan is to hold off from adding the fast solver and make the Exact solver faster.

JuanGea · 2021-06-11T08:03:48.873Z

IMHO this should never be a plan unless you have a defined timeline for such integration that you are sure that will be accomplished.

I mean, what you are doing with that idea is removing a performant feature to the user with the hopes that in the future a non-performant future will be more performant, but meanwhile the user has to use the non-performant feature for no reason since there is a performant feature.

So that does not make sense, Fast Solver should be added because it exists and it’s very useful in MANY situations, when you make the Exact solver as performant as the Fast solver then you can remove the fast solver.

Don’t remove something with something that may never happen or exist.

E.G.: Particles are not receiving any attention since 2.8 because they are going to be replaced by a new system, when? who knows, we may be stuck with several bugs for years for that reason, I insist, that’s not a good reason.

If you have something to replace it, great! if you don’t, then don’t.

Hadriscus · 2021-06-11T09:37:48.498Z

I agree that seems like a strange decision. Are there hidden costs involved in adding the fast solver to the boolean node ? I would assume it to be straightforward

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations