I'm working on a virtual reality game which, among other distinguishing features, allows users to build worlds as big as they can possibly imagine worlds being, containing objects as small as they can possibly imagine objects being.
There are, it has to be said, certain technical limits on how big a world can be, in such a game, and how small an object can be in such a world. The usual solution to this problem is to simply limit the size of allowed worlds to some not too ambitious maximum, and the minimum allowed size of objects at some similarly not too ambitious level, and hope it works. But we should be able to do some math and figure out what the technical limits actually are, and that would allow us to make the world as spacious and detailed as possible.
Let's begin with a convenient unit of measure, say, one foot. Worlds are expanses of space, but, for the purpose of our initial calculations, it doesn't matter what kind of space we are working with, and the simplest kind to describe is a one dimensional space, so, a line. We begin with a line segment one foot long.
To understand what we are seeking to do, let's suppose we want to put some object in this line segment. The implication is that this is another line segment, and that it is not longer than one foot in length, but it is not enough saying just that it is in the initial segment. Leftmost point is a certain percent of the width of the initial segment from the initial segment's ends, each of them, and its length is a certain percent of the initial segment's length. In this manner, an object can be described in a rather compact way, such as "segment it's in, left percent, length percent".
Perhaps it should be noted next that our initial segment could be divided into several smaller segments, each of equal length, for example, three smaller segments, and then, if we gave the initial segment the name Zero, the three smaller segments could be named, maybe from left to right, 0:0, 0:1, and 0:2. We have already suggested that an object defined as being in a segment should not be longer than that segment. Let's add the rule that an object in a segment should not be as short as one third of the segment's length. We won't discuss the reason for that rule here, but the implication is that a segment with its left end point in, say, segment Zero, but with a length less than or equal to one third of the length of segment Zero's length, is not considered to be in segment Zero, it is considered to be in one of the divisions of segment Zero. If its left end point is in the first third of segment Zero, the object is described as being in segment 0:0, if it is in the middle third of Zero, it is in 0:1, if it is in the last third of segment Zero, it is in 0:2. This holds as long as the object in question is more than one third of the length of the respective division of segment Zero. Otherwise, it is in a division of the division of Zero, or even a finer division. Thus an object - again, in a one dimensional world, all objects are line segments - could be in 0:0:1:2:1:0, left % 30, width % 30, which would put it in a specific very very small division of Zero, and its left position and length are describe relative to that very small segment's length.
Segment Zero is a space, and we now want to describe a larger space which contains segment Zero. We will describe it as being three times the length of Zero, with segment Zero occupying its middle third. This segment's name - it, too, is a line segment - is One.
Now objects greater in length than the length of segment Zero or equal to it and less long than one third of Zero's length can be placed in 1:0, 1:1, or 1:2, with 1:1 being segment Zero. Smaller objects with left end points in segment zero have been described as being in divisions of Zero or divisions of divisions of Zero, and now larger objects can be placed in One, and other smaller objects can be placed in divisions of 1 other than Zero: ... 1:0:0:1:2, with its left end position and length defined as percents of that division.
Note that making Zero the middle third of One allows our world to expand in all directions, which is to say, in this case, to the left and to the right.
Let's call segments Zero, One, and so on, increasing segments, and we'll call segment divisions decreasing segments.
Now we can test for limits. If segment Zero is one foot long, segment One is three feet long. In other words each increasing segment is three times the length of its preceding segment in the series of expanding segments. Let's try to determine the number of the first segment in the series with a length greater than one mile.
The question is basically this: what power of three do we need to multiply our original number, 1 (one foot) by to produce a number greater than, well, 5,280, the number of feet in a mile?
var 0 = 3; var n = 5280
var answer = firstpowerofogreaterthann(o,n)
function firstpowerofogreaterthann(o,n) {
thepower = 0
while (Math.pow(0,thepower) < n) {thepower = thepower + 1}
return thepower}
Making this into a calculator, I'm going to put that code into a script, and you can call the function by clicking here. The answer will appear here: answer: .
Phew, got that done. There were half a dozen errors in that original code (roughly represented above) which I had to ferret out one by one to get it to work.
But, now that it's working, we know that the numbers zero through eight are sufficient to describe all the expanding segments from one foot to one mile. Our base number for any of these divisions of a mile can be expressed using three bits.
Let's expand further. A light year is 5.87849981 x 1012 miles. (I asked Google.) I guess I just want to do
function firstpowerofthreegreaterthanonelightyear() {
var onelightyearinfeet = 5.87849981 * Math.pow(10,12) * 5280
var powerof3 = 0
while (Math.pow(3,powerof3) < onelightyearinfeet) {powerof3 = powerof3 + 1}
document.getElementById("firstpowerofthreegreaterthanonelightyear").innerHTML = powerof3}
click here for result: .
June 30
Hopefully I can wrap this up, now.
Just to note this, looking up the size of the milky way, apparently it's one hundred thousand light years in diameter, and then the size of the universe is 50 billion light years across. Applying the usual test,
click here. The powers are and respectively.
We can see, then, that the numbers 0 through 57 are sufficient to describe lengths between one foot and the ... I've made a mistake ... the universe appears to be 50 billion light years in radius, so it's 0 through 58 ... are sufficient to define distances between one foot and the diameter of the universe. According to our rule stated earlier, we can place objects in one of these 58 segments, depending on their size, and those objects can be anywhere from one foot in length to one hundred billion light years in length. That placement of any object within that range can be expressed with six bits.
Although this is not the entirety of the data required to define an object of any size anywhere in a space the size of the universe - it is, rather, a small beginning - I'm pretty sure we'll find that the very small amount of data required to make that start is representative, and that the totality of the data required to locate any one object of any size within a very immense range of sizes anywhere in a space the size of the universe and with immense precision is in fact quite small.
I have stated that my goal is to create a virtual reality game characterized by, among other things, worlds of unlimited size and detail. Does no such thing exist? I have no idea, because available virtual reality games are, for my purposes, insufficiently accessible. And that, then, is one of my goals for the game: that it be extremely accessible. This means, first, a world can be initialized, that is, set up, created, in seconds, using already installed software on a readily available machine, and then that the tools you use to operate in a world are very easily understood and are very effective and easy to use, and, finally, that very extensive work can be done in a world completely for free.
There are certainly many available products for creating virtual reality worlds, including ones intended for use by professionals in one field or another, and others for, let's say, kids, or dabblers. Some are very expensive to use, others cost nothing. But I would say that none offer the kind of accessibility I've described, or, maybe, the kind of limitlessness I've described, either.
I have presented some evidence, if you'll allow it, that what we might think would be technical limits on what software of this kind can do are in fact not limits at all, and I suspect similar arguments can be made regarding other kinds of seeming limits, such as can such software run on existing platforms, and be instantly accessible with almost no setup process, and be easy to use, and be largely free to use, and, will people want to use it. But, if these things are, in fact, feasible, why aren't they being implemented? I think it's because of automatic perceptions - call them knee jerk reactions to the general concept -, or, really, one such perception, namely, that in the main people have no use for such systems. Yes, we think, some people will need them or want them for very specific purposes, such as architecture or engineering, purposes which do not apply for the general user - that being an automatic perception which, I think, makes little ultimate sense - or others will want them for fun, or for the occasional small job, but those will only be particularly motivated individuals ... but that as a matter of general utility these kinds of systems are not much relevant to most people's needs.
I believe this is very far from the truth. I believe that, given access, almost everyone will find these tools to be of the utmost utility ... for very general purposes. I will not attempt to describe, just now, in what sense I think this is true - for the moment, I'm jealously withholding my thoughts on the subject - but I believe accessible, limitless virtual reality gaming is a blue ocean, a giant open market with no competition.
A final thought on the market. I have chosen to call my product a game, and somewhat contradicted myself by also saying it has - as a key purpose - general utility. Is it a tool or a game? Absolutely, it is a tool ... but, I'm annoyed by developers who take their limited, inaccessible versions so very seriously, and make their so self-important products so very dry and dull, pretty much to prove how important they in fact are - a silly kind of proof, and even a silly thing to try to prove. True, I am also annoyed by the inaccessibility of games, and by the fact that these games could be utilitarian treasures, but are only so in a certain abstracted way, which is by habit of design, but at least the games are lighthearted. So, I am calling my program a game.
It may be time to return to more technical questions. It's interesting to me that the fundamental technical issues reduce, in fact, to very simple constructs that are, at least conceptually, quite easy to understand. If approached effectively I think they are also quite fun. I've written many essays attempting to describe these ideas and argue these points, and always have felt, in the end, that I was failing in my didactic purpose, or making a mess of it. I've thought often enough that maybe a more interesting approach would begin more from the technical side - and I've been developing my understanding of that side in a fairly satisfying way, recently - and here I feel I've found a way to do that, to some extent, and I'm fairly happy with this result.
