This is a somewhat unrefined brain-dump of an idea that’s been developing in my brain for a while.
It has a bit to do with voxels. Not really anything to do with Basic4GL.
(It also tests pasting markdown into WordPress.)
Imagine if the Internet was one massive 3D world, distributed across thousands of servers, where you could stand on a hilltop and look across that world in its entirety. Imagine if your favourite online games were part of this larger world. You could join them just by walking (/driving/flying) up to them. Or you could see what’s available just by walking around and exploring.
I believe this is technically possible.
I’m going to explain how in a basic question-and-answer format, because, frankly, I can’t think of a better way.
It will require voxels.
How would this work?
(I’m going to refer to the “one massive 3D world” as “cyberspace”.)
Cyberspace would be divided into smaller virtual volumes, which connect together. Each volume would be hosted by its own server, which stores and serves up 3D content. Cyberspace would be experienced through a client application which downloads and displays this 3D content.
So the client downloads “3D content” from every server?
No. The client would find the server whose volume contains your current position in cyberspace, and download from that one only.
But how can you “look across that world in its entirety” if you only have 3D content from one server?
Each server would store a copy of the whole of cyberspace as viewed from within its volume. The client would download and displays this.
So to build up this “copy” each server has to fetch the 3D content from every other server?
No. Each server would talk only to its adjacent neighbours, and ask “What’s in your direction?”. After enough iterations every server would eventually have a complete picture.
But wouldn’t the data become far too large to transmit, download and render? You said “thousands of servers”.
Each server need only store the 3D content required to render cyberspace from within its own volume. This places an upper limit on the amount of information each server needs to store, in two ways:
- Level-of-detail. Servers can drop unnecessary detail from far away content.
- Content-at-infinity. Each server manages a finite volume of space. There is a distance beyond which any content will appear the same when viewed from any point within that volume. This content can be represented by 2D “skybox” textures.
What format would this 3D content take?
Servers would store their original 3D content in whatever format they wish (some sort of textured polygon mesh being the most likely).
The content must be converted to voxels before being transmitted to neighbouring servers.
The client would download the original 3D content from the current server as well as the voxels representing the content outside of the server’s volume, and combine them together to produce the final image.
To share 3D content between servers a common format must be agreed upon. Voxels have the advantage that they are very easy to down-sample, which is required for level-of-detail management. They are also relatively easy to generate from polygon meshes.
Graphics hardware has reached the point that it can ray-cast sparse voxel octrees in real-time.
The main limitation of voxels is that they can quickly get expensive (in terms of storage) at finer detail levels. To avoid this, we use the original 3D content (e.g. polygons) for the close up content (inside the current server’s volume), and only use voxels for the far away content.
It may be that a full voxel model with enough detail for a 1080p monitor may still be too cumbersome for current network speeds, in which case we will need to work with lower detail versions, meaning voxel content will look a little blurred/low res. But network speeds are increasing all the time.
What sort of client would this use?
There would be one generic “browser” type client which accept a general textured polygon mesh format. Perhaps with some basic scripting support and low latency networking for receiving position updates for moving objects etc. This would cover general purpose virtual areas, and would be enough for walking around, virtual stores, maybe some basic gaming.
High budget games would have their own clients, with their fancy next-generation graphics engines, networking code etc. They would pretty much function the same way they currently do, except that they will also support downloading the voxel model of rest of cyberspace and rendering it behind the local content.
When the user walks up to the server’s volume in cyberspace, the generic client will negotiate with the server whose volume they are transitioning into whether they are allowed to proceed and which game client it needs to launch and pass control over to.
What if the user doesn’t have the game client installed?
Then they can’t enter the volume and join in the game until they buy it and install it. Pretty much the same as it is now (except they can look in from the outside).
Having said that some games may choose to support a secondary form of access, using the generic client’s protocols and 3D mesh format. Consider an online racing game that allows people who don’t have the game installed to walk in and watch from the stands or over-bridges for example. They wont get to see the content rendered with the game’s cutting-edge graphics engine, but some developers may still see some merit in this (building community, advertising, e-sports).
How would this get started?
To get this off the ground would require the following:
- Work out and document the technical details, such as:
- The format for the voxel data, which may differ based on whether they are stored on server, being sent across the wire, or stored in the client GPU memory for rendering.
- Network protocols for server-server and server-client communication.
- Level of detail. For best results voxels should be small enough to project to a single pixel. How small this is depends on the display resolution and field of view. An initial target resolution and FOV needs to be established and applied across all servers.
- … And a whole bunch of other stuff.
- Create a proof of concept, with some networked servers sharing content and a basic client. Spread the word around. Invite people to download the client and connect to it, or host their own server and add to the 3D world.
- Maybe try to find an existing game developer who is willing to integrate their game client into the new cyberspace world.
- Grow and improve the specification.