There is some quirk with how instances are getting realized when you do multiple levels of instancing. Here I placed smaller cubes on 8 vertices of the default cube, and then instance spheres on resulting geometry. Result should be 64 spheres, but instead I just get 8 instances. So for some reason spheres got merged with cubes into a single mesh, and that not something you’d expect from this nodetree.
Is this a bug or a “feature”?
Thnaks. That’s more or less what I have now, as a node group. (Though yours is prettier, I really need to get some practice in node tree prettification, because mine look like somebody dropped a warehouse of nodes on the floor. )
That’s expected. Just like other nodes, the instance on points node only calculates once per unique instance geometry, meaning it creates nested instancing. The manual page goes into a little bit more detail: Instance on Points Node — Blender Manual
Do anyone know if a geometry node for extrusion/solidifying of curves will be part of 3.1?
I noticed a slight ambiguous behaviour of some attributes in curve objects.
Because a curve object is made up of both points and splines, A particular attribute can have different values depending on the domain it’s being read from and that can be problematic. For example, the Set ID node only sets the ID of the curve points and not the splines and this is problematic for something I’m currently working on where I need to set the ID of the splines instead (or both at the same time)
are they plans to tackle ambiguity like these?
Another node that has a similar issue is the curve parameter node. The parameter attribute is different for curve points and splines. Although I haven’t had any issues with it yet and having different values per domain is expected in this case.
Hi Astronet,
I believe this can be achieved if you use the “ID” node and plug it into the “Attribute Capture” node, switch to the “Spline” domain so that you can set the IDs for each individual spline. In any further cases where you want to set and store values on different domains, I’d highly recommend checking the “Attribute Capture” node, it basically allows you to store values in desired domains.
Dalai and Erindale talked some day somewhere here about medieval wall creation. Back then i had difficulties making my point, but blender evolved into my hands. Tadaa!
…but maybe someone can tell me what i do wrong here? Why is the voronoi not matching from topo to texture?
Good question. From looking at your tree, it should match. Can you share the file ?
Is there a place here to post blendfiles?
http://www.makehumancommunity.org/forum/viewtopic.php?f=2&t=12986&p=54980#p54980
let me know if you have issues grabbing the file from my temporary datadump 
Hello @CubicSpaceMon_K,
Thanks for this. However, this only solves half the problem. With this one can successfully get the spline attribute separate from the points attribute. But there’s no solution yet to set the spline attribute.
For example, say I have 3 different curve geometry with single spline and I want to join them together. But before that I’ll like to set the ID of each spline so I can use the value I set to drive another field (say the End field of the Trim Curve node since trim works per spline) after joining them together. This doesn’t work right now because there’s no way to set the ID of the spline domain. The ID used instead is the index which is the fallback if no ID is set.
When i copy all the nodes to the shader side, it works. But then, when you change something at the GN, you always have to adjust also the shader, or use drivers, which break when you ship this as an asset from outside (or is that issue solved already?).
It would be easier if one could just create a nodegroup on the GN side and then one could find that entry on the shader side under shift-a/Groups.
I took a long look at it and couldn’t figure it out. The weirdest thing is, you’re actually sending the vertex attribute to the shader nodes, it’s not like you’re using another voronoi in there.
I inserted a distribute points on faces after the texturing step, so I could visualize it, hooked up the texture output to the distribution density, and it had… no effect. I’m a bit stumped here
This issue brings to mind the heated debate months back about the removal of Get/Set Attribute node (named attribute). I remember one of the major points for keeping the node was that whenever a new built-in attribute is added, there will be no need to create custom Get/Set nodes for it specifically since we can easily access it with the generic Get/Set node. With the generic Get/Set node I can easily choose the domain of the attribute (I assume). I guess that decision is biting back already. 
Ah, then I believe you just need to use the “Capture Attribute” twice. I just check and it seems that when you use the “ID” node straight away after the “Join Geometry” node, it just automatically resets your IDs back to default, which is quite a frustration. So, you actually need to store your custom IDs into the “Point” domain first and then pass the outputs to the second “Attribute Capture” node, which will then switch your custom IDs from “Point” → “Spline” domain. This is quite a workaround and until we can get a proper “Get/Set” node, I don’t really think that there will be any pleasant way of doing things like this.
Ah, I see. Thanks again for the help. This does solve my problem 
@CubicSpaceMon_K thanks for sharing this, although I don’t understand why once I reconnect last Capture Attribute node into the Group Output node I can’t see those IDs on Spline Domain anymore, any idea?
Transfer Attribute gives a warning when converting an attribute from a curve to a mesh, but it does work as expected.
Edit: Darn, I though I captured the warning itself as well, but it seems the tooltip disappears as soon as I press PrintScreen. The warning is: “Input Geometry has unsupported type: Curve”
Furthermore, when I try to suppress the warning by inserting a ‘Curve to Point/Mesh’ node, the normal info gets destroyed. Curve to Points has a normal output, but plugging that into the offset of the mesh doesn’t work either. Which makes sense, because there’s no attribute transfer node in between.
Is this expected behaviour? I’d expected the normals of the curve to carry over to the mesh/points.
Also, the transfer works fine from curves to mesh. Maybe the warning is obsolete/ unneeded?
I think the main reason why the values aren’t being displayed in the “Spline” domain probably has to do with the fact you’re in “Evaluated” mode in the spreadsheet. Maybe I’m wrong but this is just my speculation: For now, I don’t really think that you can actually view the values in any different domains other than the default “Point” domain unless you stay in the “Viewer Node” mode. Even if you’re using “Capture Attribute” on other domains and when you connect your node tree to the “Viewer” node, it does show up in the spreadsheet, once you switch to “Evaluated” mode, the values only display in the “Point” domain.
