…added some curves for “dynamics” but the ends of the arc curves don’t line-up perfectly, (I’ll leave that as an exercise for the reader )
Currently, when you “realize” instances, any properties captured in the “Instance” Domain will exist on the realized instances… so, in effect, what you are asking for exists already (Since 3.1, I think). The “gotcha” here is that you still need to respect non-field inputs for primitives, so to get to the point that I think you’re asking for you need to think in terms of placement of generators, rather than placement of instances… i.e. better to carry points down the network that you feed into seed-based generators, rather than generated objects that you feed to an instancer.
Placing generated geometry (From a node group tweakable with parameters) on location of points works good like @zeroskilz stated. But as long as we have no loops, the problem @audiumn mentioned still exists: That it is not feasible anymore when you want to place a lot of them.
Encountered the problem last nodevember…when i generated a bunch of flowers with a generator and parameters to define the bloom(opened) state of a flower, depending to the distance of a bee. Had to limit them to a small amount to keep the effort reasonable:
I still need your help to figure out things that go way beyond my actual knowledge.
I tried to establish a rule which is this way : Each side of a corner, you have a corner instance.
Then I want a windows (alway) right after it, followed by a inbetween wall instance.
I can’t get it right. At all. It works on some islands but not on others.
In addition to that, I want to always have a certain number of faces to always have a window 1st and a window last with at least a in between wall between.
Also, the accumulate field gives me the opportunity to generate multiple floor easily but the random collection of windows remain the same selection for each floor. I can’t find a way to have a different random output for each floor iteration.
I think this problem is the same as described in the posts above. If you need each floor different with different parameters (in your case a different seed) in your floor generator nodegroup, than each floor needs to be a different instance.
So you would need one nodegroups creating a unique instance with a different seed for each level. And then turn them into an instance collection to feed the instance on points node.
For those paris buildings with 4 or 5 levels this still seems managable. But for Taipeh One like skyscrapers you would definetly want to wait for loops to be implemented (But if someone can prove me wrong on this i would be lucky).
Related to this post : Geometry nodes : Get Size of face
I found a way to scale instances to the size of the face it’s on, I search a long time on google and here and didn’t find any post about it so I did it myself (first time geometry-noding it might not be optimal)
I hope the solution will help someone :
The trick is that face corners are packed 4 by 4 so some indexing manage to get edges of faces. I’d reckon there probably could be a node doing it directly…
And then a bit of math to figure which edge is the most “upward”
The output to the “find up” frame is in order : the direction of the most upward vector
a float3 giving the size of the face in those direction x : leftmost, z : upmost , y : normal of face
Oh yeah ! But it’s a solved problem in my blendfile, can get the four corner of a face by indexing face corners
Edit : your solution if pretty cool though !
First you need to make sure the walls are subdivided into an uneven amount of segments.
Then you can do the modulo thing with the faces, that you were already doing. Though that turned out to be much more tricky than I anticipated, because I didn’t find a straight forward way to get the edges in a nice deterministic order, right away…
Fortunately the face order of the extruded mesh seems to be predictable and stable.
I indicated my additions to your file from earlier (the one with the broken normals) with a turquoise frame. Maybe you can work that into your setup somehow:
With a bit of luck there will be someone simplifying that a bit more!
Holy cow thank you so much for having sorted out.
I better understand the process now.
Clearly my modulo was lacking a bit of logic before and after to be efficient.
I was able to reproduce it and implement it inside the current normal flipped node tree.
Then I tried the complete new tree on another base mesh and I got wrong normal all along haha.
I tried to make some boolean math but I can’t get the last edge island flipped. It’s either one island flipped or all the other flipped. But can’t “addition” them to have them all pointing in a direction.
@zeroskilz already provided the necessary information for a general solution, with some inside what is going on:
My hacky first solution flipped only the last face of the row, because i did not really know what was going on, just observed the last face flipping in your first example(I think because as you stated because of the length of the last splitted curve).
Wonder if the the normal only gets lost on the last island or if that is just mere chance.
Actually, implementing the correct face distribution flipped back the last face. So now on the original model on which I was working the last face is wrong.
So it definitely is linked to the resample count new data. I guess.
Yes it is … one solution (given that only the normals of the last spline island are regulary lost) would be to determine in how many segments the last spline gets resampled and flip that many faces.
It was a bit tricky, because i had to move the merge by distance into the floor/ground nodegroups after the flipping the faces. Otherwise the pre split captured normals would have been corrupted on the side faces of an spline island. Left the roof for You to fix.
Also changed the edge angle for the corner instances to unsigned because some faces where lost with the signed one.
Also added the possibility to add 10 unique random floors on demand.
Edit: And integrated @lone_noel 's windows selection method.
Wow that’s clever.
Using the normal captured from the curve to mesh. I didn’t thought about that.
Thank you very much!!
I’ll integrate the workflow in the tree later in the day. It’s pretty unbelievable what you guys can overcome so quickly.
After integrating the solution I’ll continue to add features to the tree. Entrance for the building (obvious haha) Shops at ground level and more important I think about a proximity building to have blank faces.
I saw a lot of works using empties to trigger proximity reaction. So it seems doable on my side.
)
