I'm sure someone has already done something similar to this:
Using the basic focal length formula for simple 3d positioning of objects, I wanted a simple way to create a terrain. Creating a huge array of all the terrain points and elevations is tedious and time consuming. So, I thought, why not use a displacement map of sorts.
1-create a bitmap with a black background
2-draw an arial view of the terrain on the map, using an increase in the color value for each increase in elevation, so a mountain would be a collection of concentric circles with the color value increasing towards the peak of the mountain (topographical?)
3-when passing coordinates to the focal length formula, grab the pixel value of the bitmap at those coordinates and adjust the y value based upon the color returned, ie _y+=myBitmap.getPixel(x,z);
It seems to work great. Just wondering if anyone knows of any projects using such an idea, and if so, how does it perform under actual gaming conditions?
Last edited by JerryScript; 10-19-2007 at 12:56 AM.
This idea is called a voxel engine. They were popular in the days before 3d hardware. This style of engine is really well suited to 'low flying' games, as in a helicopter. Check out "Comanche: Maximum Overkill" for a nice example.
I'm not sure flash would have the speed you'd need for a convincing one, probably in AS3 you could do it.
The great thing about this system is you can make maps easily in photoshop using one bitmap for height and another with nice colouring and pre-rendered lighting.
I've written a simple voxel engine in the past in C, and have some quick and easy map making techniques down in photoshop, so if you want some nice maps to test out the engine or whatever, let me know.
I'd be really interested to see someone get a voxel engine going in flash.
Here's a couple of test bitmaps i had lying around that might be useful to you. Linked, because they are 1024 x 1024 each. One is for height, the other, colour.
I got a basic sample of what I was thinking of, attached is a zip with the swf and a txt file of the AS1 used. I imagine AS 2 or 3 would allow this to work quite well even with panning and origin movement. I will mess around with the concept more as time permits.
I'm new to this concept, and wondering do standard displacement maps always use 0x000000 to 0xffffff ? In my example, I'm using 0x000000 to 0x000010, but the code could easily be changed to use larger values and reduce them appropriately.
Last edited by JerryScript; 10-20-2007 at 02:58 PM.
Regarding source, this is really just proof of concept stuff, the code was rushed out in about an hour so it is terribly unoptimized (it uses 4 times the number of calls to getPixel() than it needs to) plus it is full of hard coded numbers. I might post some source later if I do a more solid version.
Basically, mine gets all its speed by not being a "real" voxel engine. The base grid positions are calculated at startup, so it just needs to add the height and colour.
Basically, mine gets all its speed by not being a "real" voxel engine. The base grid positions are calculated at startup, so it just needs to add the height and colour.
Very nice work there!
I just don't really see why you say it is not a "real" voxel engine. Having had a look at how they work basically you also precalculate the map data there in several blocks of certain level of detail for mip mapping and the basic priciples are probably the same. Since a voxel engine is not a true 3d engine it is pseudo anyways. Also if you draw with api or into a buffer, in the end its all the same and displaying your data through the viewport... so what makes yours different now?
This thread has gone way beyond what I originally was thinking of! Some very impressive examples that could be developed extensively.
I finally got a chance to work on what I was originally thinking of:
1- I create two bitmaps with perlinNoise, one for height mapping, one for color mapping
2- I render a perspective view by using the focal length formula and offsetting the y coordinate by the value of the height map, and setting the color with the color map
Note- steps one and two take up to 3 minutes to render depending on the size of the rendered cubes, to long for loading so....
3- I pass the pixel color values one row at a time to PHP/GD to convert the rendering to a PNG
4- I load the PNG and use the same perlinNoise height map to position objects via the focal length formula
Here are the sample files (the output to PHP/GD is disabled for viewing purposes), the Render example will take a long time and consume alot of resources! Render Pre-Rendered
Now I have to figure out a method for culling the objects. I'm thinking I can use the same perlinNoise function to create a set of masks, and set their layer such that objects going behind a hill will be masked appropriately. Any ideas for a better method?
Hi leechmaster, I say mine is not really voxels because traditional voxels use a single piece of height data and a single piece of colour data for each element on screen. Mine creates 4 sided polygons as basic elements, using 4 height data and one colour data per element, so it is some kind of weird hybrid pseudo 3d which borrows some techniques from voxel engines. The idea was to use the drawing API to smooth things out, so that a smaller amount of data can be looped through, basically to get around the slowness of huge nested loops in flash.
JerryScript, that is starting to look really cool.
For culling objects, I was considering making the ground out of a seperate MC for each row and let depth sorting handle everything.
But that's not really an option for you because your ground resolution is much higher, so your idea to use masks is better. You probably won't need a whole lot of masks, certainly not one per row.
As a sidenote, you've got me really interested in saving PNGs out of flash now, not being able to save output has always been a nuisance, but I never thought to do anything like that. Time to check if GD is available in my webhost's php setup.
something else for you to think about..
When making the color map, you can translate the results of your perlin height map into a more realistic palette by reading colour data from an image that is 1 pixel across and 256 pixels high, containing a gradient of the base colour you want for each height.
But it doesn't stop there, instead of 1 x 256, you could make the image 64 x 256, so that each height now has a range of 64 colors available to it, allowing you to add varying amounts of noise for each height.
This gives you basic coloring, which you can further modify with lighting by reading the surrounding pixels to determine slope.
My example also uses polygons, 2x2. I started with 10x10 and attempted to create gradients to smooth the color transitions, but averaging a four way color change into a single gradient is something I haven't worked out yet. If I can work it out, then I will switch back to probably 5x5 or larger and attempt real time rendering (probably need to use AS2 for speed).
Just a thought here, with PNG transparency, aren't your possible color variants 256x256x256x256? Even if you don't use the alpha channel in your final colors, it's value can be used to store offset values such as slope details for the color shifts etc, or am I on a wild goose chase with this idea? Kinda like turning the alpha channel values over your 5x5 pixel spread into a matrix? That's a lot of potential data storage!
My main concern is to keep the rendering simple enough that the rest of a game/app's processing requirements aren't hindered. I would KILL for a flash player that supports a perspective skew!
--A note about saving PNGs via GD. I don't recommend it on a production server. Regardless of the way you split the load, GD will bog down a server. I use a local Apache/PHP setup and send one row of pixel values at a time, and even locally, it still takes up to 3 minutes to create the PNG. Another back-burner project I keep in mind is porting some level of PNG compression to AS, but that is a huge undertaking.
Last edited by JerryScript; 10-27-2007 at 09:08 AM.
Hey... if your final result is a game that uses a large pre-rendered 3d stage with stored height information that effects gameplay, you may want to check out Bryce for the creation & rendering of your stages.
It allows you to manually enter camera position and rotation, so it should not be too hard to line up images rendered in Bryce to the height data in game, and it also does depth rendering, ie. white is close to the camera, black is far... you could autotrace such a depth render in flash and split it into MC's to build your masks.
I dunno, maybe that takes some of the fun out of creating everything from scratch, but the end result would look superb.
Bryce v5.5 is available for free at download.com (current version is 6)
Reply With Quote
Originally Posted by slight
