@dot_Sp0T Hmm?

And hello!

Yes, probably!

Having your entity stolen looks like a fkn nightmare...

Probably just a typo from someone with a similar email address. Good thing you have a second factor enabled to give you some peace of mind in the off chance it was more than that.

Ah. Even easier to typo a phone number then.

Good idea following up, just to be safe.

keep us updated :D

anyway whatcha all up to today?

Making my MFC class code reentrant.

\0/

aweseom!

smooth!

Edgy actually. Since they are only partially differentiable.

Possibly jumpy.

snarky!

What's the use of this, in real life?

Ah okay!

That's the kind of "use it or lose it" knowledge :P

Really? Shader stuff?

Cool!

@Vaillancourt I've used these for finding analytical formulas for integrating non-linear game state changes over a time step.

I think this answer involved a Jacobian, but I'll confess I'm a bit fuzzy on the exact derivation... gamedev.stackexchange.com/a/183913/39518

@DMGregory Interesting!

Mostly I just ask Wolfram for stuff like this, 'cause I've forgotten how to solve differential equations: gamedev.stackexchange.com/a/185803/39518

> "They" is me, and yes you can.

Also, that's too complicated math for what I can absorb at the moment :P

That and the Online Encyclopedia of Integer Sequences. Got some game system that needs very specific numbers, but you've only worked out a few cases so far? Plug in those numbers and see if it's a well-studied sequence with a generating formula you can use. :D

@DMGregory Not sure I understand what you mean here.

Tying it back to the question about tile based maps wrapping around a sphere. Say you're working out how many tiles you can fit, and you know that 12, 32, 42, and 72 work...

@DMGregory that is smart

but heck if i was smart enough to apply that

Type those into OEIS and you get sequence A071336 "Number of vertices of Goldberg-Casper-Klug pseudo-icosahedra"

I confess I just got those by doodling soccer balls in my notebook. After I'd filled a page with 4 examples then I started hacking away to find the pattern.

that's after running about 10-15 rots or more

and 1 deg per function call, one call per frame, 60fps

Do you normalize your quaternion periodically to make sure it remains unit length?

no i don't. that's probably it

When you use the current value of a variable as an input to compute the next value, you create a feedback loop. Any tiny rounding error in the input can compound into a slightly larger error in the output, on and on, snowballing with each iteration until it becomes significant/noticeable.

yeah that's why i thought it'll be the floating-point error accumulating

but posting it here made you mention normalizing, which i totally forgot about doing again

Yeah. The floating point error alone isn't a problem - you'll get a length within about 2^-23 of the true value after one multiplication. That's an error much smaller than a pixel.

i was thinking along the line of somehow smoothening each component, e.g. by multiplying them with 1e+6, casting to an int, and dividing back to floating point

Do not do that.

i know that's silly

but that was the best idea i had before you brought normalizing back to my brain

^^

and it very likely would've worked

The problem is the feedback loop, that takes an insignificant error and amplifies it. We often blame floating point for errors that come from the way we chose to use the numbers, not from the number format itself. 😉

if you cut off the error-margin before it accumulates then it'd work

A standard 32bit C float should have around 7 digits of precision before it all falls apart if that weird bit of knowledge is right

Universities make you learn weird stuff

Something like that. I like to think "2^-24 relative precision". Take the number you want to represent, X. You'll be able to represent it to within +-(X*2^-24)

I have a table of expected precision in this answer I look up from time to time. 😁

but then again the whole thing has been rotating for the past 10 or more minutes and stays stable in size, normalizing it is - which means the floating point was right

Or, "right enough" ;)

and the normalizing solution is way better than keeping a floating point degrees running and rotating clean quaternions every frame

We tend to do transformations in the order of: translate * rotate * scale * position

But wouldn't it make more sense to scale at the end? So: scale * translate * rotate * position

So all movements (positional change) are in worldcoordinates instead of scaled coordinates?

Generally if I say "translate by 1 unit" I really want the object to move 1 unit, even if I had to scale its model to 1.52x to make it look right next to my other assets.

Also, if you apply a non-uniform scale after rotating, then the axes the scale is applied to can be different from the object's axes, making it visually skew in a weird way. Lemme find an example...

Here you can see a non-uniform scale applied after rotation. It can be a cool effect, when you want it, but it's not the most intuitive thing we'd want all the time as our default: