I feel I should resign from this one and put it up for grabs (not sure how) I am not keeping up with things. A lot has moved ahead and I feel as though this task can be better tackled with a more clear design from a core team.

Lost track of blender development on geo nodes. It seems it is changing drastically and I can no-longer keep up.

Amazing!!! I feel as though the overlay shader needs an option for tile recursions to better show smaller distortions. Maybe something like this?

Holy mother of callstack batman!

handle_position_a -- better name?
handle_position_b -- better name?

Moving back to community tasks as I moved it after a meeting to be wrapped up for 2.93 but due to technical issues and the solution feeling incomplete this was not done to avoid a rushed product. I feel like shifting sands around the codebase and bigger priorities around geometry nodes have pushed this back a bit. I would like to return to this when more decisions around volume modeling are made and it fits in more with ongoing design tasks.

Your GPU is quite old and appears to be significantly out of date. The last driver update released for your card appears to be version 391.35 (released on Tue Mar 27, 2018) while you are using 382.05 which is significantly older. Try updating your graphics driver and seeing if that fixes your issue. (while I was gathering info someone else answered)

In T86907#1145886, @Sergey (randum) wrote:

Was other alternatives considered to boolean selection? It seems to me that the approach does not cover all use cases. For example what if I want to find bounding boxes of all separate from each other mesh elements (islands). Now the node can only find bounding box of entire mesh. With boolean mask it will be able to find bounding box for only part of selected mesh. How should the solution look?

In T73360#1151872, @Paul Kotelevets (1D_Inc) wrote:

In T73360#1107270, @Adam Friesen (ace_dragon) wrote:

A.....desk is only one consumer-friendly license overhaul awa [...]

I am not sure it is a problem.
Since Blender was redesigned to industry sta [...]

In D10506#278218, @Kenzie (kenziemac130) wrote:

Thank you soo much for everyone's feedback and continued work in the surrounding areas! Things have been difficult and demotivating recently but I would like to return to this patch after D10906 lands for BKE_volume_grid_shallow_transform. Thanks again.

In D11019#281558, @Howard Trickey (howardt) wrote:

I originally thought I would use the opportunity of this new exporter to fix those bugs. But then figured it would be better to first have a release that matched as close as possible the old behavior, so that users wouldn't complain, and then follow up with functionality altering bug fixes. I'm interested in Sybren's thoughts. I don't have a super strong opinion.

Looks promising so far! A few thoughts:

In D10905#279693, @Sergey (randum) wrote:

In Sverchok there is one node which can generate all util information about mesh elements.

I'm not sure I'm a fan of how internally the mirror_mesh function takes a normal input yet the node exposes a rotation. In my opinion rotations should only be used where a unit vector does not provide enough information to an operation, this is not the case here. I can get how Euler might be more friendly to people hand tweaking values it also adds an unnecessary step for people working with vector math who have to convert it to Euler only for it to be converted back internally. Maybe gathering more community feedback could be helpful here.

Thank you soo much for everyone's feedback and continued work in the surrounding areas! Things have been difficult and demotivating recently but I would like to return to this patch after D10906 lands for BKE_volume_grid_shallow_transform. Thanks again.

In D10506#277350, @Simon Thommes (simonthommes) wrote:

You've done a great job of bringing the patch this far and I think it would be great if you could bring it all the way into master as well. But, of course, you're not obligated to do that and I can understand that when there are regularly more requests made, that it can just be too much.

Since there is some discussion about the naming I will settle with the following:

Just chatted about this with Hans, Jacques and Pablo and there was a consensus that we should probably rename the Grid attribute to Density.

In D10506#276878, @Simon Thommes (simonthommes) wrote:

I forgot to mention one thing:
The default spacing of (0.3,0.3,0.3) seems a bit arbitrary to me. I would just put it at (1.0,1.0,1.0) that is equivalent to the default density of 1 and also means less points by default which is good when dealing with large volumes.

Would it be possible to generalize this to other attributes than position? I could see users wanting to smooth things like uv's and normals/direction vectors as well. I'm wondering if this might be a good place to do an attribute smooth/blur.

In T86499#1138993, @Simon Thommes (simonthommes) wrote:

Actually... maybe the outliner should be more prominent, as we support linking collections/objects.
So maybe the same proportions as Layout would be good here:

In T86499#1138695, @Jesse Yurkovich (deadpin) wrote:

With what little geometry nodes stuff I've done so far, I end up in 1 of the 2 configurations below.

The gist is that you need a lot more horizontal space for the spreadsheet compared to vertical. I can tell how my attributes are behaving with only a small handful of rows, so seeing 60+ rows isn't typically necessary. Also, due to the horizontal graphs today, I tend to use as wide as possible graph spaces (or I switch to vertical if the nodes are too tall and/or there's too many attributes to fit in spreadsheet)

[...]

In T86563#1137392, @Ankit Meel (ankitm) wrote:

Couldn't redo on macOS, 99dabc156ac4e843411f9cad71841bc4fb783295.
If D10506 has an issue, guess we'll investigate it when that patch lands. Which branch is that patch based on ?

In T86907#1137459, @Hans Goudey (HooglyBoogly) wrote:

In T86907#1137454, @Erindale (Erindale) wrote:

How does a selection differ from any other Boolean attribute?

A selection is just a name for a boolean attribute. It could potentially be stored differently, but it's used like a boolean attribute anyway, and that's what matters.

In D9969#275650, @Fabian Schempp (fabian_schempp) wrote:

• Takes a single vector which is the position of the mirrored element. Mirror plane will be halfway between origin and position.

In T86819#1136692, @Dalai Felinto (dfelinto) wrote:

@Hans Goudey (HooglyBoogly) considering that we use Vertices for every other primitive (and should use for line as well) I think it is ok to use Vertices X/Y for consistency

In T86839#1135871, @Keavon Chambers (keavon) wrote:

The Array modifier is probably the most common modifier used in Blender. Even though it's a duplicate of functionality that is possible already in the geometry node graph, a standalone Array node should absolutely exist for convenience and clarity of understanding to people transitioning to geometry nodes. It's generally good to avoid redundancy but redundancy is helpful in some circumstances such as here. It definitely should not be out of scope for conversion from a modifier to a node; instead, it's probably low-hanging fruit for easily completing.

I vote to keep it as lean as possible and focus on one arbitrary axis with bisection. I'm not sure how merging works in the mirror modifier but if it only merges vertices with the opposite axis then that should be part of the node as well rather than a separate node. Three of them can be chained together with some boiler plate to make the full modifier.

In T86583#1134810, @Charlie Jolly (charlie) wrote:

In T86583#1134241, @Hadrien Brissaud (hadrien) wrote:

I don't know, doesn't this seem more complicated than the problem it tries to solve ? Don't frames and reroutes already provide all the organizing functionality ? Is scrolling actually an issue ? Maybe a minimap could help in that regard ?

Remember that using this feature will be optional.

This isn't quite right, since theoretically a set_group can have multiple transforms (though we aren't using that ability yet).

It actually doesn't look like there is a need to store the grids and transforms in a temporary vector anyway. Also, take a look at the way the point distribute node does this. The way it's structured (storing an array of vectors (one for each instance) makes it relatively easy to parallelize the distribution for every instance.
[...]
Storing an array of vectors for the position isn't essential for the initial version of this node, I'd be fine if you didn't include that. But scattering for every transform in the array is important.

• Updated with suggestions

It appears it got reverted somehow... Don't know how that happened.

@Charlie Jolly (charlie) Those improvements would be very welcome, I see the minimap has already started. It just seems like this task is being designed in isolation from best practices of the existing organization tools. I would like to see some interesting results and insights come out of this prototype as well, it just seems the design needs to try to acknowledge where the other tools work and find out where it best fits in.

How and where is this any more effective at organization than properly utilizing the already existing solutions to graph organization?

In T86583#1131168, @Dalai Felinto (dfelinto) wrote:

I clarified the explanation above. Pages are local to the nodetrees. Portals are intended to connect sockets from a page to another page in the *same* nodetree. This was not clear before.

• Rebase

In T86583#1130914, @Simon Sommer (CreatorSiSo) wrote:

How would make this work would be by having in and output nodes that allow you to select a page to import/export stuff to:

And a higher level graph for linking the pages inside a object (you would have to set your in and outputs for the object in the in and out pages):

But I actuall think that this not a system that should be added in geometry nodes because group nodes just work fine for the time beeing, but rather something that we should add as a scene/object tree to connect several geometry node trees over different objects in a procedural way (the over all everything nodes tree).

I still have cautions about this concept and how having different parts of a node graph on different pages might be not helpful. Blender currently is in the right direction IMO to provide useful, organized node functionality between splitting functionality into managable layers with the modifier stack, to node groups, to the upcoming attribute processor design.

Removes voxel values to the default value?

In D10506#271978, @Hans Goudey (HooglyBoogly) wrote:

Almost there! I think it would be great to get this into 2.93.

Leaving this since master has progressed far ahead of this patch and the exporter is moving to C++. This code had unfinished business as the subsurface extension is not implemented to replace the troublesome transmission vs. subsurface hack and file paths with spaces don't raise warnings about compatibility issues.

In T86563#1129625, @Campbell Barton (campbellbarton) wrote:

This report is missing:

• Last version that worked.
• Exact steps to redo the error.
• A blend file (unless there are simple steps to redo this from the default startup).

These nodes will actually be incredibly important to geometry nodes as well once the attribute processor node and support for openvdb's sdfs come to blender. It would open up a whole new way of procedural modeling. I'm very glad to see this getting updates and am rather hopeful.

• Rebase

Investigated the issue with instance transforms. This code previously just uses VDB's "indexToWorld" call in order to convert voxel space coordinates to world space coordinates, to do this vdb must be aware of the transform. To solve this I apply the transform of the instances to the distributed points, It appears that non-instances always have an identity matrix transform which is nice because I can just rely on the VDB's transforms for them. I think I got it mostly working with the one caveat that since instances don't contribute to the VDB's "grid.voxelSize()" and messes up the spacing a bit on grid mode. Chasing it down the rabbit hole it appears to be stored in a Vec3d in openvdb::ScaleMap when the grid is initiated and I don't know how or if it would be possible to reconstruct spacing info and under what scenario we should since the only indicator would be the identity matrix from the "non-instance" on gather instances, which is still more than possible with actual instances.

• Fixed instance transforms

Nice work!!! I like how the cone is able to handle varying base and top sizes which is far more useful than the existing add cone operator.

(Edit: Upon further inspection of the mockup it seems the potential issue was already accounted for)

In T86391#1127702, @Hans Goudey (HooglyBoogly) wrote:

I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other.

I will hold off implementing grid / plane for a bit in case I hear a convincing argument for combining them though.

In T86457#1127555, @Wannes Malfait (Wannes) wrote:

Maybe it might be a good idea to have some sort of 'scope', where user-created attributes are deleted when they go out of scope. This could work well with something like T85655. Something so that temporary attributes don't get 'leaked' out of a node group for example (a checkbox to turn this on or off could be added).

In T86279#1126292, @Antonio Vazquez (antoniov) wrote:

My comment about API or for CVS was not whether or not it can be done currently, of course it can already be done in python.

Including a simple tabulated data import / export system, in CVS or JSON, could be very useful in countless cases and would not require any programming on the part of the user. If the user does not have to create their own exporter, that would add a standardization of this type of process that requires tabulated data, both at the I/O and visualization level.

Anyway, maybe this project is not the one for this idea, although IMHO it is a pity to miss this opportunity to do something really useful.

In T85898#1125167, @Charlie Jolly (charlie) wrote:

Just from a naming point of view, should it be called Volume Point Distribute.

I'll get more feedback on this. The intention was to break point distribute up into "Point Distribute Surface" and "Point Distribute Volume" I originally went with this because it read and was grouped better when adding the nodes in the menu.

My initial test was to use it like the existing Point Distribute node but it needs the Points to Volume to work.

I am aware of this, it requires an explicit volume definition in order to function (VDB) as described in the design notes. It isn't working on external volumetrics at the moment.

• Update use bke::geometry_set_gather_instances

I'm wondering what to do about the stability of points through time. The regular point distribute node tries to handle this to the best of it's ability but VDB's Point Scatter API does not handle this. With the grid distribution mode it should be rather stable for free (as long as the volume is using the "size" mode) and all you would have to do is hash the position to create an "id" attribute, the random distribution mode presents more of an issue.

Clang format

Made suggested changes

• Changed tooltip to use "the"
• Removed unused includes
• Made "PositionsVDBWrapper" private members consistent with style guide (couldn't get references to work without bugs yet)
• Replaced "typedef" with "using"
• Fixed caught typos
• Removed unwanted error when no volume component is found to avoid noise
• Replaced random "get_input" with "extract_input" (copy and paste error)
• Improved error messages based on suggestions
• Used "TIP_()" macro for translation of error messages
• Fixed double copy
• Using arcanist

Attempting to move to arc now.

Since I wasn't the clearest (probably even in my own mind) I was suggesting that since the different types of curve objects seem to share that functionality that there could be a way to break apart the curve types into how they are edited and how they are skinned. With how different (layers?) of edit types could be stacked in the curve data while how they generate geometry could be moved entirely into modifier space. This is since I have seen quite a few people in their workflows doing things like converting text objects into curves in order to achieve things like a neon tube effect when really what they are after is a different method of skinning but have to give up their preferred way of editing. But now that I think more about it that does introduce problems as well so this was probably just a false bit of connecting dots on my end.
However it does make sense that 2D curves should be their own "type" as well as they offer both changes in skinning as well as editing.