Slashdot Mirror
Fit An Entire Planet In 90k
missingmatterboy points out this "interview with Dr. Ken "Doc Mojo" Musgrave, a computer graphics pioneer who worked with Benoit Mandelbrot generating fractal landscapes and who's designed custom shaders for Hollywood movies. His latest project is called MojoWorld and it uses the power of math to generate infinite-resolution fractal landscapes? one entire planet at a time. It's going to have an open SDK and, to top it all off, a Linux version is also in the works." This is a fascinating project.
Here's the Google cached copy (which isn't doing much better)
If you have to see the images, BryceWorld got a beta release and posted a gallery of images online.
And if you want to download it immediately to start playing with it, you can do it by filling out this questionairre
I am disrespectful to dirt! Can you see that I am serious?!
This has been done quite a few times by quite a few people. Fractal planet 3d engines show up all the time at www.flipcode.com
I've seen some with complete weather and day/night cycles. Some really inspiring stuff.
Planets would move, trees would grow, forests and deserts would change shape, oceans would rise and recede, etc. (Taking into account that the planet is of the type to support something like forests and oceans). The variables that define a "place" as a human looking onto the universe were coordinates and time, and a perspective (direction/angle) from which to project back information. Yet the visual perspective was only minor compared to the actual number of calculable variables, like temperature, and the like. Of course, strange things like density has to be accounted for with Newtonian physics, but that was ironically easy. Choosing what was the cause (is temperature random, ie. fractalish, or a product of Newtonian; really it's a combination; random in a Newtonian'ish thermodynamic space, but random only because we wouldn't actually want to calculate that sort of thing) and what was an effect was the hard part.
It is an interesting premise, isn't it? Taking a mathematical curiosity (the fractal) and doing something useful with it like creating a universe, or planet in this case. Somewhat matrix'ish.
...he took real pride in his fjords, he wouldn't take too kindly to auto planet creation.
I'm the big fish in the big pond bitch.
is volumetric pixels this sort of thing ?
fractals are good for storeing large amounts of information but decompression is hard and how do you then represent the information useing standard methods or volumetric pixels type approach ?
seems nice but I would like more details before makeing any jugment
anyone have details ?
regards
john jones
p.s. I am sure a game used this type of thing before
I've just checked out the sample mojo-world gallery (I'm a sucker for any web pages that claims to show me (almost) photo-realistic rendered terrain images) and while the output is quite cool, it still has ways to go before it's going to be photorealistic. On the other hand, the point of MojoWorld is that you don't need a lot of data to re-create your scenes: you just save the seed parameters (which are tiny as compared to a real height-field) and the engine re-creates the scene from these parameters.
I have been working on terraform (which is aimed more at the generation and manipulation of digial terrain rather than the rendering of it) for a while now and in the course of doing so have learned a few things about fractal terrain generation. The fact that you can regenerate the terrain from a few seed parameters is not that special (dimension, scale factor, random seed, etc); these are the kind of parameters that are typically passed to these functions anyways. The more interesting thing (to me) is that they have apparently found a compact representation of all the data needed to create a (semi)realistic scene from it. All in all, I think this is quite cool. Hopefully they (at some point) will write a white paper detailing some of the algorithms used by the (closed source) generator.
Smooth may be defined as:
- function: all genotypes code for valid phenotypes
- injective (compact, nonredundant): different genotypes lead to different phenotypes
- surjective (universal): all phenotypes are representable
- continuous: small variations in the genotype produce small variations in the phenotype
- inversely continuous: small variations in the phenotype can be induced by small variations in the genotype
Where genotype refers to the parameters and phenotype to the representation of the world.If this were true, then one could theoretically evolve (using GA techniques) a planet that is a reasonable facsimile of earth, or any other feature set. Want a detailed map of San Francisco Bay? Let me squirt my survey through my Genetic Algorithm MojoWorld Compression Algorithm. Oh good, it's done. Use these five numbers to recreate the map...
Hmmm... sounds like it's plausible, but I don't think that small changes in the genotype necessarily result in small changes in the phenotype.
I am disrespectful to dirt! Can you see that I am serious?!
Hmmm, an Elite game which uses fractal planets?
What about, for example, Frontier: Elite2 which pretty much pioneered planet wide fractal terrain gen in a commercial game and ran on a 386.
Or, its sequel, Frontier: First Encounters which added texturing to make everything look a million times more ugle.
Or any of the recent fan-made clones, Millenium3 http:://m3fe.com or even The Eternal Project http://compsoc.net/~flend/tep/.
On the related note of fractals and their generation; A few years ago while playing around with GWBASIC (!!!) on a Tandy 1000 Color I discovered you could generate sierpinksi gadgets (there's a picture of a 3D one that I managed to find at http://www.angelfire.com/mo3/mysteriesofscience/ga mes.html) by choosing 3 coordinates on the screen (for the vertices) and then choosing a random point somewhere else. Then, choosing between 3 random numbers (or anything that has 3 equally probable events) and plotting the point halfway between the current point and the vertex corresponding to the chosen number, a sierpinski gadget slowly "fades" in.
To make it look even better, you can choose a color for each vertex. I also found you can do similar things with other shapes (pentagons, squares, etc.) Perhaps this algorithm is a well known way to generate the Sierpinksi Gadget. The amazing thing is how *small* the code is!
pseudocode (possibly with mistakes...its been a while)
Sierpinski
Choose 3 equidistant points on the screen: {x[0],y[0]},{x[1],y[1]},{x[2],y[2]}
Choose random coordinate on screen (x,y)
while no user input
choose random number n from {0,1,2}
plot ((x+x[n]/2), (y+y[n])/2))
loop
Cheers,
jw
"Has anything you've done made your life better?" - American History X
Musgrave is also extremely annoying in the way he dismisses enhancements as trivia and gives the impression that he's done the hard work. He hasn't - he's done the easy bit. For example placing vegetation on his landscapes is a very, very hard problem. Lets see him place a forest of oak trees besides a river, with realistic rendering of sunlight through the leaves, the roots in the soil, and the shadows of the leaves on the ground then I'll be impressed.
There are packages that are attempting to do this - World Construction Set, WorldBuilder and GenesisII come to mind - there are many more (including the granddaddy of them all Vistapro). None look as realistic as Terragen though - again something that can probably be ascribed to the fact that terragen, like Mojoworld, chooses a particular type of landscape in which to work. Unlike Mojoworld though, Terragen is photorealistic.
Creating a general-purpose photorealistic terrain renderer is probably on of the hardest problems still available in computer graphics. And while Musgrave deserves respect for what he has achieved over the years, sadly he's one of those people who simply isn't as good as he thinks he is.
Elite used Fibonacci Numbers with a eight 6-byte seeds, plus a few dozen bytes of look-up tables, to achive this. The principle was very similar to MojoWorld's use of fractals, but Fibonacci series are considerably quicker to process, particularly on an early 80's home computer.
Andrew Oakley - www.aoakley.com
Generating a simple fractal landscape is both an easy and a difficult process. The algorithm is relatively easy - it is the implementation that can be difficult.
It is possible to implement a fractal landscape generation system on using only 2D graphics, which produce an image that looks amazingly 3D in scope, but isn't. Of course, it is possible to do the same algorithm in a 3D coordinate system.
I came across the 2D method first in an old Creative Computing article from around 1983 (the issue was the "graphics" issue, and in addition to the fractal mountain code done in BASIC for a couple of systems, there was an article that detailed making photo masks and combining computer graphics and real photo techniques to produce cool effects for the time - today, photoshop works wonders). The BASIC code was for a PCjr (IIRC) and an Apple IIe, but I converted it to my TRS-80 Color Computer - and it ran fine (though very slowly).
Essentially, the process is:
1. Select three random (X,Y) points on the screen - these form the "base" triangle.
2. Find the midpoints of each side of the base triangle. Split each side in half (subdivide it), and move the midpoint up/down by a small random amount (in the Y direction on screen), and join the points - the deformed triangle should now be composed of 4 sub-triangles.
3. Repeat the process on each of the resulting sub-triangles n-times.
Of course, n tends to be a small number - around 7-10, depending on the resolution of your output device. There is also a way to add "water" by deciding on an certain "Y" level to disallow drawing of "land", instead showing "water" (where "land" is green, brown, or grey, and "water" is blue).
That's the basic algorithm, and the hard part is keeping all the sub-triangle's vertices joined, so that when one is shifted up, the adjoining triangle's vertex shifts up as well. In the Creative Computing article, this was accomplished with arrays and really complex code that wasn't explained too well. Today, you would probably use a combination of linked-lists of objects (where each object represents a vertex), and of course a recursive function system. It would end up being more of a memory hog, but it would be easier to code as well.
Taking the algorithm into the 3rd dimension would be easy, since you would plot the base triangle on the X/Z (or X/Y) plane, then as you went through the subdivision process, you would simply change the height of each vertex in the Y (or Z) plane respectively.
Reason is the Path to God - Anon