Hacker News Reader

Comment by moron4hire | Hacker News Reader

You don't need to understand the root construction of Quaternions to use them in game code anymore than you need to understand the root construction of the Reals to be able to do arithmetic in game code. Just treat them as opaque values that have certain operations you can perform to get certain results and be done with it.

View on HN

The author is arguing against this exact mentality - and I believe, this was one of the main motivations this article was written:

> Personally, I have always found it important to actually understand the things I am using. I remember learning about Cross Products and Quaternions and being confused about why they worked this way, but nobody talked about it. Later on I learned about Geometric Algebra and suddenly I could see that the questions I had were legitimate, and everything became so much clearer.

I tend to agree with the author. I find it a lot harder to work with concepts I don't understand: I'm forced to "fly blind" and just plug in formulas and hope everything works. At the latest when you have to debug something, this can go horribly wrong and leave you without a lot of options.

So you know exactly how everything in your computer works, because otherwise it'd be too hard to use? I wager the exact opposite is the case: it's much easier to use a computer through heuristics of operation rather than any sense of "deep" understanding.

Besides, your GPU shader code implements fast quaternions, and you aren't going to get NVidia to replace them with rotors. So the game is lost.

Oh, unless you don't mean "understand everything" and are going to draw your arbitrary line at the GPU.

the math is the same so technically nvidia gpus already implement rotors.

They didn't say "understand everything", but that's the interpretation you're replying to, and it gives me some thoughts.

Different people will be okay with different levels of understanding. You put "deep" in quotes. You should also put "heuristic" and "easier", and many more, because all of these terms are up for analysis now.

A very heuristic operation of technology is "power cycling"--"have you tried turning it off and on". Another version is "factory resetting". This is very useful, but without a slightly deeper understanding of what is does, or how computers work, it's easy to waste time doing it. Like if I get a cloudflare message saying some website is unavailable, I'm not going to log out and back in. I'm not going to turn my computer off. I'm not going to do anything. But that requires a slightly deep understanding.

I wouldn't try to argue what's easier and what's harder for people so generally. There are lots of different kinds of people. That's why both the quote and the grandparent are explaining their personal motivations and describing themselves. I mean, you kind of acknowledge this after the fact when you talk about "arbitrary lines", but it still sounds like you're dissing someone's "arbitrary" personality. I mean, yeah, even if it were arbitrary drawn at GPU---that's the sense in which we are individual people...

Shader languages do not include quaternions as primitives, so if you do have quaternions in your GPU shaders, it's your own code (or a library), not NVidia's. What is usually done in shaders is encoding all transformations (rotation, scale, translation) in 4x4 matrices, which are a primitive in all shader languages I know of.

From my personal experience, it can pay off immensely to understand the internal structure of the representation you're working with. I can look at a 4x4 matrix and immediately identify some stuff (does it include a translation component? does it scale and is this scale uniform? is it rotated and around which axis?).

Meanwhile, I can't do this with a quaternion. I know what they do and can understand how, but I have no intuition for what the four numbers mean.

I added quaternions to my Javascript canvas library. They scared the heck out of me - I coded up the functions from scratch in JS, partly to try and 'understand' the concepts behind quaternions, but mainly because I was stupid and over-confident. I am not a math/physics genius!

I doubt using the concept of rotors in place of quaternions would've made my experience any better. It's not the concepts that really frighten me - I can read about them and nod my head, pretending that the information is somehow sinking into my brain; the things that scared me were the equations which, the article implies, are pretty much the same.

In the end, the things (seem to) work as intended in my library, and I can now sleep at night knowing I'll never have to revisit quaternions (or rotors) again in my life.

Not knowing what's behind the hood in floating point numbers and their limited precision leads to all kinds of surprises.

Rarely

Often. Often missed though.

Almost every component of a game is built on the premise of leaky abstractions that go unnoticed. Texture compression, lighting techniques, physics, audio filters, network latency filters.

There are other uses of 3D than games. 3D Engine != Game engine.

Try building a space game at real-world scale on 32 bit floats. Star Citizen tore apart Cryengine to make it have 64 bit positioning for this very reason.

Kerbal Space Program manages it.

(by moving the world around the origin)

Yeah in singleplayer with lower fidelity that is passable.

> Personally, I have always found it important to actually understand the things I am using. This article is aimed at readers who do find understanding the constructions they use important.

That is the point of my comparison to the Reals. No accountant or mechanical engineer or architect need ever read, let alone understand, any proofs that the Reals exist or the fundamental construction of arithmetic. I know several highly successful economists who don't know the construction of statistics, anymore than knowing that the proofs exist and could be found somewhere, if it ever really mattered (it doesn't). As a developer, you are not a theoretical mathematician. You use math.

Game development is not fundamentally more hard than any other field of applied engineering or mathematics. It isn't theoretical mathematics. You just use the math.

Needing to "understand" root construction before "being able to use" is just procrastination.

That's fine if you're building something that's already been made. Games don't do that, when you push the boundaries you need to know how your math works. You won't get more performance than the competition without understanding the tools you are using.

And here we see the other common conceit in the game industry, that graphics make a game.

I didn't say that? There's more ways to push a game than with graphics? That's not the words in my mouth.

Star citizen needed 64 bit positioning for real world planet scales in game, that had to be hacked into cryengine...

It didn't need it. That was just the solution the devs created. They could have done it with 32-bit floats, or hell, 32-bit integers, if they wanted, given the right representation. But they chose 64-bit floats to solve the problem, the problem did not choose 64-bit floats.

It really does need it. 32 bit positioning breaks down fairly quickly on planet scale. Shifting the world origin is not a streamlined process and doing it frequently for each client in a large multiplayer game is nearly prohibitive. You could invest the effort into making world shifting and planet scale work in 32 bit, and the lesser of the two evils would still be implementing 64bit positioning. You gain so much and lose so little for having done it.

> Needing to "understand" root construction before "being able to use" is just procrastination.

since I feel personally attacked by that statement (I say in jest), it's more charitably viewed as a risky investment. Understanding now might help you use it more efficiently later.

3D Rotations are traditionally very tricky to represent in a computer! It's only in "modern" times that basically everyone has settled down on quaternions as the best parameterization. I think the comparison to anything about real numbers misses the point. It's not about rotors themselves, or real numbers themselves, it's about how they model something we care about. Money isn't a real number, but we model a balance in an account using one. And an accountant definitely needs to understand operations such as "debiting", "crediting", "accruing interest". So they need to understand addition, negative numbers, and multiplication. But that's just because of the choice of the model.

funny enough, it seems like lots of accounting existed a while before negative numbers were obvious, so there are all sorts of to-me funny ways of representing negative numbers, or subtraction (I don't have any clear evidence to back this up). Everyone was doing accounting just fine before, but really it just feels more obviously elegant to use a negative number to represent a deficit.

Why then engineers do get taught that?

Also :

You "can" be a "good" engineer while thinking the Earth is flat. (Unless you're working on space-related projects of course.)

You "can" be a "good" scientist without knowing anything about epistemology, Popper, Kuhn...

(But can you, really, be a good one ?)

(Also IMHO most of today's economists are just charlatans akin to the astrologers of old, misusing math because math gets your more respect, and it's probably related...)

That's not how it works in programming in general. Many - if not most - abstractions turn out to be extremely leaky. (For example, you do want to know the difference between the "root construction of Reals" as it is done in mathematics and what is taken to be their representation in the computer.)

Reply on news.ycombinator.com