[Bf-blender-cvs] [838c4a97f1d] master: Geometry Nodes: new Volume Cube node
More information
D15198 Geometry Nodes: Volume Cube node (blender.org)
In short, this has a potential to be an extremely powerful tool, as you can create things that are otherwise difficult to do with traditional tools (like sponges and Swiss cheese). I have an image that contains a lot of cheese done with booleans, but it would’ve been much better if this node existed back then.
Woah, thanks for showing this, I had no idea it was possible without creating drivers or python scripts every time!
This sure makes a lot of things simpler!
can those be accessed in geonodes?
No. Would be nice to avoid storing them on each Vertex as @Charles_Weaver mentioned.
But this object level storing may be a better fit for the once planned collection nodes.
Looks like we could benefit from reading/writing per scenes/objects attributes 
Houdini can do that
Sadly, not at the moment, but it would be interesting to have for sure at some point !
I think it’s a bit beyond the scope of “geometry” in geometry nodes, but having these shortcuts would be awesome. At some point it would be great to be able to manipulate things on object level or mesh level in the same tree.
@Charles_Weaver ,
It’s very powerful but a bit of a work to manage. For materials, you add a material to an object then you need to create the custom props. I’ve made some scripts to automatically generate these properties based on the materials, and it allows to do basic management over these properties.
Something similar would be needed to have a good workflow being either in shader or GN.
The last thing I’d like to mention, is that you can set the Attribute Node to Instancer rather than Object, and then it will work on both objects and instanced collection. You add the custom props to the empty / instance collection, that is also super useful when you link collection from other files and want control over the materials, without breaking the links with overrides.
I am absolutely loving the new volume cube node in 3.3. It really smashes a lot of limitations we had before, and makes things like metaballs and shape blending possible.
It even makes remeshing semi-possible (to an extent):
It could use some smoothing, but the attribute blur node should take care of that.
As someone who hasn’t switched yet (a few crucial addons hadn’t been updated at release), could you show an example of the nodes? I’m curious how you’re using the raycast, and what it’s doing exactly. The result clearly speaks for itself, looks like a far better option for watertight voxel remeshes!
You can take the dot product of the ray direction, and the hit normal to find all voxels within a mesh. Keep in mind that you may need to do this multiple times with different directions and add them together, as it doesn’t always catch everything.
This proximity setup might be better for this purpose, as it lets you set a custom threshold, and looks smoother overall:
Also, I found it looks smoother when you use the size setting on the volume to mesh node. I’m not exactly sure why, but my guess is that there is some interpolation going on.
3 posts were split to a new topic: Make Distribute Points on Faces generate more evenly spaced points?
Especially now that we have a procedural UV unwrap node, I hope the edge attributes are generalized at some point, and we get a way to create and assign custom ones.
It would be awesome to access crease, seams, sharps, and bevel weight in geometry nodes, and create custom edge attributes.
For instance, if you were sculpting a model, and wanted to procedurally UV map multiple displacement textures, you could create a second seam attribute and use it instead.
Agreed…
Currently you can only access the crease value using named attributes:
I would also like to see that concept taken even further: To have any attribute type from any domain accessible, AND editable in the 3D viewport (by choosing a custom key-bind in the properties panel). Something like that would be needed to allow custom GN implementations of things like the Skin modifier.
Why “only”? Named attribute seems the best, most straightforward way to access any attributes. I mean, the fact we have some cherry picked hardcoded nodes for certain attributes is more of a consequence that the named attribute nodes were added so late.
In fact, it’s now sort of a mess. For example crease can only be accessed via the Named Attribute
Position can be accessed through both Named Attribute as well as a hardcoded node:
Embarrassingly enough, Normal can also be accessed via both Named Attribute and hardcoded node, but unlike Position, it doesn’t show in the list:
So now we have mess of 3 states:
I am replying just because I don’t like the wording
It sounds as if it was a bad thing and implies there should have been more way to access it. I think there should be exact opposite. The hardcoded nodes should be deprecated and removed, and Named Attribute should be THE way to access attributes. Then there would be no overlap, and no ambiguity.
In response to Zorro’s comment about Edge Attributes… crease is the only accessible Edge Attribute. Was using the word “only” to denote a singular.
Not the point I was making or a point I care to refute. I was merely suggesting a mechanism for binding Attributes to Viewport functionality - similar to how Alt-s affects Curve Radius and Ctrl-a[x|y] affects “skin size” for skin modifier.
Right, nevermind then.
