Utilities for fast sqrt, inverse square root and smootherstep

[legends2k]

Theses functions might be good additions to util.h

• Smootherstep (6x⁵ - 15x⁴ + 10x³)
• Fast square root; related discussion in GameDev.net
• Fast inverse square root

[recp]

@legends2k thanks for suggesting new features 🤗 Yes we can add these after the critical PR (https://github.com/recp/cglm/pull/198)

[awsdert]

Jumping on the wagon here, couple more utility functions that I was looking for but didn't find, here's what they should roughly look like:

long double glm_squared_length( long double x, long double y, long double z )
{
    return (x * x) + (y * y) + (z * z);
}

long double sqrt_of_vec3_length( vec3s vec )
{
    return sqrtl( glm_squared_length( vec.x, vec.y, vec.z ) );
}

I'm re-writing the corange project to learn how to use opengl and it had a couple of functions similar to these (although badly named, these are the re-named versions after I re-wrote them). If something like these already exists please let me know, would rather keep out all the excess code from what I wish to be a small piece of the original so that I (and others) can understand how to to use the IDs given by glGenVertexArrays & glGenBuffers together and with both buffers for the vertices and indices. For now I've been copy-editing code from the cengine* files, better to start with full core then rip out piece by piece until I get it down to just enough for a few independent triangles with some textures and movement and rotation. BTW, did I mention how I hate unintuitive APIs like OpenGL?

[legends2k]

@awsdert Both glm_squared_length and sqrt_of_vec3_length are already present as: glm_vec3_norm2 and glm_vec3_norm. As for your hate on APIs like OpenGL, I'd suggest looking at wrapper libraries like sokol.

[awsdert]

Well those are definitely not intuitive names, I associated those with normalization (did think it odd that there was multiple with seemingly the same purpose)

Edit: I'd like to suggest some new/alternative names for those, glm_vec_squared, glm_vec_sqrt, I didn't see any functions named the same way so there shouldn't be any conflicts

[legends2k]

Looking at the implementation helps. Also norm is the general term used in place of length in math literature/libraries; length commonly refers to Euclidean distance/norm.

[awsdert]

Looking at the implementation helps. Also norm is the general term used in place of length in math literature/libraries; length commonly refers to Euclidean distance/norm.

Can't say I'm agree with that terminology decision of theirs, it's as if they were deliberately making gfx math harder to understand than it needs to be

[recp]

squared length = length ^ 2 // pow(length, 2)

// or 
squared norm   = norm  ^ 2  // norm2

So I was thougt that using 2 suffix as glm_vec3_norm2() could be a good name (I like short names, sorry for that). We can add more readable alias if it is necessary

---

There are a few norm functions:

float glm_vec3_norm(vec3 v);     // Also called L2 norm, euclidean norm (magnitude)
float glm_vec3_norm_one(vec3 v); // Also known as Manhattan Distance or Taxicab norm 
float glm_vec3_norm_inf(vec3 v); // Also known as Maximum norm. 

As I said before we can add [inline] alias for norm/length if it is necessary to make it more readable...

[legends2k]

@recp I think norm is a commonly used name for length in a lot of math libraries (e.g. GLM has a norm.hpp). I don't find anything wrong with the current names. Part of being a good programmer is to be mindful in looking for functions/APIs a library/framework/platform provides; reading documentation and headers is part of the work.

[awsdert]

I understand the desire for short names since I used to do it a lot back when I 1st started programming but found when I came back to old code I hadn't maintained in a while (nor documented for that matter) I didn't have a clue what was doing what until I went to the function implementation, that's poor design and I have since been trying to kick the habit by only using short names when the name can be intuitively connected to it's related task, for example instead of engine I can write core, instead of shader I can write task, instead of program I can write proc, instead of array I can write list, instead of memory I can write data, it's all about making sure the names can be intuitively connected, not about needing to hunt through documentation to get the gist of what it's supposed to do but only for the finer details like what it considers to be valid, whether it uses a copy of the data or the originals, things like that are what documentation should be needed for, not "what is the purpose of this function?"

[recp]

I think norm and norm2 (norm ^ 2) are not bad, an alias like glm_vec2|3|4_length() could be used too.

[awsdert]

Try to think about how you would've viewed it when you were still new to this sorta thing, would you have still thought of them as good names? Of course not because having seemingly multiple normalisation functions would confuse you as it did me, at least have some defines that just map to the name like this:

#define glm_vec3_squared_length glm_vec3_norm2
#define glm_vec3_sqrt_of_length glm_vec3_norm

Then newbs like myself can search for those names and see the what the purpose of the official functions is at a glance, on a side note I did not intend those 2 defines to line up so perfectly, I do love it when that happens

[recp]

I think it would better to have inline func instead of macros. Because we could call the fuction like

glm_vec3_length((vec3){x, y, z});

Also glm_vec3_sqrt_of_length is weird to me since it is just length.

2 suffix is also used in glm_vec3_distance() -> glm_vec3_distance2() which is alternative name convention I think.

But we can create inline functions or macros, yes.

[legends2k]

it's all about making sure the names can be intuitively connected

Intuition comes with some exposure to the subject matter. Most math and 3d programmers I've spoken to knew about norm and their various types e.g. Manhattan/Taxicab/l1 norm, Euclidean/l2 norm, etc. @awsdert

[awsdert]

I think it would better to have inline func instead of macros. Because we could call the fuction like

glm_vec3_length((vec3){x, y, z});

Also glm_vec3_sqrt_of_length is weird to me since it is just length.

2 suffix is also used in glm_vec3_distance() -> glm_vec3_distance2() which is alternative name convention I think.

But we can create inline functions or macros, yes.

The defines I gave can still be used as calls, or rather they MUST be used as calls, when compiled the compiler only sees the norm/norm2 so it will expect a call, do agree with length being a weird name for the context though, I only gave that name as it was used in the code I was converting

[awsdert]

it's all about making sure the names can be intuitively connected

Intuition comes with some exposure to the subject matter. Most math and 3d programmers I've spoken to knew about norm and their various types e.g. Manhattan/Taxicab/l1 norm, Euclidean/l2 norm, etc. @awsdert

That's taught intuition, not natural intuition, if we want more programmers to learn then we first need to provide names they can intuitively understand and find, then show what names they connect to and why they connect to them instead of being stand alone names, the why is outside the scope of the project but providing the natural names should be a given, even if they're enclosed in an #ifdef so that people that have learnt the taught names can save space in their binaries by just undefining the names and switching them with the official names

[legends2k]

@awsdert Well... 3D mathematics and "natural" intuition!? I thought everything about 3D mathematics is learned. I rest my case :)

[awsdert]

@awsdert Well... 3D mathematics and "natural" intuition!? I thought everything about 3D mathematics is learned. I rest my case :)

If you're gonna use a technicality then I'll go one further, everything we know is taught to us at some point, our intuition no doubt stems from that, but someone still new to graphics functions (like myself) would appreciate more verbose names that explain what they're actually doing and ignore the technical names, we can learn those just by looking at the implementation which would call them, it's not about reimplemting the wheel, it's about providing names that are verbose enough that when we search for the related terms we can find those functions and follow them back to what they actually call/do