Try doing the vector math with another attribute, then converting it back to the UV layer afterwards. Basically you want to avoid writing into the UVMap
attribute with anything other than a 2D vector, and the vector math node creates a 2D vector.
@lone_noel ā¦ ah my bad, I used UV Map node instead of Attribute node(with UVMap set), that makes it to work in Cycles as you suggested, thanks.
Hello
Where is the use count feature in geonode?
Today i had to scatter a collection containing a lot of objects, and i kind of miss this feature. IT was really easy to control the percentage of instance scattered.
i saw a design drawing made either made by Dalai or Pablo back in the days when they were working on the point instance node
Couldnāt find it anywhere,
The idea got abandoned?
Big kudos to the geometry nodes team for their outstanding effort. I understand weāve reached something of a milestone ? Anyway, Iāve never seen such open development beforeā¦ users trying stuff all the time, giving no respite, devs doing an ungodly amount of work and taking feedback like starsā¦ that was fun ! I hope it continues. I havenāt been testing out the new stuff this past two weeks due to lack of time, hopefully thatāll change soon.
I read the post-mortem, itās always a great idea to do one.
For the records, the post-mortem @Hadriscus mentioned is here: https://wiki.blender.org/wiki/Projects/Geometry_Nodes/Sprint12
This is just a feature request really, instancing geometry directly is planned, but it is not trivial to implement.
At any point in a node tree a piece of geometry could be procedurally defined, then how do you pick whatās going to become the instanciated geometry ?
Well, it would take the geometry at the moment you plug it into the instance node, save that in the āInstancesā component of the instancer geometry set, then you have a really performant way to have duplicates of the geometry.
Then later on it can be made real as necessary.
I might have imagined somethingā¦ obviously either the geometry varies in time, or it does across copies of itself, but at any given moment and at the end of a given node, it is what it is.
This maybe a different topic to instances, but does this encompass different values per instance. Eg instancing flowers on a bush where each instanced flower has a different seed value to arrange the petals.
Not really I donāt think, unless you want to make the instances real. Iād imagine some of the cases where you want a per-instance value would fall under ācollection nodes.ā Though Iām still figuring out how to best make the distinction myself, so Iām not sure.
I showed parallel progression but the image was removed. Here is a mockup of how attributes could work better.
Current Design
Proposed Design
The proposed design seems to be in essence the proposed Attribute Processor Group. What I am proposing is that there should be a way to loop new attributes linked to a specific geometry back in main stack without duplicating the actual geometry. Sure, if additional groups are needed, they can be created, yet, if they must always be needed, it would be hard to understand the node flow.
Useful nodes to have
Edge instance node with tangent direction and Face instance node with tangent direction nodes would be needed to get these buildings to follow the orientation of the street edges.
Cars, benches, traffic lights, and potentially people could all be scattered if there is a way to control the direction.
Further on
This is just some food for thought to think about
Wondering if the instance could have indpendent modifier stack without a big performance hit? Reason being is that at the moment all the buildings are scaled based on the attractor distance. Yet, itās a little more complicated with buildings as they donāt scale up in height but instead should have additional floors.
A system that allows lightweight instanced performance yet allows to change the array number of individual instances, along with tangent based nodes would make creating cities super intuitive.
I showed parallel progression but the image was removed. Here is a mockup of how attributes could work better.
The parallel progression example has been thought over multiple times already. I think it was actually in the original geometry nodes ui mockup before. It always breaks down when different topology comes into play.
What I am proposing is that there should be a way to loop new attributes linked to a specific geometry back in main stack without duplicating the actual geometry.
Not quite sure what you mean by this or how it could be useful. Attributes are topology dependent. Can you elaborate?
Edge instance node with tangent direction and Face instance node with tangent direction nodes would be needed to get these buildings to follow the orientation of the street edges.
Would be nice to have curve based point distributes for following lines. I believe I saw someone wanting to work on a points from face center as well. You should be able to construct rotation from tangents there.
Wondering if the instance could have indpendent modifier stack without a big performance hit? [ā¦] buildings as they donāt scale up in height but instead should have additional floors.
At that point you no longer have instances but new geometry. You might be able to solve this by breaking down the buildings into instancing floors based on lines of points or even in the future when the project grows instance their facades based on point frames in order to give each building that needs extra detail itās own look. I believe this is the current preferred approach for doing procedural buildings nowadays but geo nodes might be a little far off from that for now.
Probably recursive iteration over the whole topology. Any new geometry created during would be included in the next iteration. Something-something along those lines Iād guess.
Iām not sure you are thinking about the same thing but that would turn into quite a mess. I would rather have explicit loops over ranges and domains to do this kind of thing.
Anyone have any idea on how we can rotate an attribute ? or simply rotate a vector?
Coming from Houdini, this kinds of little detaisl are a bit awkward in geonode
Data transfer already works on āattributesā in a legacy sense. Can you clarify?
I simply need to access the points position from another scatter objects!
but i canāt !
because blender only give me the position of each vertices of the applied instance geometry, i canāt work with thisā¦ thereās litterally billions of verticesā¦ using them in an attr proximity node will just freeze blender to death
Ah yes, I know what you mean now. The way instances are just turned into real geometry whenever brought in is a bit of a problem. I now just realized there isnāt really a way to split the output of a geometry node graph either. But yes, I get what you mean.
I have the same problem
thereās a plan to have a convert domain node i heard