I think this and many other functions can be bundled in a Math or a Noise class
100% viable, but should account for other similar functions

I think this and many other functions can be bundled in a Math or a Noise class 100% viable, but should account for other similar functions

Oh, absolutely, and GDScript already has functions like sin(), cos(), and tan(), and they could be included alongside those.

Please refrain using ALL CAPS in issue titles.

There's a S-shaped curve preset in Curve resource (not sigmoid).
This would work for value mapping.

There's a S-shaped curve preset in Curve resource (not sigmoid). This would work for value mapping.

Bézier curve is not a Sigmoid function, it can looks like that, but is not calculated that way.
Adding a Sigmoid function can be useful, but there are sign() function already, may need to consider the possibilities of confusion

but there are sign() function already, may need to consider the possibilities of confusion

Well, maybe the builtin function could be named sigmoid() instead of sig().

There's a S-shaped curve preset in Curve resource (not sigmoid). This would work for value mapping.

Bezier curves do not approach their bounds asymptotically, whereas sigmoid functions do. This means that the higher the value you plug into a sigmoid, the closer it reaches the bound, but without touching -- for the bezier curve, it will reach that limit. For something like weapon sway, that will create an effect where the model's movement appears to hit a wall, whereas a sigmoid function will appear to meet greater and greater resistance.

makes sense, sort of like an ease-in and ease-out.
as for the curve, value mappings are inherently slower due to the cross point lookup, it can work but a raw math is superior

Does this have a related Godot proposal issue?

Does this have a related Godot proposal issue?

No results for "sigmoid" in issues or PRs, open or closed. Seems like fair game for us

I kinda would like this to be thrown upstream first, but that would depend on what @8bitprodigy wants, or in the case of Redot-Engine/redot-engine#148 what @NickUfer also wants, if they don't want it upstream then we'll need to merge it in a way to minimize merge conflicts with Godot.

I kinda would like this to be thrown upstream first, but that would depend on what @8bitprodigy wants, or in the case of Redot-Engine/redot-engine#148 what @NickUfer also wants, if they don't want it upstream then we'll need to merge it in a way to minimize merge conflicts with Godot.

Whatever works for y'all.

I kinda would like this to be thrown upstream first, but that would depend on what @8bitprodigy wants, or in the case of Redot-Engine/redot-engine#148 what @NickUfer also wants, if they don't want it upstream then we'll need to merge it in a way to minimize merge conflicts with Godot.

Whatever works for y'all.

I posted on the PR for this, we revised this policy as a team due to a bunch of concerns. I need to check on the PR, we were just waiting on some small changes and then a squash afterwards iirc

I posted on the PR for this, we revised this policy as a team due to a bunch of concerns. I need to check on the PR, we were just waiting on some small changes and then a squash afterwards iirc

He'll yeha!