Today there is some overhead for instances in geometry nodes, but when the legacy instances are removed, the overhead will already have time to fix (I hope)
2 Likes
I am not sure about âpoorly controlledâ part.
GN is a visual programming language, so switching instansing to GN realization is a raising abstraction level.
Raising abstraction level is always about more âmetaâ - downsides are less discoverability and less clean manageability.
It is like managing one versatile modifier with operation selector instead of clearly formed different modifiers. In short, it is technically possible to replace functionality, but it is not possible to replace manageability)
Also, is it planned to support blend files backward compatibility? I mean, is it planned some kind of interpretative conversion of a removed functionality in further software versions, which is typical for raising abstraction level cases?
To mention
- higher abstraction levels are more technical
- lower abstraction levels are more artistic.
Even with the explanation below, not sure if weâre talking about the same thing.
By raising the level of abstraction, you can move from an instantiation node to an instantiation group.
Replacing the functionality with a group of nodes is unification and standardization. The level of abstraction is what is being discussed here now (if you have a suggestion for a node groups).
Itâs still easy for artists to add this by simply adding a modifier (+1/2 click).
Backward compatibility? Node groups will work the same way as before.
That is, you want it not to be a node groups?
I donât think itâs:
- Necessary.
- Possible (by removing this from the blender data structure).
- Justified.
Will the geobased version support âScale by Face Sizeâ option?
1 Like
You can check the last file I posted
I tried to reproduce the functions in full there (by reading the code and doing it in nodes). So yes, it will.
2 Likes
How in geonodes you can you define if some object is instanced somewhere in a massive scene to make a decision if you can delete it or modify?
Group input named as Parent is confusing, it has nothing to do with actual parenting, so it is a naming collision.
The host can be a better name for it, especially taking into account that GN version works in reverse in comparison to parenting.
Also didnât succeed to realize the resulting cones to separate instances, but it is a complex topic, maybe I am missing something.
1 Like
Agree. Also not to forget that setting up geo nodes for a more or less minor task is always a hassle.
If geonodes really were to completely replace the current modifier stack, I think there should at the very least be some sort of âquick setupâ preset that mimics the current modifier setup behaviour by creating a geonode preset in the background with exposed options similar to the old modifier.
If the user wants or needs to go in deeper they can open the geonodes editor and improve upon.
Otherwise they can simply use it as is and have a geonodes setup be created and work quietly in the background.
Donât get me wrong: Geonodes surely is powerful but is it really planned to make Blender work similar to Houdini with Geonodes as a necessary core design paradigm in the future? For now this still sounds a little un-blenderish to me.
1 Like
Letâs not get distracted by changing modifiers. This is the transfer of another function to modifiers. And its interface (panel) remains almost the same (with the exception of a separate input of descendants).
2 Likes
The plan is not to replace the modifier stack, but to turn each modifier into a geometry nodes node group that ships with blender by default. The modifier tab will still be there.
If done right, this would not impact the current workflow from the usersâ perspective, apart from that the user would have the ability to adjust the node tree if they want.
Perhaps, to impact the workflow even less, there could be a âParent objectâ node, which would work like the âSelf objectâ node, but would link to the parent instead. And âChildren Collectionâ too. This node could be used to instance all children on points/faces just like it does with the legacy instancing.
6 Likes
Ah okay. Nevermind me then. Thanks for clarification 
Found a difficult place.
If we also want to instantiate non-geometry (lamps, emptys, âŚ) then we donât want to realize geometry.
But if you do not do this, for some options extra nesting and a large overhand for rendering instances can be obtained (if you delete all realize instances nodes in the test file, then you will be waiting for a minute a new frame!)
Hey, hi guys. New problem here.
Right now old instances work as well:
- Create object childrens copyes for each points.
- Transfrom this (move to point, aling to normal, âŚ).
- Apply child object transform on instance. Transfrom also in parent space. Not in instance space.
How it look like:
Problem:
Geometry nodes right now canât get some random attribute (transform) value from nested instance and allow to use it, read/write.
So if i instenced some childs with himself initially applied transform, it will look like:
Reason: Child transform applied before instance.
If we just ignore that, behavior will look different:
Solutions:
- It possible to capture transfrom on child as instance. After instanced all of that, realize instances. Now it possible to apply transformation in object space.
Problem: It lost main goal, result isnât instances and we have to transform a lot of geometry. - For each child can be created on point cloud duplicate with instances transform. Sampling from instances by point cloud duplicate-index allow to have transform child X instance in same domain and avoid nesting. Problem: are it not so complex? Also, need to manually copy a lot of points, but not so bad i guess.
- Wait accepting of node for realize not all instances, but only first one. This give access to nested instances with recuered transform. But this not so desired for me.
Node tree design update, which will replace the old function automatically in new versions:
Example in collection For each parent should be similar to Now collection.
Pay attention to the new methods of delayed transformation application for instances.
I was change naming to:
- Instancer - Parend object.
- Instanse - Child.
- Instances - Result.
- Geometry - General naming.
Sure, but I would probably prefer to have real parenting node to keep the same manageability level as legacy instancing infrastructure has, as Freemind mentioned.
Parenting links does a nice job of making clear what belongs where when you work with massive projects during collaboration, this is why we prefer to use it over GN in our studio. Hope it is possible.
List of children, this really sounds like an attribute-array of properties for each object in data block nodes / object nodes / scene nodes. So I just wouldnât want to try to run ahead and do it in geometry. With the same success, this can be added to shaders if there are sockets for data blocks. You can always want to make decals for childs through a shader
While node group can be added that are updated by the addon and can collect all the children of the object, this is just something that can be automated for now by using python.
Sounds good.
We actually familiar with making object dependencies handling addons (for example, select all the instances of a selected objects or filtering from a selection objects that have instances)
Using them quite often to manage sceneâs data.
2 Likes