Astral Realms

I have completed the Quad Sphere! It took some time to draw the other five planes of the sphere in the correct location and the correct orientation, but that is now working.

The system is scalable, I can enter a resolution and it will draw a quad sphere with that resolution, so for example a resolution of 3 will produce a very blocky sphere, such as this:

while a resolution of 10 will produce a much higher resolution sphere, like this:

The resolution gives the number of vertices per plane, so a resolution of 3 works out to: 3*3 = 9 vertices per plane. In this grid, there are (3-1)(3-1) squares, which is 4 squares, each square contains two triangles, which is 8. There are 6 sides to the quad sphere, which means a final poly count of 8X6, which is 48. Clearly, the complexity scales dramatically with resolution, and this is why, for generating even reasonably large or complex terrains, optimisation and culling  will be extremely important.

The algorithm seems to be working well, although I am noticing some distortion of some kind visible around the seams. I am hoping that this is a cosmetic issue that can be fixed when I implement texturing, but it may be more serious. The next step is to apply a noise function to the vertices to produce an actual bona fide “terrain”. What I have now is really just a sphere. Once I do this, I will know how serious the seaming issue is.

I have succeeded in drawing one face of the quad sphere! I had made a slight error in the implementation of the mathematical equations, which is why it didn’t work before, but it is working now. This is a major step forward. I now need to draw all six faces of the cube, so that I can project them to form the completed quad sphere. In the images below I have copied and pasted several several faces and manually rotated them, to confirm that the edges line up correctly.

After I get the complete sphere drawn, I will need to apply a noise function to produce the actual detail of the terrain. With T3D’s terrain, this was easy, but with my new solution I am doing this completely from scratch, so I will likely need to apply some kind of smoothing function manually.

Then, I will need to look into texturing, collision detection, culling, and a whole host of optimisations!

After the issues I had with modifying T3D’s terrain, I had to come up with another solution to the problem of creating a quad cube. In the engine there is a piece of sample code called the “RenderMeshExample”. This basically outlines the code necessary to create and render a mesh using vertex and primitive buffers. I have been modifying this code in order to create a six sided cube with a specified number of vertices on each side.

I then intend to apply the sphere mapping equations to the cube’s verts, to produce the quad cube. Using rendermeshexample as a starting point has one main advantage, in addition to allowing me to write the rendering code from scratch. It allows me to create all six sides of the cube within the same mesh, so that there should be no visible seaming effect. This avoids a very difficult problem that I would have had with my previous solution.

However, I will have to write collision, optimisation, culling, paging, and a whole host of other features myself, since rendermeshexample doesn’t contain them. This will certainly prove difficult.

I have managed to draw an entire face of the cube, and change the resolution, creating a grid of whatever size I want. I now need to project this face to a sphere, and of course, draw the other faces.

I have run into a stumbling block with regard to the spherical terrain implementation for this project, so I took some time to work on a different aspect of it.

I have implemented the code changes described HERE which allow for the player class in T3D to be rotated about all axes. By default, the player is only capable of rotating about the Z axis. I have also added code to keep the player aligned to the terrain, as well as modifying the gravity vector so that it is relative to the center of the spherical world object and is not just applied to the negative Z axis.

This means that the player can now walk around spherical and non-flat terrains without falling off. In this example, I have used a mesh object, not a terrain, but this will not make a difference.

The approach I need to take to creating spherical terrain involves the creation of a “Quadrilateralized spherical cubes”. Essentially, a cube which is projected to a sphere.

I have been trying to create a sphere using the wrong equations. I have been getting very close to the solution, as can be seen in the first image, but this approach will not solve the problem. I can only have one value along the z-axis with the type of terrain I am using, and so creating a sphere or part of a sphere with conventional sphere equatiosn will produce distortions or invalid vertex point information whenever the sphere section curves back on itself.

I will need to use different equations to produce the Quad cube, however, this wil require being able to modify the X and Y axes of the terrain file in addition to the Z axis (height). The second two images show the results of modifying the Z-axis height only. This is very close to being correct, but I can never assemble these sections into a sphere without also modifying the other axes. T3D’s Terrain does not allow this, and so I have quite a lot of work to do to modify the terrain code.

UPDATE:
I found THIS website, which contains the equations necessary to create the quad cube. This is a vital resource.

I have made quite a good start with the spherical terrain. I have managed to create a cube using six terrain objects, and have learned how to deform those terrains using curves, and apply noise to those curves to generate terrain.

I now need to create an actual sphere. I have succeeded in creating a curved terrain object, but it is not spherical, and has visible seams at the edges. This will likely be the greatest challenge of the project, at least before I start working on terrain paging and very large terrains.

T3D’s terrain system, which I am basing my spherical terrain on, is very simple and easy to use. It is basicaly a list of vertices, and so terrain can be deformed very easily using the following code:

        for ( S32 y = 0; y < blockSize; y++ )
{

for ( S32 x = 0; x < blockSize; x++ )
{

                   file->setHeight( x, y,999 );

           }
}

Where “file” is a terrain file, and “999” is the desired height of that terrain pixel. Blocksize is the resolution of the terrain, so 256, 1024, etc.

After much careful thought about the future of my virtual world concept project, I have decided that I need to at  least make an attempt at implementing the holy grail of realism: Spherical Terrain. Spherical Terrain is exactly as it sounds, terrain which is in a sphere. This kind of terrain allows a developer to create realistic planets and moons, which can be viewed at any distance. Most terrain is flat, as this is the simplest to create and texture. However, flat terrain has some serious limitation for open world and virtual world games.

Firstly, and obviously, in a game which allows the player to build flying vehicles or structures which are high off of the ground, flat terrain may allow a player to see, or even reach, the edges of the terrain. This requires some kind of unrealistic mechanism to prevent the player from leaving the world, such as teleporting them to the other side of the map, automatically killing them for leaving the “play area” or even the dreaded “invisible wall”.

Secondly, flat terrain doesn’t allow for space games (unless some trickery is used in the surface to space transition). It also makes it difficult to use realistic world simulation code, such as simulating climate, terrain type, etc etc. Spherical terrain could have realistic orbits around a star, which could be tied in to a very realistic day/night simulation, as well as seasons, weather, climate, etc etc.

Spherical terrain, particularly for large worlds, is difficult. It involves a lot of paging data from the hard disk (only a small amount of the world can be stored in memory at once, so chunks of the world have to be constantly loaded and unloaded from memory), texturing has to be procedural (just TRY to load a texture big enough to cover an entire planet into photoshop!)

In general, the simplest method of making spherical terrain seems to be to create six normal, flat terrains, and arrange them into a cube, where each terrain meets at the seam of the adjoining terrain. Then, use a spherical mapping algorithm to map the cube terrains into a sphere. This is the concept, but I have a lot of research to do before I can even attempt to do this in practice.

I have just completed setting up and testing an SQL server in T3D.

I had to first install Ubuntu linux on a server machine I had (it used to run Windows). I then had to install and configure mysql and mysql workbench.

I had never used Ubuntu before now, and so far, I am likingit. It’s a nice operating system, fast, responsive, and powerful. I like the Software center, which makes installing software a breeze, I don’t even have to search websites. I did have an issue with installing mysql which required a few uninstalls/reinstalls, but that may have been due to my inexperience.

I used THIS resource to set up mysql in T3D. It is the most straightforward and easy to use resource I have found to add mysql support to T3D.

Something to be aware of when using mysql is licencing. I am not an expert on the legal issues present here, however, my understanding is that if a developer releases mysql code to a client, the developer is required to purchase a licence, which costs several thousand dollars. To avoid this, what I and other developers have been doing, is adding the mysql code to the servers only, and not the clients.

The way this works is that instead of a program using client-side code to directly communicate with a database, it instead communicates with a game server. The game server then uses mysql to communicate with the database. Since the code on the game server is never released, the client never gets access to the mysql code, which means the developer doesn’t need to purchase a licence, even for a commercial game. This approach is also far more secure, since it prevents malicious users from modifying the client sql requests, and tampering with the database.

I have spent several days working on some bug fixes and improvements to the directional levers.

The code that I had was failing when the user tried to move the lever while the platform itself was also moving. In addition to this, the lever would sometimes move in the wrong direction, depending on the players viewing angle in relation to the lever.

This was again a vector math problem. I was using the position of the players eyepoint to calculate the direction and magniture of the movement vector for the lever. As the player was standing on a moving platform, the players position was changing as the player was manipulating the lever, which threw off the calculations. I eventually manged to fix this, and fix the issue with the direction being flipped if the user approached the lever from the opposite side.

Levers now seem to work correctly, but I have not yet wired them up to control the platforms.

This feature needs to be done correctly, since user interaction with the environment is a key feature of this project. I don’t want to have GUI’s or other static or non-immersive gameplay elements, I want the user to have complete control of their environment through emergent means.

I now have levers smoothly rotating in both directions when the user clicks and drags the lever with the mouse. I have some more debugging to do on this, and then I need to connect the levers to the platforms to allow for directional control.