Spiritus Astrum

I have made significant progress with the terrain’s floating origin system.

I have added and tested all of the distance calculations, and I can now move the player in world space and have that world space position influence the rendering of the terrain nodes. This means that the terrain “pages” as the player moves in world space, as expected.

P152_DEBUG
14/07/2016 , 05:42:29 AM
Torque 3D MIT – P152
However, I have discovered a problem with my concept.

Currently, the process is:
The coordinates for the terrain nodes are in local space, so I scale these to world space (64-bit numbers).

I then get the distance from the center of each terrain node to the player, and cull everything further than a specified distance.

I then take the nodes that haven’t been culled, rescale them to 32-bit space, and apply the LOD subdivision to them.

The problem here is that when I scale to 32-bit space I am basically scaling the entire world to a radius of 10,000 units. Even though I have a floating origin system, I am essentially not using it.
As the player moves around the world in 64-bit space, the terrain in 32-bit space will update correctly, but that 32-bit terrain will have a radius of 10,000 units, which will not work.

What I need to do, is to cull all nodes not close to the player, as I am currently doing, but then, instead of scaling them to 10k and then subdividing them using LODs, I would subdivide the 64-bit nodes without scaling. The initial terrain mesh is low resolution, so each node is far bigger than 10k. If I continuously subdivide each node, and then continue to cull any nodes outside of the 10k boundary around the player, I should eventually end up with a finely detailed mesh containing only nodes within 10k of the player, which is exactly what I want.

These changes will hopefully not be too difficult to implement.

I have completed the re-introduction of the LOD’s. I can now properly subdivide between multiple levels of detail using the new coordinate system.

The images below dont have noise applied to the LOD’s, so the subdivisions don’t look like they are actually adding detail, but the solution does work.

I was able to basically program the system to function between a distance of 0 and 10,000. This should work, since the renderable area of the terrain is going to be a “snapshot” of the entire terrain, rescaled to a coordinate system that doesn’t exceed 10,000 units.

The next objective is to test the floating origin system. I need to be able to move the player in 64-bit space, then grab any nodes within close proximity to the player, and render those in a 32-bit compatible coordinate system.

I believe I am close to implementing the LOD system for the large terrains that I have been working with.

I had to try a few different approaches to this, in order to make the large values work with T3D, but I think I have hit upon a relatively simple solution that seems to work independent of a planet radius.

I have also decided to translate the 64-bit coordinates into 32-bit coordinates for rendering, so no object in T3D is outside the 10k limit. There is still quite a bit of work to be done on this, but once I have finished the planet-specific floating origin system, and the LOD system is working again, I should be a lot closer to success on this project.

The next goals will be to allow the planet to be rendered over vast distances, until it eventually ceases to be visible. Currently, I am concentrating on ground-level rendering, I will need to include some additional logic to make the terrain work over long ranges.

I also need to solve what I think will be a problem with scaling the visible terrain from 64-bit coordinates to 32-bit. Currently, I am just scaling the terrain, but this will cause the curvature of the planet to be quite incorrect, since the diameter of the planet is now essentially 10,000 units, even though it is possible to traverse the entire planet using the floating origin system. I will need to find a way to alter the curve of the terrain to match the actual curve while still drawing the terrain in 32-bit space.

The below images show the terrain at two detail levels. The difference is very subtle, which is the intention, ideally, it should not be possible to tell the difference between two LOD’s.

My current goal with this project is to fix the LOD and scaling parameters so that I can subdivide the terrain correctly based on the players distance.

Currently, I am rendering a section of the terrain using realistic number. However, my algorithm to subdivide the terrain into different Levels of Detail doesn’t seem to work at realistic distances.

Solving this is proving to be difficult. I think the best thing to do would be to modify the existing system so that the LOD’s are calculated based on the realistic (64-bit) numbers. With the nodes subdivided, I can then easily cull any nodes outside the 10k limit, and then I can either render the rest at their current coordinates, or scale those coordinates down to a more reasonable scale.

The below plots show a selection of vertices at two different scales, a radius of 6137000, and a radius of 10,000. The shape of the nodes is exactly the same, which is as it should be.

I am concerned that translating the 64-bit nodes to 32-bit space may not be possible, or may be difficult, but before I can investigate that, I need to solved the level-of-detail problem.

I believe I have achieved a preliminary proof of concept for the planetary scale terrain.

I achieved this by taking six images, one at each “Point” of the quad sphere. The player was spawned at a distance of 6137000 meters from the radius, and at each point, they were spawned close to the surface, and each point was central to that side of the quad sphere. This is not exhaustive, but I feel I have achieved a basic working system now.

I also took the following two images. In the second image the camera is 10,000 meters to the right of the first, in 64-bit space. It can be clearly seen that all of the nodes are exactly the same, except that there are an additional two nodes on the right in the second image that aren’t in the first. This proves that moving the players position in true world space causes the terrain to update dynamically. Extending this to the entire terrain, the player should be able to walk anywhere on the planet that they want to without any issues.

The next objectives will be bug fixes, adding the floating origin system to the terrain, and working on the distance scaling of the terrain.

P152_DEBUG
26/06/2016 , 12:13:23 AM
Torque 3D MIT – P152

It looks like the terrain is rendering correctly at a realistic planetary scale now. There are still some issues with it, but those should be solved when I reintroduce subdivision to the terrain.

I am culling most of the nodes that are outside of the players view, and I am noticing no real issues with rendering.

The next goal is to verify that the planet is actually at the correct scale, and that the player can move around it in world space.

I intend to do this by manually setting the 64-bit player position values to various key points around the world, it, the center of the 6 sides of the quadsphere.

There is a lot more work to be done here, but I think I have proof of concept of a very large terrain, assuming the testing I am about to do goes well.

I have looked at the spherical terrain using the wireframe viewer tool in the T3D editor, and, when scaled to realistic planetary sizes, it seems that the remaining issues that I am seeing are due to Z-fighting.

I think that given the huge distances involved, some of the vertices from behind the terrain (the other side of the planet) are being rendered in front of it. What I have been doing over the last few days is experimenting with various scaling factors and coordinate systems in order to come up with a way to reliably cull nodes that are not relatively close to the player. I believe I have succeeded in doing this, and it involves first changing the players scale so that it matches the terrain (the player is in 32-bit space, typical for an object in T3D, the spherical terrains nodes are between -1 and +1). Then, I scale both to by the radius of the planet (6137000 for Earth). I can then get the distance between them.

I am tentatively hoping that by removing all but the nearest nodes, the Z-fighting issues will disappear (since the distance from the nearest node to the furthest is much less, and there are no no nodes in front of each other). This won’t really solve the problem, but it should eliminate any noticeable rendering issues. I can implement a better solution later. Since the player is close to the origin always, there should be no jitter at all.

If this doesn’t work, I will need to find some way of translating the node position from 64-bit into 32-bit space. This is not just a simple case of scaling them down, since a simple scale operation would change the radius of the sphere, which would in effect change the entire terrain’s structure. I will probably have to do something like this eventually anyway, to completely solve the issues causes by the huge view distances.

Even if this idea does work, I will still need to implement the floating origin system which will actually allow the player to travel around the surface of the terrain, and then I will need to implement the distance scaling algorithm that will provide a seamless surface-to-space transition fro the terrain.