Geometry Nodes

https://developer.blender.org/D13838
Do I understand it correctly, that instead of making Geometry Nodes work with classic mesh data (UV maps, vertex colors, etc.), we are asking to wait and hope all the exporters and other tools will learn to work with attributes?

Yes, that’s it. Short term it might be more difficult, but in the long run it’s definitely the better decision.

1 Like

Thank you for reply. Is there also some solution planned regarding preventing / reassigning UVs and other mesh data after Realize node? I need to take advantage of this node to improve the viewport performance when working with large amount of instances, but since the result loses the mapping I can’t really work with it anymore.
Thank you

Just to clarify, it doesn’t lose the data, it just outputs it as a generic attribute instead of a specific UV layer. The realize node will probably always create generic attributes at this point. You can use an attribute node in the shader editor instead of the “UV Map” inputs. For exporting, support for generic attributes in exporters will be added over time, probably starting with Alembic.

6 Likes

Isn’t the plan for ‘specialized UV layers’ to disappear completely and be replaced with generic UV attributes throughout all of blender?

1 Like

5 posts were split to a new topic: Using generic attribute data type for UV layers

Is that the one where the normals were split off into a separate array?

I can have a look at the code. But I’m not sure if I’m up to snuff really changing it. For example: when I look at the task you mention I see

In the longer term, this should be stored as an optional named generic float attribute (see T89054).
In the shorter term, this can be stored as CD_BWEIGHT

And up to now I thought the CD_* layers were the generic attributes. :smiley:
As a beginner in the codebase it’s quite hard to know which parts of the code are the old-stuff-to-be-replaced and which parts are the new-and-improved stuff.

Anyway. I can fool around with it, might be a good way to learn.

Is there a way to mimic Instance Face behavior with nodes? How do I copy face rotation the same way Instance Face does?

1 Like

Good question
you want to get the “tangent” of a face somehow, and use it in your rotation alignment, not sure how it’s done :face_with_monocle:

@BD3D
Here is approach using face corners.


5 Likes

Of course! :grinning:
Using indexes

However this produces quite a random result, isn’t it?

In some cases it would be visually interesting if our instances tangent are following the topological flow of your mesh, or at least respect it’s consistency. I was thinking of measuring the length of each edges linked to a face, and using the direction toward the shortest edge to align our tangent, hard to say w-o trying.

Perhaps this is possible with 3.1 with he new mesh inputs added by Johny.
Did not tried 3.1 yet.

1 Like

Thank you! It does not produce consistent rotation on more complex models like UV Sphere, but it works perfectly well with planes, which is what I need.

Mesh to Points node should really have tangent, normal and rotation outputs, similar to Curve to Points.

Anyone knows how we are able to create, get and delete new attributes with nodes in 3.1? With nodes of course, it’s called geometrynode afterall.

You have to connect fields to the group output and name them in the modifier interface

I am about to use GNodes for scattering large amount of instances (~300k).
While the viewport is now perfectly smooth thanks to the Realize Instances node, it makes the density editing (using vertex / weight paint) very laggy.
What about adding some kind of “delayed update” feature which would pause GNodes updating during vertex / weight painting (until the editing / stroke is finished)? Do you think such feature would make any sense, and is it even technically feasible?
Or is there any other workaround how to significantly improve the performance of this task?
Thanks

1 Like

disable the modifier?
reduce the number of instances when editing?

I meant without sacrificing the productivity.

Yes but that is a poor solution that leads to a lot of convolution/limitation

i’m talking about T90864 :

  • Store Named Attribute (set attribute)
  • Named Attribute (get attribute value)
  • Remove Attribute (delete)

any news anyone?

We’d like to finally use geometry node in our studio pipeline, witouth these flexible node the whole studio is stuck because we can’t replace our basic houdini needs. This modifier interface is causing some serious pipeline issues with us

2 Likes

It’s too late for 3.1 at this point, but we just talked about those nodes this week, and agreed on the basic ideas. I can’t promise anything, but I would expect them earlier in the 3.2 release cycle.

16 Likes

This makes me sad :crying_cat_face:. Considering how heated this discussion was last year I was really hoping named attribute would be the first thing to address for 3.1. I’ve indefinitely paused two major geonodes project because if it. Oh well! Waiting a couple more months isn’t all that bad I guess.

2 Likes