Virtual Physics

Last time I left off with a virtual ball moving towards a virtual wall after touching on the basics of how we determine if and when the mathematical ball virtually hits the mathematical wall. It amounts to detecting when one geometric shape overlaps another geometric shape.

In the physical world, objects simply can’t overlap due to physics — electromagnetic forces prevent it. An object’s solidity is “baked in” to its basic nature. In contrast, in the virtual world, the very idea of overlap has no meaning… unless we define one.

This time I want to drill down on exactly how we do that.

We’ll use the same 2D setup as last time.

The wall (a 2D rectangle) is defined by the opposing corner coordinates: [120, 82] and [145, 82.5]. That means our wall extends from 120 to 145 along the X direction (we’ll call that east-west) and 82 to 82.5 in the Y direction (north-south).

We using the scale that 1.0 = one foot, so the wall is 25 feet long and 6 inches thick. We’ll also assume all coordinates are positive numbers (and skip all the + signs).

Just to be clear: Going east means increasing your X coordinate. Going north means increasing your Y coordinate. Conversely, going west or south decrease your X and Y, respectively.

The ball (a 2D circle) is defined with a radius of 0.25 (three inches). The ball is moving, so its location coordinate (which positions the ball’s center) changes with each clock tick.

That’s where we left off last time.

§

Velocity encodes both speed and direction, which makes it a vector.

We generally represent velocity as the degree of change along each axis per clock tick. The larger the change, the faster the motion.

In our setup, moving directly north increases the Y coordinate without changing the X one. Moving directly west decreases X while leaving Y unchanged. Moving along any diagonal changes them both.

In a virtual reality, “movement” means that each virtual clock tick causes an update of the object’s location coordinate(s) using the velocity vector associated with that object.

Imagine, for example, simulating a pool table just at the break, with all the balls in motion. Each ball has its own velocity vector, and each clock tick the simulation updates each ball using its vector.

Then it needs to see if any have collided (or hit an edge)!

§

Oops! Missed!

This requires testing the objects’ geometries to see if they overlap.

Physical objects simply can’t overlap, we don’t have to worry about it. (In fact, mechanical designers need to worry about when parts do overlap, because that’s usually catastrophic.)

Abstract geometry, however, has no problem overlapping. We can draw thousands of circles in the same spot. So if we intend to simulate reality, we need to both detect and respond to objects overlapping.

[OTOH, overlapping is sometimes what you want. Some 3D toolkits create complex shapes by merging simpler ones.]

The very simple example last time indicated basically how we check for overlap. A mathematical analysis of the boundary points of two objects tells us when a point from a moving object is “inside” of (or just touching) another.

With two balls (in the pool table example), if the center-points are twice the radius (or less), then the balls are touching (or overlapping). Circles and spheres are easy because they’re such regular shapes. Their boundary is — by definition! — a fixed distance from their center.

Rectangular objects are easy if they are squarely aligned. In that case, testing their boundaries (as shown last time) is a simple matter of crossing an axis line (X, Y, or Z).

It’s a bit more complicated if the straight lines are diagonal, but objects with flat surfaces are easier than irregular objects. Even so, the math is well known and understood. It can always tell us if a given point lies inside (or right on) some boundary.

§

I’ve made a point so far of differentiating objects just touching versus objects overlapping. There’s an important point about that.

Ideally we don’t want overlap. Real objects don’t overlap, so we don’t want them to do that in the virtual world either.

Consider the ball moving towards the wall. Each clock tick the simulation updates its location, and at some point the ball will be either just touching, or just inside, the wall.

It depends on how much the ball moves each time. Say it moves 0.1 along the Y axis each clock tick (starting at 80.0 — the wall is at 82.0).

After ten clock ticks the ball is at 81.0 and seven clock ticks later it reaches 81.7. The ball’s radius is 0.25, which puts the ball’s boundary at 81.95 — not quite touching the wall.

The next clock tick puts the ball at 81.8, which puts the ball’s surface at 82.05inside the wall. Oops!

The problem here is that the simulation is badly designed. It allows the ball to move fast enough that it can overlap objects before the simulation can detect that overlap.

Essentially, the problem is that the clock is too slow. If we run the clock ten times faster, the ball only moves 0.01 per clock tick and we’re able to detect when it touches.

§

The typical result.

This problem can be even more severe.

If the ball moves fast enough, and the wall is thin enough, then it’s possible for the ball to tunnel through the wall.

Imagine the wall’s thickness runs from 82.0 to 82.2 and the ball moves a whopping 0.8 each clock tick. You may already see the problem.

If, as above, the ball’s edge is at 81.95, placing it just “south” of the wall, its center is at 81.7, so the next clock tick puts it at 82.5, which means its (south) boundary is 82.25, placing it just “north” of the wall.

The ball goes right through the wall as if it isn’t even there.

Obviously the simulation is allowing the ball to move much too fast for the clock rate. A faster clock rate fixes this. Or, if it makes sense, disallowing such fast speeds is also a fix. (One can implement something akin to air resistance, for example.)

It isn’t just that we have to implement every aspect of our virtual reality physics. It’s that we also have to get it all correct.

(Given how hard software is, that’s an important point.)

§

The larger point is that all rules in a virtual reality are up to us to define and implement (correctly). As such, all rules are entirely arbitrary (and potentially buggy).

One thing about physical reality… as far as we know, it’s bug-free. (In a very real sense, the concept of “bug” doesn’t even apply.)

§ §

This has gotten a bit technical and math-y, but as I’ve said all along, it is all just math.

But there is a key point about what kind of math, and it’s one I haven’t really mentioned much so far. The math does involve number-crunching (adding and such), and it also involves logical operations (such as AND, OR, etc).

Even more crucially it involves a very special (mathematical) idea: algorithms — which divide evaluation of expressions from execution of logical steps.

The operation of a virtual reality requires execution of its algorithms and involves one of the most fundamental distinctions in computer science: code (algorithms) versus data (information).

[The distinction is, on the one hand, clear and precise, but on the other hand, entirely context dependent. A loader program sees code as just a file of bytes to read into memory, but the CPU sees it as a set of instructions.]

None of what we do in a VR is possible without algorithms because they bring to life two very important things: Firstly, what’s called “selection” but commonly thought of as the “if-then-else” statement. Secondly, the ability to save state — aka variables.

These tools allow us to compare the geometry of two objects and determine if they overlap. The basic idea is pretty simple:

if overlap(object1, object2)
then
    react_to_collision()
else
    keep_on_keeping_on()
end if

That ability to test and react is what algorithms give us. It’s what allows us to write programs that do things.

At the same time, remember that, not only is it just math, it’s just ones and zeros.

Ultimately their operation is simple and very easy to understand, but in combining lots and lots of them, unimaginable complexity arises.

Just consider that one bit only has two values (the aforementioned one and zero), but just ten of them have over 1000 states, 20 have a bit over a million, and 40 have over a trillion. Each bit doubles the count.

§

So this has been a bit of a tour. It began last week with five purely physical systems and then looked into numeric simulations and emulations of those systems. This week, we got into virtual causality, got lost in a maze, and considered walls.

The take-aways are (I hope):

  • Virtual reality is all math — everything is calculated.
  • Virtual reality is arbitrary — it can be anything.
  • Virtual reality requires algorithms — it must decide things.

Virtual reality has no causality other than what’s programmed into it, and that programming is entirely arbitrary.

This applies equally to text messaging apps and future uploaded brain VR scenarios. Software is just numbers, and we can make those numbers do just about anything we want.

Stay algorithmic, my friends!


				

About Wyrd Smythe

The canonical fool on the hill watching the sunset and the rotation of the planet and thinking what he imagines are large thoughts. View all posts by Wyrd Smythe

4 responses to “Virtual Physics

  • SelfAwarePatterns

    The discussions about objects not overlapping reminded me of all the grief I had trying to make collisions work in the Defender-like video game I tried to write as a teenager, in 6502 assembly. The Atari platform had some interesting resources to help, but for various reasons they didn’t work for me. Ah, memories of pouring through the De Re Atari book.

    “One thing about physical reality… as far as we know, it’s bug-free.”

    Depends on what level we’re talking about. You could describe a detrimental mutation as a bug. Or the flaws in someone’s brain that causes epileptic seizures to be a type of bug. With sufficient complexity, bugs, in one form or another, seem inevitable.

    • Wyrd Smythe

      “The discussions about objects not overlapping reminded me of all the grief I had trying to make collisions work in the Defender-like video game I tried to write as a teenager, in 6502 assembly.”

      Exactly. So you know what I mean about having to do everything when implementing a virtual reality and about how hard it is to get right.

      (Ah, the 6502. Commodore used that CPU, too, and I have a lot of fond memories. A great deal of my early work involved assembler-level stuff for the 8086, 6502, or Z80. Loved them all!)

      “You could describe a detrimental mutation as a bug.”

      Certainly. As you say, depends on what level. The things you describe are all high-level systems that suffer errors. But those errors follow physical laws, so they’re not “bugs” in the sense of the universe not working correctly.

      “With sufficient complexity, bugs, in one form or another, seem inevitable.”

      That brings up an interesting point. Are bugs different than errors?

      Bugs certainly are errors, but are (all) errors necessarily bugs? I suppose it depends on whether you think of a bug as just an error or more specifically as an error in human judgement or performance.

      • SelfAwarePatterns

        I think any old programmer knows that if you don’t code it, it won’t happen. Although that’s probably less evident today with everyone using libraries, frameworks, and APIs, all of which take care of a lot of messy details that someone on an Atari or Commodore computer coding in assembly had to handle themselves.

        The philosophy of bugs! I think of a bug as any aspect of a system that prevents a desired outcome. So, it’s very much a value judgment. I noted mutations above, but the difference between a detrimental one and a new feature is all in what leads to successful reproduction. I’ve occasionally had a feature accidentally show up in a program, which I then just said, “Oh, okay, why not?” (Although that’s a big no-no in product development since accidental features go on to have support ramifications.)

      • Wyrd Smythe

        “Although that’s probably less evident today with everyone using libraries, frameworks, and APIs,”

        I think that’s true. (As you say, old programmers know these things, young ones may be less up on them, but non-programmers don’t know them at all.)

        I’ve taught programming, and I’ve done a fair bit of mentoring. I’ve found that {Has Developed Apps Using Assembly} is a pretty good predictor of programming ability. I think it really helps to have worked at the “metal level” — one has a much better grasp of how a computer does what it does.

        Those who have few languages, all high-level, and have relied on libraries (e.g. have never written a CSV or TAB file parser), often just don’t have the insight or experience that assembly gives one.

        (There’s a smaller group of us who have worked with compilers and are experienced with the mapping between high-level source code and machine code. I’ve run into coders who don’t think one is “really” a programmer until one has designed a programming language and written a compiler for it. Kind of an extreme and old-fashioned view, but I admit some sympathy towards it. At least understanding how compilers work is, I think, very useful.)

        “I think of a bug as any aspect of a system that prevents a desired outcome. So, it’s very much a value judgment.”

        Ah, yes, and that introduces yet another level… I’ve been pondering errors and bugs since you raised the topic, and it occurs to me there is a whole ecology one could list.

        • Unliked Feature (but correctly working as designed). Basically a disagreement between the user and the designer as to the value of a feature. Purely, as you say, a matter of value judgement.
        • Broken Feature (not working as designed). A logical error on the programmer’s part.
        • Unexpected Feature (not designed at all). Some consequence of not managing the complexity of an application.
        • System Error. A data mistake of some kind. Rare in the computer operation; common in data transmission and sometimes storage.
        • Programmer Error. A typo, a memory leak, etc. General programmer mistakes.

        And probably others I’m not thinking of.

        What I’m finding interesting is contrasting software bugs with hardware bugs and nature bugs (taking this back to the idea of bugs in basic physics). Many of these can be lumped as a “Design Error” of some kind. (My comment in the post was suggesting there are no such design errors in reality.)

        On the flip side, a system error is a kind of reality error — noise corrupting the data.

        Heh. I just naturally used the word “error” in that last sentence, and I think that indicates my view here. A bug is a very general idea, and even a value judgement, but an error is even more generic (all bugs are errors), and not all errors involve value judgements (corrupt data is corrupt data).

        In baseball, many distinguish between “mental” errors and “playing” errors. (In baseball, all errors are judgements on the part of the Official Scorer, but some are more objective than others. The basic criteria is: Would a normal baseball player normally have made that play? Fortunately, the answer is usually pretty clear, and there is an appeals process. But umpire judgement calls do add another not often appreciated element to the game.)

        So a playing error is a physical mistake of some kind — failing to catch the ball or whatever. A mental error is a judgement mistake — throwing to the wrong base, for instance. Many fans find physical errors more forgivable than mental errors. (These guys have been playing baseball since they were kids… mental errors are hard to forgive. This is what you do for a living, dude!)

        Anyway, what I’m turning around in my head (and what may end up as a post one of these days) is the idea of physical versus mental mistakes… or of design errors versus system errors.

%d bloggers like this: