Honestly solvers just seem like they could be achieved with some sort of cache node that stores geometry and can retrieve the geometry results from a previous frame. Maybe this could be a special type of or use case of a loop.
2 Likes
I though about it more,
i think whatâs needed is some sort of adaptation of the data-transfer modifer but for attributes. An object info node on steroid.
Would that make sense?
1 Like
I think those are two different problems. On one hand weâre going to need a way to transfer generic, user-made attributes just like the data transfer modifier allows us to do with built-in attributes now (ie by proximity or projection), thatâs one thing. Since the code is âalready thereâ Iâd wager thisâll come sooner than later.
The second issue is : right now we canât reference an object at a given point in its modifier list. The thing is⊠this is exactly the problem nodes solve : the user is able to pull an arbitrary output socket all the way to another distant input and connect those, however far apart in the node tree they may be. Trying to come up with an equivalent solution for the modifier list would be total duplicate work. For this reason I donât see it happening. Rather, I see geometry nodes expanding and expanding until they cover all use cases we had of modifiers (and infinitely more), and the modifier list becomes mostly redundant.
2 Likes
Data transfer already works on âattributesâ in a legacy sense. Can you clarify?
Is it me or is there currently no way to point instance a primitive mesh node? I though I could do that, only to find out the point instanc node only accept an âobjetâ input, and primitive mesh node only has a âGeometryâ output. How should I do this? I donât want to add another cube just for another geometry nodes modifier, it loses the entire purpose for having a primitive mesh node. If there is no way to do that, is there any plan to make it possible? It should be possible, right?
1 Like
Eventually geometry should be instanceable within the node tree but for now youâll have to make a separate object and instance that. Not a perfect solution but it does let you keep things parametric for now
That sounds like it would be a long time⊠So currently no plan, but after who knows how long, there will be, is this what you mean?
I came across this problem, for example, I need to instance an icosphere on a line mesh created by node, I found out it is not going to work in one node tree, so what I ended up doing was to add a cube object and use geometry nodes on the cube, then connect the icosphere node to output so the cube becomes an icosphere.
But then I realized, there is no point of using primitve mesh node at all, not at all, I could have added an icosphere object and use it as Object Info, exactly what I did before the primitive mesh nodes. As for the line mesh, I could have used a single vertex and add an array modifier before Geometry Nodes.
This is what I meant when I said âit loses the entire purpose for having a primitive mesh nodeâ , there is really no reason to use it at all now in my use case.
Geometry nodes is still super young! If it was a different software we wouldnât even be playing with it this early in development.
If you just wanted to have a single icosphere and not need any controls for changing it later then yes, itâs worth just adding a ârealâ object as it doesnât need to be analysed each time the tree updates. If youâre doing something more complex like instancing a parametric fence or wall or trees etc then you would want those as a separate objects to keep them live. Obviously it would be a more optimal solution if we could work entirely within a single graph and that will come in time!
You can already do some really interesting and complex things just with geometry nodes though:
6 Likes
Ture. I guess we have to wait.
Also your image gave me inspiration to solve another of my problems, thanks
1 Like
I was wondering if I could manipulate position Z with the A attribute?
The A attribute is just pos Z > 0 and now I want to move the top face.
This would basically give me the freedom to model a cube lol
1 Like
Your > operation seems to be a bit off. 1 and 6 seem to be out. However the method would just be Attribute Mix node set to Add, A attribute as your factor, position first, vector for how you want to move the parts second and result is position
Is getting attributes on points, that are being instanced, onto the object they are instancing (so you can access them with the attribute node in the shader editor) something that it planned for the near future?
Yes you can already !!
2 Likes
Unfortunately this is not what Iâm looking for. Iâve got a grid mesh and using geometry nodes Iâm instancing some cube object on each vertex. I want to add attributes to the points on the grid mesh and use the attributes in the shader of the objects I instanced
Maybe this could help.
No, this is using the attributes on the object that is instancing, not the object being instanced.
I would like to set some attributes on the grid and each rhombus gets the attributes that were on the point that it is being instanced from
1 Like
I donât think âattribute transferâ is in yet. The only attribute thatâs currently passed down from instancer to instance is normal, and even thatâs happening automatically in the point instance node.
3 Likes
Guys, how I can manipulate individual duplicates in Geo nodes?
If I applying the Geo modifier all objects disappears, if I adding one more modifier and applying it to mesh objects loses its materials.
If you want to make the instanced object into real individual meshes then you can Apply > Make Instances Real:
But be careful because theyâre all still using the same datablock so if you edit one of the meshes they will all change together. If you want them to be properly individual, you need to also set as Single User. You can do this to all of them at once if you keep them all selected.
4 Likes
Thatâs awesome! Thanks, man!