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 ?
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
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.
4 Likes
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 ?
Hi guys, hereās my new video on making instances to follow a curve + short advert for bLandscapeTools at the end
13 Likes
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!
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:
This is 95% of my node setup, pretty small and simple compared to what Iāve seen others post
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)
12 Likes
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.
1 Like
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.
1 Like
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.
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:
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.
1 Like
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.
5 Likes
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 *
Combined with this seems perfect to me.
Thanks for the response
1 Like
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ā¦
3 Likes
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
1 Like
Is there a reason why Boolean node is limited to Exact solver?
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ā
1 Like
Currently, the plan is to hold off from adding the fast solver and make the Exact solver faster.
3 Likes
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.
5 Likes
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
1 Like
It does seem counterproductive and forces me out of geometry nodes workflow back to using modifiers, where I wouldāve been just fine using only nodes.