Fractal Generation System

[mkruer]

I suppose that these results could be achieved by just skipping the subdivision of some facets earlier on during iteration. It could result in some very strange results though; very flat triangles in the terrain.

Another problem that I can see with this approach is that you can no longer use a tristrip to render the planet. That'd be a performance hit

What I am trying to do is set up a primary level of disturbance that everything else is generated off of. This macro level of disturbance will be responsible for the generation of the main landmasses. I know in many ways this is what is already happening, but I am trying to figure out ways of creating more consistent results. If you notice the fractals tend to bunch together forming one huge landmass, instead of several smaller ones. The other extreme is that it creates way too many small islands. Either way this is not very visually appealing IMO.

This attachment is supposed to represent the primary level of disturbance. Darker the lines the deep the initial starting point for the vectors.

[richard]

Ah, righto. That's be easy enough to do for the cases you care about. You wouldn't want to have do it for *all* planets though. If you've run my system generator python code, then you'd know why (so many moons :)

Another problem that I haven't thought about until just now is generating the skin for gas giants and airless planets/moons (ie. crater generation after the landscape generation). Probably not too hard though ;)

[hurleybird]

Couldnt you just get crushed by the gravity when you get too close to a gas giant?

[zaydana]

nah... i don't think so. If we are using anti-gravity to get around places, i'm sure we can use it to go to the sun's center if we really want. I mean, the only problem then would be heat dissipation, since energy would be quite easily taken care of in an environment with that much gravity

[richard]

I really hope that there's going to be atmosphere processing stations in gas giants!

[mkruer]

Ok cool, the main reason why I want this is because I have a planet for my Rylix project that I need specify items to appear in certain location. The next step in this macro POV is then to adjust the map for tectonic shift. This factor should effect all planets ~0.8 Earth Mass. (Mars had this same process in its historic past, however due to the small size of the planet, the tectonic shift ran out of gas. in comparison, mars is more like your current fractal. Now if you go over to Venus, you will see the height maps is radically different. This is because the tectonic shift appears to still be going on, and more importantly there is no erosion.) So the idea for the tectonic shift is not to move the land masses, but rather designate the areas where the plates buckle. The easiest way I think to do this is again go back to the macro view of the grid, and create rifts. These cracks would go over the planet and with some stretching and buckling would create the mountain ranges, and rifts. The more extreme the shift, the higher the mountains, and lower the valleys will become.

So right now there are two layers, the landmass layer and the tectonic layer. The only one remaining is the Biome layer for textures for terrain planets (BTW FYI when I say terrain, I am talking about earth like planets)

On other news I need to sit down and tweak your system fractal. I find it very unlikely to find a wet planet at 96au from a small star. LOL

[richard]

There's been other efforts to use tectonic approaches to generate more realistic planet surfaces. And the passing filters over the results to simulate erosion. Erosion's a bugger though, to get even close to realistic.

Here's some more interesting notes (note the bit about refinement):

http://www.cs.berkeley.edu/~rcdavis/cla ... rview.html


Also, note that my system code ain't fractal, it's just random with lots of rules. It does have code in it to specifically make sure that if it says "wet planet" then the planet's in the non-freezing band ringing the star. It also makes sure that the atmosphere will keep the planet from freezing (and indeed a planet can be further from the sun and still wet if it's got a nice thick atmosphere). Finally, just because the star's small doesn't mean it's not really, really hot ;)

I don't recall where I got the source info for the system generation stuff from. I did just find this though, which might be interesting:

http://www.users.zetnet.co.uk/trisen/sol/2300ad/wg/

[edit: clarification of system gen para, added additional reference at end]

[mkruer]

I think that erosion is way to complex for any real time rendering, however if you generate the tectonic distortions i.e. ripples and add it to the generated surface, this should be much more doable in real time. The only thing to do is give it a try. In my minds eye what you are doing is creating two simpler fractals and then adding them together.


Still sound like im full of it?

[Guest]

http://snork.home.texas.net/jason/tep/

[edited by richard: odd, thought I was logged in when I posted this...]

[mkruer]

Yep thats more what I am looking for. And with todays Processing Speed, we should be able to make it ever better.

[captnemo]

Finally, just because the star's small doesn't mean it's not really, really hot

If realism is the goal, then yes it does. Small stars don't have as much compression in their cores, so they can't maintain as high a rate of fusion, making them cooler redder, and dimmer.

[richard]

Depends on how you define "small". I presumed when Matthew said "smaller" he meant smaller than say a red giant. I guess it would've been better if he'd quoted the actual star present in the system :)

I'm not an expert here, I'm just working from my own understanding of the H-R diagram and various tables relating stellar classification and temperature.

See a Hertzsprung-Russell diagram for specifics (there's one in the wikipedia page on stellar classification http://en.wikipedia.org/wiki/Stellar_classification ). Sol is in the middle of the plot (being a very average star ;) and they get hotter and brighter (and gradually bigger) as you head up and left. Down and right are smaller and cooler.

[jackS]

well, as for size data we only have 3 categories in our data set: dwarf, unremarkable, and giant. For color/temperature, we do have OBAFGKM 0-9 for a few thousand stars, everything else is, of course, faked, but I believe that we fake it in such a way that we still bother to generate random values for stellar classification. We do not currently denote multi-star systems as being different from singletons, as that data was difficult to glean from our initial data source.

[richard]

Ah, my system generation code will generate systems with stars across the whole range of sizes.

The multi-star (companion star) generation code is currently commented out. It's been too long since I looked at the code, but I believe it was generating invalid orbits as there's no code in there to check for stupid orbits in that situation.

It's just come back to me - the code is based mostly on the tables from Traveller. As it turns out, there's a new sf.net project to encode the Traveller stuff in a C library: http://travtrack.sourceforge.net/travlib/reference/ It doesn't look like they do actual generation of the systems, just handle existing data. I've tweaked the methods as given in the Traveller books so they're a little more sane (the books are constrained by dice and by making the generation less tedious than it could be :)

[etheral walker]

I found this program, http://www.witchspace.com/landscape.html
seems really good

[richard]

Here's another landscape rendering engine: http://frustum.org/3d/

Dynamic shadows from the terrain elevations could be made with the use of horizon textures. There is an huge infinite terrain in this demo (~100000 triangles per frame) with dynamic shadows (it could be turned off ), light scattering effect and brightness/contrast regulation.

Source available right there. Note that it uses shader programs.

[Guest]

Anyone intergrating any code?, Let's bring this to reality

[mkruer]

I think I am speaking for everyone when I say we are all more interested in getting it working correctly, then quickly. If it does not make it into the next release (which is highly likely) then it is not a big issue. There have been more the enough other fixes and other add-ons to keep everyone’s interest in the meantime.

[richard]

Yeah, personally the first things I'll touch on the C++ side, assuming I can figure them out:

• making the targetting box not be smaller than say 10 pixels across (ie. not disappear ;)
• making the map display zoom and pan

They're so much higher on my list of things to do that landing on planets :)

[mkruer]

Pointless Rambeling: I forget where I saw this, but one of the ideas for speeding up a land terrain rendering systems was not to render distance objects in high res. Basically making it so every poly has to be a certain minimum size of screen.

[dfryer]

Rendering far-off objects at lower detail (LOD) is something that a fractal generation system (or any decent procedural geometry generator) should be good at, since the level of detail would be a parameter of the algorithm.
Many people have fiddled around with realistic world-terrain systems, I was wondering if anyone had given any thought to procedural generation of bases (i.e. the positioning of buildings, landing pads, etc.) or other man-made structures. They're usually not quite so "fractal" in nature.
Also, if VegaStrike is going to employ fractal/procedural techniques which use a seeded pseudo-random number generator, has a random number generator been standardised upon?

[richard]

Python ships with a standard random number generator (based on a Mersenne Twister core generator).

That means it generates consistent number sequences given the same seed across all its target platforms.

Hooking that into VS should be a doddle. It's a C module too, so it's not going to be too slow.

[hellcatv]

we already have a great random number generator in vsrandom.cpp
it's a lot faster cus it's in pure c++ so you don't get any of the call barrier stuff

we can use the python guy from python--sure

[richard]

we already have a great random number generator in vsrandom.cpp

Ah, cool. I s'pose I should've poked into the source first, sorry! :)

[richard]

I just tried out the Ranger downloadable demo (http://web.interware.hu/bandi/ranger.html) on my computer under WinXP (source is Windows-specific, and I have not the clues to translate it to Linux).

My box is an Athlon 1900 with a Geforce4 440MX. Unfortunately, the demo decided that my card was *not* a Geforce3 or better - probably due to some query for a specific OpenGL feature that failed. So on my box the demo defaulted to the wireframe mode.

Anyhoo, the demo itself was still quite impressive. I was able to zoom around the landscape and even in wireframe the thing's pretty impressive. There's also a complete control over the level of detail shown, so I could crank it way up to max, and IIRC I'd get about 10fps viewing the entire (the *entire*) map. But I could then just scale that back until I got 60fps or so. Then when I flew into the map I could crank the detail back up. I'm sure it wouldn't be too hard to actually lock the LOD into the currently rendered fps...

In the wireframe mode, it's more obvious (ie. educational ;) to see the actual subdivisions coming and going.

I really want to get the texturing going though...

One downside was that it took a long time to convert the input data (representing 160km x 160km) but it only did this once. 160x160 isn't that big though... and if we're going to be doing this on a *planetary* scale...

Then again, if the routines we use to *generate* the landscape data (rather than convert from some heightfield image) are fast enough, maybe this isn't going to be a problem...