|
|
| Landscape Prototype | ||
 |
||
| Previous Image | Next Image | ||
|
Description: 13 years after the idea, I have gotten round to making a prototype to render landscapes. It is far from finished, of course, and renders very slowly. Next step is to convert the AMOS prototype into C++... Picture Stats: Views: 1862 Filesize: 19.49kB Height: 768 Width: 1024 Posted by: benJamin at March 29, 2007, 11:50:40 AM Image Linking Codes
|
||
| 0 Members and 1 Guest are viewing this picture. |
| darksun9210 Posts:1319 | December 18, 2008, 03:46:41 PM .... one day i'll get there.... one day.... :-) |
| Karlos Posts:16879 | March 31, 2007, 10:45:18 AM My version was so slow simply because it was doing lighting based on the point normal at each point on the source data. I got around to adding water and experimental reflections too. I'll see if I have any screenshots to put up. Much more recently, I tried "realtime" voxel rendering using a 3D card. If you imagine calculating your fractal again, what I did this time was to use the 8-bit greyscale to lookup an RGB value and combined it with the greyscale value by putting the greyscale value in the alpha channel. The resulting 32-bit pixel data was then used as a W3D_Texture and applied to a quad on screen that was rotated axonometrically around any angle (in other words, opposite edges were always parallel on screen). When rendering this, I had alpha testing turned on so that only texels with an alpha value above a certain threhsold would be passed. Since the alpha value was derived from the "height", this basically renders a slice of your terrain where only the points considered to be "above" the slice are visible. In order to construct the relief, all I had to do was repeat the process with as many times as desired, increasing the alpha test value for each iteration whilst simultaneously moving the quad along it's rotated "z" axis (which translated to vertically upwards on screen since I didn't use any pitch or roll, only yaw). Only the slow texture fill rate of my graphics card was the let down, in all other respects the rendering was realtime, the entire projection could be rotated. |
| benJamin Posts:226 | March 30, 2007, 11:01:45 PM I don't think my 'lighting' is what's slowing things down. After all, the light-source is fixed, as is the colour palette, so I use a series of 2x4 if-elseif-else statements to modify the brightness of the original colour (8 different terrain types x 4 light 'directions'=32 colours). Typically, we're looking at: * 4 minutes to generate the terrain; * <20s to select terrain types according to rules and a bit of chaos; and * 4 minutes to render the terrain. (You can see there is still an error in the terrain wrapping. I hope to figure this out during the port to C++). |
| Karlos Posts:16879 | March 29, 2007, 08:37:13 PM Ah, I remember doing something a little bit like this once, way back when I first started learning C. I used a tweaked "plasma" fractal generator to generate the raw data, which was for all intents and purposes an 8-bit greyscale image. This data was traversed in a diagonal sense, each "pixel" being used to lookup a height/colour pair. On screen, a vertical line segment was drawn, the height being the first looked up value and the colour the second. The diagonal traversal of the source data translated into a left->right traversal on screen, successive traversals moved the starting "y" coordinate on screen, giving a nice isometric rendering of the source data. I did get around to a version that had lighting, but by then it was dog slow too :-) |