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)
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?
- 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:
- Possible (by removing this from the blender data structure).
Will the geobased version support “Scale by Face Size” option?
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.
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.
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.
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).
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.
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:
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:
- 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
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.
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.