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)!
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.05 — inside 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.
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!