I think thatās the idea, but @jacqueslucke or @HooglyBoogly can help clarifying that.
But they can be considered āsecond classā since something has to come āfirstā hehehe itās a matter of time IMHO 
Iāll try to clean up my current experimentation with GN + curves a bit to demonstrate what Pauan means, and post it here. Because Pauan is IMHO right. Currently GN in some cases ignores the materials that are attached to the curve data in a way which feels very counterintuitive.
I generate shapes based on input curves, and Iād really like my GN tree to use the material that was on the input curve for itās result. That currently only works if you go to the hassle of
- select curve object
- create material (so far so good, Iād expect to be done here)
- click link dropdown (isnāt it strange by the way that the link dropdown only appears once you have a material attached to the objectdata, but that aside).
- link material to object as well.
1 Like
Apologies, I do understand the problem with the following clarifications. I tried to capture an attribute using material selection to re-use it on the resulting mesh, but it seems this node doesnāt work on splines, because the attribute appears empty on inspection.
On the contrary, geometry nodes is all about doing the opposite. Thatās why the socket type is āgeometryā, which can contain any and all geometry types at the same time. Data types are abstracted with attributes, so many nodes can work on any geometry type with a position attribute, for example. That was never possible before, and it will only happen more in the future.
If it looks like curves are āsecond-classā in geometry nodes, just compare the curve and mesh categories in the add menu.
This is correct. The list of materials in the curve object materials tab only applies to the evaluated mesh. Currently materials on a curve are not used in geometry nodes, because, like @Hadriscus says, data without a surface cannot really have materials. That may change in the future though, Iām not sure.
6 Likes
Hi Hans, -even though curves canāt render materials they can still technically have one assigned right ? this is what Pauan was asking. If passing through geonodes destroys that assignment, is there a way to restore it ?
I tried something in my previous post (capturing boolean attribute with material selection node and re-applying it later on the beveled curve) but it didnāt work. I feel like it should workā¦ Or is it more like a known limitation ?
(In light of your explanations I assume the captured attribute is empty because the curve loses material assignments as soon as they enter geonodes)
sorry for the ninja edit
2 Likes
Thatās what I meant, curves in geometry nodes donāt store a list of materials. Personally I think we should find a more general way to make passing a list of materials possible, rather than adding a list of materials to a geometry type that canāt directly use them.
3 Likes
While this sounds logical, itās not like curves work outside GN. There they can have a material just fine, and it shows up when you bevel or extrude the curve. So it only shows up on derived meshes, but the material info comes from the curve object.
For example this GN analogue of beveling the curve:
Iād expect this to behave exactly like beveling the curve, but the resulting mesh just has no material.
3 Likes
To me this seems more complicated than it needs to be, adding a material list to curve geometry seems the most straightforward and consistent solution. That curves canāt be rendered directly I donāt think matters much, itās clear what the materials would be used for when you tessellate the curves to be renderable.
13 Likes
What you want is not a geometry transform, but a vector transform mode set on the position attribute 
Vector transform already exists in cycles, i made a nodegroup for this here Geometry Nodes - #2144 by BD3D (few posts below)+ it supports reverse toggle
Thanks, but my question was really about why the transform node canāt accept values from the random value node.
I already tried the set position node to set a random position but that one operates per vertex therefor each vertex gets a different random value. I am trying to apply the same random value to every vertex position uniformly.
This was the only solution I could find. I added a random driver to an input field, but this is far from ideal given it is updated on each frame. My other option would be to write a script that is triggered by some common seed I guess.
Change the ID, by default it will use the builtin ID attribute that differ per vertex, if you use a single int value the random will be uniform
Itās not very intuitive because, for this very specific case, the id transfer is done implicitly, like pre-field geonode
1 Like
That works as a decent work around, thanks for the tip.
Hey, @dfelinto!
What do you think about my neon sign generator? Would it be useful as an official demo file? It demonstrates use of the new text nodes very well.
Iāve gotten very good reception of my gumroad page so far:
Let me know what you think!
2 Likes
@SimonThommes Sorry for talking to you here, but i canāt log in to the geonodes dev-chat, and i feel the need to respond to what you said at the GN.chat:
" When itās about workflow speed for people that already know which node they want to add the idea is to move more to a search based adding workflow. The add menu is more intended for discoverability and organization. That is a much better approach the more nodes we have."
Please while tweaking the workflows donāt forget those people who have to look at the keypad to know which butten they press, such as me. The āsearchā-workflow for me is one of the worst.
But the new subcategories are fine for me. Just please donāt forget those people who hate to work with keyboards. Thx.
Of course the intention is not to replace the add menu entirely. But we are only getting more nodes from here. For a fast workflow, hunting down the right menu entry every time you want to add a node is just not viable anymore. The submenus help with organization and will, of course, be kept up to date with new nodes and not go anywhere.
Focusing on the search means that this will also improve over time. The idea is to make the search smarter with nodes you nodes you use a lot to give them priority for example. As more nodes are added we can also leverage the tag system of the assets to find nodes more naturally. And there are already ways to make the search process more efficient. For example a quite reliable way of finding nodes with long names is to use the initials, rather than typing the entire name. (e.g. dpof for Distribute Points on Faces)
Personally I have been also adding nodes via shift+a for the longest time, but more recently switched and Iām not looking back. The only issue for me is that itās still not super reliable that you get what you want 100% of the time. But that will get better.
9 Likes
That would be absolutely great. Itās how I have become accustomed to other node systems with a fuzzy search. For discovery, a neatly organised menu is useful, but for everyday work, search menu is a must. It would also be great to extend that sort of smarter fuzzy search when doing drag-add-connect from a node input/output.
1 Like
Didnāt read the whole discussion. I just want to add that yes - search is the way to go.
The only problem that Iām facing is that search does not differentiate between build in and custom node groups. Having naming convention helps but this area needs to be managed by a user. Finding a way to quickly switch between default/custom node groups in search would be great.
1 Like
What would be even better could be to be able to type in search simple math expressions and get a node with the correct settings. For example typing the following in search:
-
+1.5creates a Math Add node with the second item being 1.5 -
*-1creates a Math Multiply node with the second item being -1 -
/2.5creates a Math divide node with the second item being 2.5
17 Likes