I’m instancing elements on a main object, let’s say, windows.
There are several objects using this GN modifier (i.e., buildings)
BUT, the model “window” is not just a window- it has a GN modifier. Thus, I want different windows for each building, each type of window modified by certain parameter/attribute given by the building.
I’m trying to pass values from the building, but I don’t get it. Any ideas?
You could store the window type on each building (a string stored inside a bundle, or as an attribute on the geometry), then look it up from the window instancer
Well, that’s a point. In fact, I do that because there’re several window types.
BUT… besides the windows type, I want certain modifications via another parameter used by its own nodetree.
For example, the number of glass lattices, or the type of corners…
So, I’d like to get a value from the main object to be passed to the window nodetree modifier.
Sounds like that would cause a dependency conflict since it’s not guaranteed that the window modifiers will be evaluated before the instancing
I don’t understand why that doesn’t work for you ?
Welcome 
..
I’m also not sure if i understand the question:
You seems to switch some “sub-object-slection” via some input parameter…
So why do you have problems to use it ? If you are chaining some geometry node parameters then you “simply” need to to wire it as some output parameter to transfer it into/onto “the next stage”.
Or.. you might rethink the conceptof you geometry nodesat all..
You may have to elaborate this to get a more suited answer.
I don’t really understand your answer, sorry. Anyway, I summarize my problem in this composition:
In the object “monutain cones”, the instances are the object “Tree”, with a certain value 0 (here, the Index switch).
In the object “mountain cubes”, instances are the same object “Tree”, but another value: 1.
It’s better to “stay on topic” 
.. Anyway:
In both cases you should overthingk your workflow. Somehow you have to decide which type of additional object you want to put onto some other and so use this “decison” as input on some geometry nodes. You are doing this inside the geometry nodes setup and then want to use this information “afterwards”..
So if you really need to “transfer” the input then you can use somethign like this:
This has a good looking, I’m working on it. Though I already tried something like that…
Thanks everyone, I’m going on…
Ah I see. I would create several distinct objects for various instance types, then the logic for swapping instances can live inside the “distribute” modifier, that’s where you’ll pick which one to use according to some property or string you can store on the terrain object.
I’m very confused about what your goal is: you talk about buildings and procedural windows.. but then you post an example with mountains and .. random stuff ?
Ok, the goal was simplifying, and I took the “trees” as the “windows” in the other example.
Well, I rewrite what I want.
You want to make a city: 1000 buildings. You make, however, these 1000 objects as boxes.
You decide where put the windows onto each of them. So you develop a nodetree which distributes ONE object name “Window” along the faces of the buildigs. In any how.
The you realize every window is the same. You need some variations for the object Window, but keeping even those ones in the same building.
For that, I’ve made a nodetree for the object window, which variates it for each different building.
I think this explanation is clearer…
By the way, the group/attributes solution looks impossible to implement for me. I agree with the idea tha there’s some type of conflict, maybe not cyclic, but related to loss of object data, by the conversion object to geometry, of something like that.
As i wrote before:
I might be some better idea to think about chooseing some “context based” selection for the changeable sub-objects and use these as inputs for the geometry nodes setup than changing the already made procedural “decision” afterwards.
For the trees this might be some “mixture” between height and a slope and for some windows this might me some map-controlled/weighted area of some distibution factor for some areas in some city..
Even some “random” value might be of use.
I think what you actually want is a Collection instancing setup where a value stored or created in the building modifier determines which collection object to use
Windows collection containing all your different window types
Instancing in the building modifier
The Instance index value can be created in whatever way you want, it can be exposed in the modifier through the group input for each building or it can be calculated based on the height of the building mesh etc.
Not really, I don’t want to choose. If I have 1000 buildings, I can’t model 1000 different windows!
I want that the window object to be modifiable/adjustable, changing its characteristics
Yes… I agree, this is the goal. But I can’t find the way.
The clue is how to know in which building/mountain is instanced the sub-object each time. I go trying, but I find it hard.
Do everything in a single object
You might have not understood what i’m trying to tell you. It’s like in some object orientated programming language.
If one change some “data” and always has to “remember” when and why those changes happenend this mircomanagement whill make this project by far too complex because it’s too complicated.
If the changing operations are put into objects which “do know how to handle their own data” then you only have to tell them what to do.
So you might use some “random” value to tell every house to “make use” of one of the possible windows and does not have to bother about this any more.
With this you also do not choose some window type and after that something else:
..but let the object (via geometry nodes) let choose the window type, glasess and corner..
You are overcomplicating this. Procedural generation is to make it simpler and not to fidle with every little detail.
Yeah, of course I’m not trying (as user) to give the parameters to change the windows characteristics by hand: this might be done randomly for each building. The problem is, how to say to the window how it has to change, which parameters must use.
Surely I’m not facing the problem properly, but i’m not how to solve it in other way.
In your window example you already showed this.. depending on the index this will use one version or the other.. so now when using for example somethigng like this..
..you got a random version of windows for the entire house..
Also for different versions of such a window you showed already the two version of some differnt geometry based on a Cube and a Cylinder..
Your jumping of topoics and contracticting statements are very irritating.. and you may have to elaborate this to get a more suited answer. So you might have to rethink all this or you are just joking around here ?? IDK..
Good luck.
