Maybe this is a floating point thing:

@Henrik Dick (weasel) I guess this comes down to preference. We could remove Range and Variance, but honestly they don't really bother me.

• merge master

• median, min and max now via std::sort

• fixed float3 statistics

• WIP refactoring to use stl parallel algorithms

Closing this revision, and abandoning the idea of a multispan or of a custom iterator that loops over multiple spans.

• some testing

From the description it seems like it's planned that the extrusion part will be contained in this node, right?

Current plan: keep MultiSpan, it's job is to provide a .begin() and .end() for the iterator. Then use algorithms that work with iterators, see the sum test for an example with std::accumulate().

• Sum test that shows this is not how inheritance works in c++
• removed sum() and calculate sum with std::accumulate() instead

As Jacques pointed out, what I explained in my previous comment is not possible in C++.

The overhead for each element access is not ideal, but when you need this functionality, the alternative is usually copying all the data in all the spans.

• a bit of cleanup

Addressed the small comments. I'll look into a solution for the unnecessary copying in compute_median.

• cleanup

Pass spans by value and removed std::vector.

• Pass Spans by value and replaced std::vector with Vector and MutableSpan

Removed CombinedSpan and I addressed most of the other comments. I've done some quick tests and everything still seems to work, but I'll do some more thorough tests later.

• removed unused includes

• removed CombinedSpan and replaced with function that take Span<Span<>>

• WIP refactoring

Yeah I wasn't really sure what category to put this one in. My thinking was: all the nodes in the Mesh category really alter the mesh topology, this node just adds an attribute so I thought it fitted there better.

Ah yes indeed, forgot about that. Just tried it with the rng outside the loop and it causes the points to shift around while weight painting.

• reverted previous change and instead just changed default userpref

Archiving this because it is not actively being investigated.

Another solution would be to create a single RandomNumberGenerator rng(seed); outside the loop over looptris, instead of creating a new rng for each looptri.

The problem is this line in sample_mesh_surface():

const int looptri_seed = BLI_hash_int(looptri_index + seed);

I'm not sure whether this is a bug. I believe the Utilities Map Range node uses the code from node_shader_map_range.cc. In that file you can find this:

• fix bug that caused saved nodes to load as Undefined

• vector median and removed size_()

• Merge branch 'master' into geometry-nodes-attribute-statistics
• removed operation dropdown and exposed all stats as sockets instead

• added support for pointcloud and volume

• WIP refactoring to include pointcloud and volume

• removed prints

• merge master

This functionality might be covered by this desgin task by @Hans Goudey (HooglyBoogly): Mesh Smooth Node https://developer.blender.org/T86903. Or is this something different?

As I understand it:

• Made a few variables const and removed comment about get_result_domain()

• Merge branch 'master' into geometry-nodes-attribute-map-range

Ah yes of course, thanks! Should have checked the docs :p

@Jacques Lucke (JacquesLucke) no that wasn't intented. I've updated the patch with a fix. The problem was that I changed the CLAMP() to std::clamp() last minute and didn't bother to test thoroughly. Apparently std::clamp() doesn't work.

• one more std::clamp changed to CLAMP

• changed std::clamp back to CLAMP because it doesn't work

• merge master
• add node back to menu (removed by accident with merge) and set default vectors to (1,1,1) instead of (1,0,0)

• std::clamp instead of CLAMP

• simplified smoothstep and smootherstep

• merge master and new way to choose result domain

• Fixed conversion issue

• Added result field and clamp socket, however there's still a bug with float to float3 conversion

• merge master
• More documentation and removed 0.00001f because the old stepped function is used again.

I think this is the intended behavior (with Attribute Vector Math):

I believe the problem is that the Attribute Math node is trying to save it's result, a float attribute, into the position attribute. However position always has to be a vector attribute, so it gives this error. Should be fixed by used Attribute Vector Math instead.

feedback by Hans an example with point cloud

added examples

change Location to Position

• merge master

Charlie and Simon I agree with your comments about the stepped function so I've reverted it back to floor(x * (steps + 1)) / steps. It only behaves somewhat "weird" when input values are outside the [From Min, From Max] range and when clamping is disabled, so it's not that big of a deal and definitely not worth breaking consistency for.

• reverted stepped function based on feedback

Not yet, I guess we should revert to original stepped function for consistency, even though it's not perfect for attribute values outside of the [0, 1] range when clamping is disabled.