Geometry Nodes

[DamianWinnichenko]

Does anyone know how to access Shape keys from Geometry Nodes?

For example, I want to scatter a few plants of different ages and animate them growing by changing its Shape Keys parameters.

[hemigon]

I’ve been experimenting with a workaround for getting real UVs on procedural geometry.

The core idea is to use the UV Project modifier to get a valid UV data layer on the geometry. Basically add a UV Project modifier after the geometry nodes modifier, set any object as a projector and you should get a real UV map.

After the UV Project modifier, the easiest way to adjust UVs is by adding another geometry nodes modifier, then using the legacy Attribute Convert node to convert an attribute of your choice to the “UVMap” attribute. This avoids destroying the UV layer. There are ways to get around using legacy nodes, but they are a bit more involved, so I recommend just using Attribute Convert.

The main limitation is that this method only works for one UV layer. Even if multiple UV Project modifiers are used, only one UV map will count as a real and be renderable.

I’ll try do a more in depth write up at some point, but I hope this helps for the moment!

[Eary]

I think we need a more convenient way to turn nodes-generated geometry directly into instances, the current approach I use is to each use a single vertex to instance them and then join them together, but this just feels a bit awkward to me.

[Grinsegold]

Hi folks, does anyone understand how to match the GN generated mesh with its shader? I tried it like this, but obviously it’s wrong:

I did expect the mesh to be white at the top and black at its feet.
Any hints for me?

[Miro_Horvath]

Haven’t tested it, but could be missing Set Material node?

[Grinsegold]

Awesome!

[Grinsegold]

It starts being fun: Voronoi Fields (pun intended).

[jendabek]

There are already 37 subscribers (including me) which would love to start using GNodes in their projects, but the inability to cope with UV Maps and other mesh data keeps it completely useless for us.
https://developer.blender.org/T85962#1248681

Can I ask any developer for any response regarding this task, or even some ETA when this (essential) feature is going to be implemented?

In our case we would love to take advantage of GNodes when scattering an assets over a game-scenery, but not being able to export the result with all the mesh data prevented forces us to stick with particles (and all it’s drawbacks)

Thanks!

[3di]

Would be nice if we could separate node groups into four sub menus on the shift A menu; modifier, object, blend file, and asset library (local/community sub menus)

Modifier would show node groups created inside the current GN modifier, object would show node groups created inside any GN modifier of the current object, blend file would show node groups from the current blend file, and asset library would have two sub menus (local and community) to access node groups from a system wide asset library, and a internet community repository.

Actually maybe a fifth ; favourites, which automatically holds the 20 most commonly used by the user.

[Eary]

AFAIK They are planning to add a 2D vector socket to 3.1 and make UV to go with it

[3di]

Yep, it’s infuriating that all the necessary attributes are already present on the geometry, but the choice to only grant access to a small selection of those attributes is currently SEVERELY crippling what’s possible with geonodes.

All we need is for:

1. all attributes to be available and shown in the spreadsheet

2. a generic ‘get attribute’ field node which lists attributes available on a dropdown. Exactly the same as how current attribute field nodes work, but not restricted to what the designers deem necessary…

3. a create attribute geometry node, so for example we could make a copy of attributes on certain frames to use as a ‘rest state’. Necessary for making things stick to deforming geometry, but also this allows to store data as attributes at one part of the tree, and then access them at a later point in the current tree (or even a different tree), without having to have wires running the length of the tree, or even worse in and out of group inputs/output sockets.

4. Finally a generic modify/set attribute geometry node to make amendments to existing attributes (such as normals, uv’s etc) This should also have dropdown of available attributes. At the moment we’re limited by the specific ‘set attribute nodes’ which the designers have deemed necessary, so we can’t do things like copy normals from one part of the tree to another.

Fields is a great design, but there’s no need for it to be so forceful in what it allows access to, or how the data is passed around. Just three nodes, and everyone has the choice to work in the way that best suits them.

[jendabek]

The requirement of picking / entering attribute names for converting it into legacy data (UV maps, vertex groups / colors, etc.) is no-go to me, because:

1. You often can’t know in advance which data are used by your instances (the actual names of UV Maps / vertex groups etc.), thus you can’t enter / pick it in some get/set node
2. Even if you know all the mesh data (layer names) used by all your instances, just imagine how the node setup would look like i.e. in case of tens of vertex groups used… Then every change of your instances data (i.e. you decide to rename some vertex group) means you will have to update your GNode setup, otherwise those data would be missing in the exported mesh. Such workflow wouldn’t be exactly productive…

So in my opinion there must be an option to make Realize work exactly how Particle Instance Modifier handles it: the resulted mesh just contains all the data used by the instances.
GNodes already works like that in case of materials, so it is expected to behave the same way in case of other mesh data, isn’t it?
This behavior could be optional though, in case somebody still wants to handle the mesh data manually.

[BD3D]

& rotation special vector sockets

[Grinsegold]

I wonder if it makes sense to rename the “Object”-socket from the “Texture Coordinate” shader node to “Origin”, and also the “Position” of the GN…
They both represent pretty much the same concept, right? And since they now can interact from geonodes to shaders…
Or maybe just simply replace “Object” by “Position”?

Is it worth a papercut ticket? Don’t know exactly where to put it, so tadaa.

[Grinsegold]

Call for swarm intelligence:

[Hadriscus]

I think with the id input you should be safe

[Grinsegold]

I wouldn’t ask if i hadn’t tried every imaginable combination with ID, Index and Set ID. When i change the seed of the random vector, all clouds change their shape uniformly, no matter what i plug in. I also tried all the combinations for the “Instance Index” of the InstanceOnPoints node.
2 possible solutions:
-I didn’t find all possible solutions and missed the good one.
-There is no solution for the issue in the current node set.
I doubt the latter one. Blender feels already so capable of nested visual programming.
Is there already a manual for the InstanceOnPoints node? F1 on its entry in the add-menu does nothing. Maybe i should learn what the node can and what not…

[Grinsegold]

Making progress with my procedural pun (Voronoi Fields) btw. Right in time for the winter days, the wounds of 2.8 are starting to heal. What a nice toy blender is.

[RonanDucluzeau]

Instances are duplicates of same mesh. If you displace this mesh, all instances will continue to have the same shape. You can randomize scale, translation and rotation of each instance but you can not randomize data that is instanced.
You have two solutions.
You can use Realize Instances node to create a global mesh and randomize its vertices.
Or, you can use several displaced meshes, create one instance per mesh and join those instances as one geometry (or use different objects placed in one collection) and, then, instance the geometry group or collection with an Instance on Points node using Pick Instance option.

[Grinsegold]

Just activate checkbox of the Pick instance?