Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SpaceFlight]

Are you asking if multiple planets will be supported? The engine is meant to support traveling between planets, each planet having its own definition, be it heightfield-based or generated algorithmically.

Wow, this sounds pretty exciting

be it heightfield-based or generated algorithmically.

Excuse my question, but what is the difference between these two methods ?

[cameni]

be it heightfield-based or generated algorithmically.

Excuse my question, but what is the difference between these two methods ?

Height field based planets are those for which you've got global elevation data defining the shape of terrain in some resolution, say in 90m or 1km raster, which the engine refines down to centimeters. Additionally the engine will use other datasets such as climate maps to generate the planet.
This approach will be used for Earth and other bodies for what we've got some data, like Mars and Moon.

On the other hand, planets could be generated procedurally from scratch, basically from a single random number seed. In this case (in Outerra) the process will work by employing a generator in place of the external planetary data. The generator will mimic the characteristic patterns of topographic features on a planet - continents, mountain ranges, water drainage networks, volcanoes etc. generating them randomly but keeping them believable and natural for given planet type.

Obviously, these two approaches can be also combined. With procedurally generated planets you could still want to influence the shapes of the continents or to place/move the mountains or to define the climates so that it all lines up with the game setting. You should be able to mod specific locations by smaller height field patches as well.

[SpaceFlight]

Thanks for the detailed explanation.

[C. Shawn Smith]

On the note of heightfield data in the required format, I'm currently working on a photoshop tutorial that attempts to "fake" heightfield data at more or less 1km per pixel.  I won't know how well it will perform until Outerra gives us that ability, but it should get you in the ballpark.

The image in this thread shows a sample.  The original is a 4096x4096 16-bit greyscale image.  The island continent shown is approximately 1/4 to 1/2 the size of Australia.  Basically, I took an original color map I created using this technique as a baseline, then overlayed various greyscale colors to get "basic" heightfield data, and then use various cloud filters amongst others to try to make it a little more variable.  I also use a greyscale version of the original map to give a few extra features, namely for mountain regions.  The custom heightfield data more or less works in Lightwave, although refining it down to the cm level like Outerra doesn't work quite as well.  Not to mention the render times are horrendous.

This is only one sample of an image I created in Lightwave using the heightfield data:


I think this one is about 1+km above the ground plane


This one is at typical human eye-level, looking off to the horizon (no fog effects enabled, so it's hard to sense the scale)


The mountains in this image are about 5km away, I think (I'll have to go back and check my maps to be sure)

Regardless, even with the bad renders here, it's close, so hopefully Outerra's refinement will make these images really shine

Too bad that ability is still in the distant future

*Edit* Public Facebook links not working ... will fix in a minute
*Edit2* Fixed distance

[C. Shawn Smith]

Hmm, on this same note, Cameni, what method do you use to compress your current height field data?  After considering just how big a planet is, and considering my 1km per pixel height map, I'm realizing that there will be a LOT of Photoshop/raster images just to make a single viable planet .

(This question would probably be better served in a separate thread or on a different forum)

[cameni]

The compression is based on decomposition to wavelets and using a entropy encoder on it. It also obeys certain rules the engine imposes on it; in other words it cannot be easily produced outside the mapper/encoder tool. The tool was made for the purpose of mapping and compressing elevation (and other) data, but at the time it's not very sophisticated and very slow.

1kmpp is also a rather low resolution; the fractal noise is tuned for finer ones, there will have to be another intermediate stage that can make terrain features in that range.

But I was thinking about providing a set of tools within the engine or in a separate application, aimed at planet creation, that would automatically compress the data so that the storage is compact. It will have to wait until we progress in stuff essential for our survival, but it could be a nice addition even for that. For example, adding an island to Pacific. Or Atlantis. Originally I thought we could do a this kind of application, a world builder, instead of the game, but a game will reach wider audience.

[C. Shawn Smith]

Hmm, if that's the case, that could also explain the problems I encountered in my Lightwave model as well.  I originally thought it was the mesh not having enough geometry, but I'm beginning to think it might have been a combination of both (1km/p + mesh density).  I'll have to run a few tests.

On a personal level, I know I can chop that image into pieces and upscale them appropriately to get better resolution, but trying to map that to a dense, triangulated mesh in Lightwave is a pain in the proverbial arse  :/

My main goal in creating the tutorial is to help 3d artists generate highly detailed custom terrain.  Depending on how the Outerra planetary builder tools work when and if they're done (I know you want to do it, but I also understand it's low priority , I could probably alter the tutorial a bit once I understand the underlying height field architecture of the engine.  That should be a fun little project when the time comes

[cameni]

Depending on how the Outerra planetary builder tools work when and if they're done (I know you want to do it, but I also understand it's low priority , I could probably alter the tutorial a bit once I understand the underlying height field architecture of the engine.

It's not exactly a height field architecture, only the input data come in form of height fields. With the tools for direct manipulation of terrain the height fields will go away entirely, except maybe for smaller localized patches imported from other programs.

[C. Shawn Smith]

Ahh, I think I see.

Guess I'll just have to be VERY patient then  It's fun speculating on the build though