Did a quick walk over some of the header files -- I think this case would be the spot to add logic which restricts painting based on slope? Coupled with expanding the brush data definition here to include some slope-restricted-painting parameters? (and producing some editor UI stuff for end users)

(Confirming my understanding before attempting a PR)

Looking at the current issues in the 9.x and 1.0 roadmap, onlyhttps://github.com//issues/174 pops out to me as a coupled feature. Would GPU painting introduce breaking changes in _operate_map() potentially?

Did a quick walk over some of the header files -- I think this case would be the spot to add logic which restricts painting based on slope?

Painting based on slope can be applied to painting texture, color, wetness, autoshader, navigation.

So the gdscript tool_settings UI should have a slope setting that is enabled for all of those tools. That setting is added to brush data so _operate_map can access it and set it up at the beginning of the function.

This code you've highlighted is the controlmap, which is the correct place to filter based on slope for painting texture, autoshader, and navigation.
It also needs to be added to the colormap section for color and wetness.

Do consider how the autoshader handles slope. If there's a better way to calculate slope, that's fine, we can change it, I just want both settings to match so one it to match, so you can take the value from one and stick it in the other and it blends the same.

get_normal() will help you.

I hope looking up all of those heights won't slow it down, but it probably will, considering how much slower the smooth brush is. It may not be feasible to implement this until GPU painting works. So if it is any slower, then at the least, have a checkbox to enable/disable slope painting.

Coupled with expanding the brush data definition

Implement it without considering GPU painting for now. There's much more testing and planning to do before we start on that. We will refactor a lot of code to get it working.

Thanks for the understanding confirmation, broader requirements and suggestions.

I hope looking up all of those heights won't slow it down, but it probably will, considering how much slower the smooth brush is. It may not be feasible to implement this until GPU painting works. So if it is any slower, then at the least, have a checkbox to enable/disable slope painting.

The speed issues/limitations of the smoothing brush can probably be mitigated/side stepped a bit for texture painting because the values aren't being changed. No promises on speed, but definitely will make it a toggle/checkbox.

Do consider how the autoshader handles slope.

I've looked through the auto_shader, dual_shader and main shader code to get a tentative understanding of how the auto shader handles slope in the context of the shader overall. the //INSERT: AUTO_SHADER_TEXTURE_ID block seems to be using bool auto_shader for branchless code, specifically to lookup the textures and define a weight/strength of the blending per vertex.

I'm not super comfortable with bitwise operations and don't fully understand what control is, other than inferring it must be where the textures and hole data is stored... and I think this code is casting the r value of control to bool, int and float to create branchless code.

in out_mat.blend I have a question about the second parameter of the dot() call inside the clamp() call:

dot(vec3(0., 1., 0.), normal * auto_slope*2. - (auto_slope*2.-1.))

normal is a vec3 and auto_slope is a float, so multiplying them is perfectly regular... but then we're subtracting a float from a vec3 with - (auto_slope*2.-1.)? And that's a thing in gdshaders? or am I missing something?

I'm sorry I missed this message. I'll answer these questions for posterity.

The speed issues/limitations of the smoothing brush can probably be mitigated/side stepped a bit for texture painting because the values aren't being changed.

Smooth is slow because it's doing 4-5 height lookups and averages them.
A slope brush will use get_normal which does 3-4 lookups.

I'm not super comfortable with bitwise operations and don't fully understand what control is,

Control is a uint that stores a bitfield defined here https://terrain3d.readthedocs.io/en/latest/docs/controlmap_format.html

normal is a vec3 and auto_slope is a float, so multiplying them is perfectly regular... but then we're subtracting a float from a vec3 with - (auto_slope * 2.-1.)?

Component-wise operations between scalars and vectors are applied to all elements of the vector. That's a normal operation in glsl. You can see it with ALBEDO = vec3(1., 1., 1.) - .9;

There is a beginning implementation in #456.