| View unanswered posts | View active topics |
It is currently Mon Feb 06, 2012 10:04 pm |
|
All times are UTC |
This section is under re-development. It is not finished, and not fully functional. The current
development stage is pre-alpha and as such, not every feature is even implemented yet.
Options
Planet-Black0psGeoMipMapping
Started: 11th October 2008
I had been thinking of how to go about this for a while – it is something I was never inclined to look into using tutorials. Previous 'experience' with this subject has only gone as far as a brief "it needs to render less detail the further away the terrain is from the camera". The quadtree algorithm gave inspiration, but I will get onto that later – for now I just wanted to see if the idea worked, THEN quad tree's can come into it when i'm satisfied. As it write this, so far it seems to have worked almsot spot on how I imagined it to.
The idea was this – divide the heightmap into a series of 'nodes', each of which would be responsible for the height values they contain.The further each respective node is from the camera, the less detail it needs to worry about.
If that sounds familiar to concepts in books that is because it is. Seriously, this is a situation where anyone with some form of experience will come up with similar, if not the same idea. I am by no means claiming I invented this idea – all I am trying to say is that this is the idea to go about it that came to mind.
1st attempt
The first attempt involved a lot of numbers and offsets into the grid. I spent some time in front of a white board drawing out what I had pictured in my mind – a large grid of 6x6 nodes with different resolutions of triangle strips depending on their distance from the camera. Each node was given a coord at each corner, and each patch was given an X and Z coord at each corner. A lot to draw, but it probably saved off all sorts of time trying to re-imagine the numbers and offsets in my mind.
The loop to fill the node data was too much for what it should be. I tried adding each height value to each corresponding node, so that rendering would require looping over each node, then looping over its patch coords with no possibility for a node to overlap its neighbour. Again, too much for what it is, and an added frustration was that collision detection would have had to loop over all nodes to find the height values.
2nd attempt
Much better. A struct full of the height values, texture coordinates, colour values, etc. This was filled up as before with the bruteforce terrain. The nodes would simply reference this array of structs with an index into the height values struct. Filling up the node data was just a case of dividing the terrain size by the (configurable) patches-per-node value, so that we are left with a count of nodes (for both X and Y). Then, each node is given an id, its centre coord calculated, and an x and z start (which is used in the rendering code to offset into the height value array to get the correct coords).
With that done, rendering the terrain was straight forward. Loop over the nodes, and use their x/z start values to offset into the height values, to plot each height value.
Amongst rendering, we check to see how far away the camera is from the current node – if it is greater than a (configurable) threshold value, we reduce the detail level (by a multiple of 2) so that the rendering loop skips over some of the height values. The further the node, the more we reduce the detail level.
What we are left with is a 1024x104 terrain which displays suprisingly similar to a bruteforced version, but with much more FPS. We are also left with 'popping' terrain, and cracks. Damn.
This is where the id's come in. Each node is supposed to be able to refer to its neighbouring nodes. The node struct contains an up, dn, lf, rt value which links to its respective neighbours. This will (hopefully) allow us to easily check neighbouring nodes for their level of detail, and (somehow) blend the triangle strips so that the crack is eliminated.
Anyhow, progress shots:
(Stage 1 - Nodes and indexed vertices loading fine)
(Stage 2 - Heights added)
(Stage 3 - For test purposes, rendered a vertical line at each node's centre coordinate)
(Stage 4 - Errornous attempt at adding detail levels to nodes)
(Stage 5 - detail levels fixed - before... (see next image))
(Stage 5 - detail levels fixed - after (yes, I am aware its only applying to the one column of nodes at the moment))
Proposed Improvements
-Fix distance checking - only first row seems to be changing detail
-Implement neighbour checking, and avoid rendering height value which the lesser detailed patch does not render
-Investigate detail 'popping'
I had been thinking of how to go about this for a while – it is something I was never inclined to look into using tutorials. Previous 'experience' with this subject has only gone as far as a brief "it needs to render less detail the further away the terrain is from the camera". The quadtree algorithm gave inspiration, but I will get onto that later – for now I just wanted to see if the idea worked, THEN quad tree's can come into it when i'm satisfied. As it write this, so far it seems to have worked almsot spot on how I imagined it to.
The idea was this – divide the heightmap into a series of 'nodes', each of which would be responsible for the height values they contain.The further each respective node is from the camera, the less detail it needs to worry about.
If that sounds familiar to concepts in books that is because it is. Seriously, this is a situation where anyone with some form of experience will come up with similar, if not the same idea. I am by no means claiming I invented this idea – all I am trying to say is that this is the idea to go about it that came to mind.
1st attempt
The first attempt involved a lot of numbers and offsets into the grid. I spent some time in front of a white board drawing out what I had pictured in my mind – a large grid of 6x6 nodes with different resolutions of triangle strips depending on their distance from the camera. Each node was given a coord at each corner, and each patch was given an X and Z coord at each corner. A lot to draw, but it probably saved off all sorts of time trying to re-imagine the numbers and offsets in my mind.
The loop to fill the node data was too much for what it should be. I tried adding each height value to each corresponding node, so that rendering would require looping over each node, then looping over its patch coords with no possibility for a node to overlap its neighbour. Again, too much for what it is, and an added frustration was that collision detection would have had to loop over all nodes to find the height values.
2nd attempt
Much better. A struct full of the height values, texture coordinates, colour values, etc. This was filled up as before with the bruteforce terrain. The nodes would simply reference this array of structs with an index into the height values struct. Filling up the node data was just a case of dividing the terrain size by the (configurable) patches-per-node value, so that we are left with a count of nodes (for both X and Y). Then, each node is given an id, its centre coord calculated, and an x and z start (which is used in the rendering code to offset into the height value array to get the correct coords).
With that done, rendering the terrain was straight forward. Loop over the nodes, and use their x/z start values to offset into the height values, to plot each height value.
Amongst rendering, we check to see how far away the camera is from the current node – if it is greater than a (configurable) threshold value, we reduce the detail level (by a multiple of 2) so that the rendering loop skips over some of the height values. The further the node, the more we reduce the detail level.
What we are left with is a 1024x104 terrain which displays suprisingly similar to a bruteforced version, but with much more FPS. We are also left with 'popping' terrain, and cracks. Damn.
This is where the id's come in. Each node is supposed to be able to refer to its neighbouring nodes. The node struct contains an up, dn, lf, rt value which links to its respective neighbours. This will (hopefully) allow us to easily check neighbouring nodes for their level of detail, and (somehow) blend the triangle strips so that the crack is eliminated.
Anyhow, progress shots:
(Stage 1 - Nodes and indexed vertices loading fine)
(Stage 2 - Heights added)
(Stage 3 - For test purposes, rendered a vertical line at each node's centre coordinate)
(Stage 4 - Errornous attempt at adding detail levels to nodes)
(Stage 5 - detail levels fixed - before... (see next image))
(Stage 5 - detail levels fixed - after (yes, I am aware its only applying to the one column of nodes at the moment))
Proposed Improvements
-Fix distance checking - only first row seems to be changing detail
-Implement neighbour checking, and avoid rendering height value which the lesser detailed patch does not render
-Investigate detail 'popping'