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 explicit volume descriptions 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 node it should be rather stable for free and all you would have to do is hash the position to create an index, the random distribution mode presents more of a issue.

Clang format

• Fix merge issue
• Made suggested changes
• Fixes an untracked file

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 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.

Could it be possible to version all of the "Geometry" features of the curve over to the modifier stack so all that is left is explicitly related to defining the shape and base sampling of the curve? I remember when I changed some things about the curve to default to filled it had a knock-on-effect on text as well and I was a little surprised. The curve/surface/text object just feels kind of an odd duck since they can be mutated into each-other by changing the data-block and It kind of feels like the differences mainly come from how the curve data is edited or skinned.

Corrected diff

Just realized that this commit marks the point distribute file as deleted for some reason... That should not be happening. Somehow my git must have gotten pretty messed up. Ignore that, in the process of fixing this.

Removed -U1000 from git diff (seems to have created issues applying patch)

Removed Point Distribute Rename

Needs initial code review

Stress tested and fixed coordinate space issues. Fixed artifacts due to floating point precision.

At zero spot of course

In T85654#1121949, @Erindale (Erindale) wrote:

I agree with the implicit XYZ too. I think showing "Position X" would lead some people to try calling it as an attribute rather than knowing to separate the Position vector.

Duplicate

WIP build is available for people who want to try it out (it is not going to be the most up-to-date version however) https://blender.community/c/graphicall/nsbbbc/

Optimized grid distribution.

Planning on investigating optimizations for the grid distribute mode and possibly skip out the deep for-loop. It's not memory bound but it can get rather sluggish. That being said it took on billions of points surprisingly well in a little under a minute without it.

Random and Grid Distribution Working (grid needs optimization)

In T85655#1118629, @Hadrien Brissaud (hadrien) wrote:

With the introduction of this attribute processor, would attribute-specific nodes still be necessary ? (attribute color ramp, etc) Would they keep existing alongside the attribute processor ?

We are aware of this limitation. I believe it smooth shading was meant to be a separate node.

Initial user interface

"Random" point scattering is working.

In T85898#1118073, @Florian Kamenz (TimBrown) wrote:

So is this kind of the same distribution as in the old Particle System?

First bit of tangible progress: https://www.youtube.com/watch?v=EdOhC0yGfh4

Looking at the VDB documentation it should be relatively straight forward to just add the distribute functionality with the Point Scatter API with just a wrapper around the Point Cloud class. Then if there is any other VDB grids we sample those in parallel and add them as attributes.

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

By the way, we would want the renaming of the existing node in a separate commit / patch. Fine for now, but eventually it will need to be split.

It appears that the implementation of volume sampling in the legacy particle system produces quite broken and unstable results under random and especially jittered volume distributions.

Began working on Approach 2 D10506. Will keep this updated with more potential design issues, especially when it comes to the distribution method.

Fixed broken git diff

In T85898#1117314, @Hans Goudey (HooglyBoogly) wrote:

I prefer the second approach, sounds like the proper way to do it.

This design task could actually cover common algorithms for that case. I assume you're interested in implementing this?

Can this be extended to support bounding spheres as well?

How about the name "Attribute Processor"?

YEs while its safe for the news it is safe for here like you said. Some people watch news if they work late shift and like you said this fits there. All is good.

In T85720#1113869, @Leonardo (leonardos) wrote:

In T85720#1113854, @MacKenzie Strand (kenziemac130) wrote:

Hello! Can you isolate this issue to a simple test blend file you can upload with replicatable settings to help developers a bit more? It's a little difficult to just work on an image alone. Also no disrespect against your artwork but perhaps you can make the demo file more SFW? I'm not too bothered by it but I can imagine other developers who would work on this regression might have issues with their comfort level. Thank you!

Hello I assure my art-work is very safe for work I have put blur where its not safe to look. I have tried to replicate the issue with simple geometry but alas it is not very obvious. So here I have isolated the area of the mesh from my screenshot where the issue is most obvious and uploadet that files.

Hello! Can you isolate this issue to a simple test blend file you can upload with replicatable settings to help developers a bit more? It's a little difficult to just work on an image alone. Also no disrespect against your artwork but perhaps you can make the demo file more SFW? I'm not too bothered by it but I can imagine other developers who would work on this regression might have issues with their comfort level. Thank you!

Better handle flat surfaces (e.g. planes, circles), could ensure the camera points down the normal direction.

Default low poly, high poly human rigged characters: businessman, sportsman, children, blue colar, etc. (useful for many projects, should be easy to customize to make variantions)

In T84971#1106938, @Some User (someuser) wrote:

char string[1024];

but in this case, unicode characters are not supported. and we can't use this node as input for creating text mesh object 😢

P.S. also in other software, text input filed also used in some nodes to create points/edges/faces/etc, from they text representation of array coordinates/id/etc, i mean lenght of 1024 maybe to short?

In T85374#1107044, @Some User (someuser) wrote:

imho switch node need integer variable as index input (not binary thing)
and multiinput socket for:
Integer
Boolean
Vector
Color
String
Geometry
Object
Collection

Attribute Product does seem useful. I can definitely see some use cases for that in the future like deciding the amount of work to do when loops become a thing.