You probably are talking about one of your specific test.
Here, if I simply add a Point Instance node -> Object result is evaluated according to its local space.
Whole Collection result is evaluated according to world space. But that seems a logical behavior to me.
Alright, so here are my findings, if youâd to align your particles along the normal rotation from a separate object via an info node, thatâs how to do it :
edit: well it seem that in the end it didnât work in some places (specific axes). I guess using a separate object for scattering make things a lot more complicated due to local & global spaces issues? currently being talked on the blender chat by some devs
1 Like
Hello,
just downloaded 2.92 and made sort-of a spherical falloff:
Writing attributes is fantastic, well done guys. What Iâm missing is the ability to read attributes. Even though there are Map Range and Clamp nodes, it doesnât seem I am able to use them to do math with attributes, or am I mistaken? It seems the only way I can access attributes is with the special attributes nodes, which limits what we can do with the rest of the nodes.
If Iâm using the wrong place for this, please point me out to the right place.
2 Likes
It does seem like weâre going to need a version of each node but for attributes. Attribute map range⊠attribute clamp⊠etc. Itâs expected I think⊠since attributes are not separable from the geometry flow, we need the nodes to have geometry sockets. I guess they also work kind of differently because the math is done for every mesh element, whereas in the context of geometry, regular math nodes operate on single values, not arrays.
By the way nice test, very straightforward too !
1 Like
@HooglyBoogly are there any plans to be able to use a single vector component in the attribute fields? Being able to type position.x or scale.y into an attribute field in an attribute math node would be very helpful.
Am also curious about the attribute field input sockets. Is this intended to take in a string from a node? I am having trouble thinking of a real use for this (aside from maybe using a switch node to toggle between several attributes), but maybe you guys have something really cool up your sleeves 
6 Likes
A couple suggestions for exposed parameters that are created when you connect something to the Group Input node:
- It should be possible to control parameters for multiple objects at once from the modifier tab. Right now the same node group can affect multiple objects, but exposed parameters can only be adjusted for one object at a time. This is of course a useful feature, but there are many cases where you would want to control multiple objects at once (without going into the node editor). Iâm thinking there could be a checkbox next to each parameter to set whether it controls just one object or all objects that have that checkbox enabled.
This would basically give us linked modifiers but with added flexibility to choose which options should be instanced and for which objects.
- Multiple Group input nodes in a node tree. This is mainly to help with organizing the node tree. Right now even quite simple node trees for procedurally creating objects quickly become incomprehensible when you have multiple exposed parameters and dozens of connection lines going back to the Group Input node from all over the place. If Group Input node could be duplicated as an instance and placed close to the nodes that need to be connected it would help to reduce the visual clutter that too many connection lines create.
Number next to the node name shows that it has been linked multiple times, just as example.
I think this is covered by drivers⊠you can create a control object/rig that connects to these properties and sets them all at once. This way you can even animate it on and off. I agree with the multiple group input node, I think that works fine in Cycles already.
3 Likes
Hi Hadrien,
I suspect a version of each node would make things messier and more destructive, in the sense that setups created with normal nodes canât be re-used for attributes.
I think it would be ideal to treat them in a generic way, similar to materials. In the materials each node is applied to every pixel, in a similar way each node could be applied to every instance point. It would do math to the whole attribute list automatically and people can use the same node groups for single objects or for instances without distinction.
Yes, I know that it is possible to control multiple properties with drivers, but itâs a very tedious solution to a problem that shouldnât exist in the first place. Imagine if you had to control material properties for multiple objects by having to set up drivers every time. I have no idea why modifiers behave differently to every other datablock in blender and cannot be linked, but geometry nodes seems like a good opportunity to fix that.
1 Like
This is already possible, itâs just not working here, adding a separate solution just for the nodes modifier is not the way forward IMO.
You just need to hold âaltâ
2 Likes
To my mind this is where overrides should come into play: By default when you alt + D duplicate a object into a instanced duplicate the object data is linked and the property adjustments propagate to all instanced duplicates linking the same data.
If you right click a property you should be able to pick an option to make that one value a local override. I.e. that property on that object ignores the value from the root data that is instanced and override value is used instead. The value field changes color to indicate this and you can now change that value without affecting the other instances. Then if you want you can clear the overridden state from it and it returns to instancing and affecting the instance data.
@sergey Would something like that in theory be possible?
2 Likes
Then same solution could exist for geometry nodes : implement object ID.
@Orestiskon I agree. But whatâs the solution ?
Thatâs not exactly the same, because you first have to select all the objects that should have that property changed. If there are a lot of objects placed around the scene, that need to be linked, selecting them all every time would quickly become a drag on your workflow. Since modifier nodes are designed from the ground up to replace and improve current modifier system, why not improve this aspect and make working with many objects more user-friendly? Maybe exact solution could be what @megalomaniak suggested: all parameters are linked by default but you can add a local override through a right-click menu.
Not sure if I understand. How would object ID help in this case?
Controlling variations on individual objects sharing the same material is done through Object ID, as far as Iâm aware. Having ObjectID variable accessible through geometry nodes would make individual variation possible, even when the same objects share the same node modifier and the same input values.
I donât want to sound like the party crasher but what you suggest seems to go against the very idea of node groups. Theyâre supposed to be just like programming functions : black boxes with exposed parameters that you can modify independently, and thatâs the point. If you want shared properties, you can bundle/animate them from within the node group directly.
Ideally we should be able to use scene properties from inside material nodes tooâŠ
3 Likes
Is there an attribute remap node already? how do we do to remap nodes from rande X to range Y ? someone have any clue? iâm currently stuck in my project?
also, anyone know what is happening with instances with a scale of 0 ? are they still slowing down performances, or arenât drawn at all? in the old particle system instances with scale of 0 were still highly taxing to the viewport gpu performance
In the meantime, to remap to another range you can multiply then add
I think youâre right, you can only use the Attribute Vector Math node for such operations. However, clamping and range definition could still be done with that node, like in this (extended from your) example:
which results in something along the lines of this:
3 Likes
we need to get attr min/max values for that. seem that itâs not possible
edit:
maybe this? I donât get why thereâs two arg needed to find a minimal value. Iâll check the doc
*edit while working on this attr normalize/remapping within the current nodes, i found a some issues
thereâs feedback loops going on with the attr re-evaluating itâs own result
i donât think that any modifier should re-evaluate its own result at all. i hope it can be fixed?
may i tag some developpers @dfelinto @HooglyBoogly because in my opinion this is a serious issue
in the gif above, all i did was enter this IntProperty editing, i didnât actually change any values. But the modifier keep evaluating itâs own result
blend file demo here below
tested on
version: 2.92.0 Alpha, branch: master, commit date: 2021-01-12 20:03, hash: rB719bea0d6d06
1 Like
Hey thanks for the tip. Yes youâre right itâs technically possible, but a bit unintuitive to work with.
Is there a documentation on the available attributes we can read on?
Agreed, it is unintuitive. I hope that the fact that each Attribute has an exposed socket means that there will be a Attribute node that allows you to simply pick one of the existing ones out of an Enumeration or create a new one. So far I am not aware of any Attribute documentation.
1 Like