It is looking like I may get proof of concept of the spherical terrain implementation very soon. I will not have a game-ready solution for some time, but I should at least know that my general concept is going to work.
I have, as I said in a previous post, created a simple 4×4 resolution terrain, with the proper arrangement of nodes. This was very difficult, and I have had to hardcode a lot of the code to make it work. I have also had similar problems with the other nodes in the first and second tiers, and I have had to hardcode those as well.
However, I have now reached a point where I should be able to test the optimisation function with the small amount of test data that I have created, and hopefully prove that I am at least going in the right direction.
I will likely have to postpone this project, or at least downgrade it in importance, since I have several other projects still to complete (before the Oculus Rift is Released). I have spent far more time on this than I had planned to, and I am not really very close to finishing it. It is vital for my virtual world project, which is my ultimate goal, and so it will need to be completed.
I intend to continue working on it at a slower pace, but prioritise other projects over it until I have more time to spend on it.
I am still doing some testing on my latest code changes, and I may yet achieve proof of concept. Even if I do, it will still be some time before the terrain is ready to use in-game.
I will post shortly about my plans for the next stages in my virtual world project. I will just use a stock T3D flat terrain for the moment, and experiment with other aspects of the virtual world, such as dynamic world generation, multiplayer and server setup, user interfaces, chat, and of course the ability for the player to interact with the world. My intention is to “simulate reality” as much as possible, so players should be able to build , combine, create, and interact to an unparalleled degree.
I can experiment with all of that using a conventional flat terrain, although, as I said, I will need to upgrade to a spherical terrain system eventually.
I have succeeded in creating a terrain of resolution 16 (4×4 nodes). I am now testing this to see if I can parse it in an optimal way. I have not yet finished doing this, but this is quite important. If it works, I could claim to have achieved proof of concept, and I may just need to continue with my current idea. If it doesn’t work, I may need to go back to the drawing board completely.
The level-order search algorithm seems to work fine, however, it did not fix the problem.
After much research, I believe I know what the problem is.
The quad tree part of the code may actually be working ok, the issue at the moment, I believe, is in generating the points in the correct order before feeding them to the quad tree.
I was using a simple loop of i and j values, scaling them, and projecting them to a sphere. However, this produces a range of values which traverse the entire terrain grid, so, if the grid has a resolution of 256*256, the i value will increment from 0 to 255 and then be reset to 0, j will then increment to 1, and the next row will be processed.
Since the quad tree is loaded in order from a list of points, this means that the quad tree is not being loaded with the correct points. I need to generate the points in the same order that the quad tree will be parsing them. So, I need to generate them in groups of 4. For example, for a resolution of 16 (4×4) I need to render the points in 4 groups of 4.
This is turning out to be very complex! I am having difficulty using a simple coordinate based system, and incrementing counters. I am also conscious of the fact that this system needs to work for all tiers, so for a resolution of 16 I need 4 groups of 4 nodes, but my solution needs to scale to a resolution of 64, 256, etc.
If this works, I should be able to get proof of concept, and I can then decide how to proceed from there.
Although it was harder than I thought, Oculus claimed that they were experiencing “Massive” load on their servers, and it was overwhelming their payment processors. That’s a good sign for VR!
It did mean that by the time I managed to complete my preorder, my ship date had slipped from March to April.
Eventually, however, I managed to secure a preorder for the rift using Firefox and Paypal, that combination seemed to work better than chrome and a credit card.
The bad news is that the total price (including shipping) for European customers (or as least the countries in Europe that Oculus ship to, it’s not available everywhere) came to €740! A lot more than US customers had to pay, although even they had to pay more than expected, few prospective customers thought the price would be more than $500.
Several twitter users have expressed concern that this price, combined with the very high system requirements, will serve to price the Rift out of the market.
I see it more as the cost of the early adoption of high-end VR tech. In a few years, with mass production, the rift will be less expensive, and Rift capable PC’s will be a lot cheaper. So, for a high introductory price, you are getting early access to what could be a whole new way of living.
There are some Rift competitors out there, but most of them aren’t capable of the same kind of immersive, realistic experience as the rift. Some of them are intended for mobile devices, for example. The rift is intended for not just realistic gaming, but alternative reality experiences, such as virtual work places, virtual teleconferencing, etc.
I also ran the Oculus Compatibility tool, and as expected, my new PC is more than capable:
I have made significant changes to the algorithms which I have been using to initialise and populate the quad tree. I now have the terrain successfully rendering using these algorithms.
Unlike the recursive system that I was using, these algorithms use “breadth first” or “level order” search, which means the first tier will be processes first, then the second, and so on. This is exactly what I want.
I am not certain how this will affect the efficiency of the system, but so far, I am only using the algorithms at load time, so it shouldn’t make much difference. I believe my current recursive algorithm should work for the run-time subdivision of the nodes.
I am currently rendering all nodes, for testing purposes, but I believe that I should now be able to run my optimised tree parsing algorithm without the difficulties that I was seeing before. I should be very close to proof of concept here, if everything has worked as I believe it has.
I believe I have correctly implemented the 3D to 2D projection code, however, it has not solved the problem.
After more research, I have discovered that there are two additional problems with the spherical terrain system. The first is that there is an issue with one of the nodes in each tier, I believe it is the first node. This node seems to have incorrect values, it seems to have the same values as the root node from the highest tier, meaning it is a single quad that encompasses the entire width and breadth of the terrain.
The below images show this quite well. The points themselves are being generated correctly, so the issue must be in how the points are being loaded into the quad tree, or more likely, in what order they are loaded.
The second issue is related. If the code was working properly, rendering the children from each node should produce a square, or a quad, shaped pattern. Ie, if I subdivide only one of the four nodes in the second tier, I should see it’s four children forming a square.
As the second set of images show, this is not what happens. I get four nodes rendering, which is correct, but they render as a line of three quads, and then another quad on another line. When I render all of the nodes, I get the correct spherical terrain output, but clearly, the nodes are being loaded in the wrong order.
This is almost definitely the cause of the render issues I was seeing. If the nodes are being loaded in the wrong order, then subdividing them based on distance will produce incorrect output. I hope that this will be an easy fix, and I will then be able to finally achieve proof of concept of this system.
Also, I have recently read about the “Teslasuit“. This is a full-body haptic suit created by a UK company that allows users to “feel” what is going on in a Virtual World. The suit uses Electro Muscular Stimulation, or EMS, to allow users to feel everything from “a cool breeze to the impact of a bullet”, according to a roadtovr.com article.
The suit will begin funding on kickstarter from January the 1st.
I have been researching the current issues that I have been having with the Spherical Terrain in some detail.
I believe that, basically, what is happening is that the distances between the player and each node are wrong.
Due to the way that the different levels of detail of the quad tree are created, some of the nodes from different tiers overlap. However, for my current algorithm, I am splitting each node within range of the player into its child nodes, and then further subdividing each of those child nodes if their (the child nodes) distance is also within the players view distance.
Theoretically, this should work, however, since some nodes overlap other nodes of different detail levels, the distance values are not correct, sometimes, for example, a node’s distance will exceed the players view distance, and will not be subdivided, but it’s childnodes will actually be within the players view distance, and so, should be subdivided. This, I believe, is the reason for the missing nodes in the spherical terrain rendering (visible in the below images).
To fix this, I believe I can use 3D to 2D projection, or 3D Projection. This basically takes a 3 dimensional point and projects it onto a 2 dimensional plane, similar to the “window to viewport transformation” that is done in the rendering pipeline.
If I make sure to project each point (parent nodes, child nodes, etc) into the same 2D plane, then I should essentially be able to convert a 3D problem into a 2D problem, and then get the 2D distance from the player to the point or node in question. It then shouldn’t matter if there is an offset between the points in 3D space, since they will all be “collapsed” essentially into the same 2D plane, and only their positions in the other two dimensions will matter.
I have found what seems to be a fairly simple implementation here: 3D Perspective Projection, but I have to do a lot more research to properly understand what is going on here.
If this works, I should, finally, achieve proof of concept for the Spherical Terrain, and I can then add the next steps to it (Massive terrain, texturing, etc) before I move on with the project.
I have not been able to fix the current issue with the Spherical Terrain Project. I feel that I am very close, but I cannot seem to get the terrain to subdivide correctly.
The below video illustrates what I mean. As the camera moves further away from the terrain, the nodes at the back should stop rendering. This happens to most of the nodes. However, some of the nodes are rejected from the render list incorrectly, such as a node in front disappearing from view before a node behind it.
This is the problem that I am having issues fixing. I will continue working on it for the time being, but I may not be able to crack this.
