Development:Orbital Planet Surfaces

General

This page summarizes concepts and approaches to creating planet surfaces as seen from orbit. Topics of atmospheric entry and close-to-surface planetary topology and atmospheric effects or planetary flight should be covered in a separate document.

Two main topics are covered in this document:

• Development of textured surfaces
• Development of procedural surfaces

Textured Surfaces

Texture Requirements

Generic Image Requirements

Please read this Development:Graphics_Requirements page before continuing to the specific requirements.

Summary of Texture Requirements

Textures ready for submission should fulfill:

• Codec: dds DXT1 with mipmaps for diffuse textures; dds DXT3 with mipmaps for citylight textures
• Extension: .texture
• Ratio (horizontal:vertical): 2:1
• Size: following the POT rule (power-of-two)
• Resolution: min 2048x1024
• Tilable (seamless): horizontally and vertically
• Quality: RQ or CQ

Image Resolution, Formats, and Quality

The planet surface graphics format currently recommended for the game is dds format with dxt1 compression, with filenames ending in .texture. (Before May 2008, DDS textures were stored in files named .png, because of references to filenames in other places.)

The image ratio horizontal:vertical must be 2:1 (assuming pixel ratio of the map is 1:1), since the texture is wrapped around the planet sphere horizontally around 360 degrees and vertically around 180 degrees. Necessarily, in order for the surface not to appear distorted, your pixel ratio of the generated texture must be 1.0, i.e. a circle must show as a circle when viewing the texture in an image viewer, on a monitor with square pixels.

The vertical and horizontal sizes should be a power of two (POT). Really, NPOT (non-power-of-two) textures are possible, but really, really, really troublesome. Don't use them. Just use POT. Love the POT. The POT is the mother, the POT is the father. Trust the POT.

That leaves few options:

• 1024x512
• 2048x1024
• 4096x2048
• 8192x4096

Keeping original high resolution image (e.g. 8192x4096 or 4096x2048) versions in stock helps maintaining quality and scalability as game development progresses or typical screen resolutions rise in the future with better hardware available to the players.

Most of the surface textures included in data have a horizontal resolution of 1024 or below. Committed textures are classified as:

• DQ - Development Quality: textures with horizontal resolution of 1024 or below and low degree of realism
• RQ - Release Quality: textures with horizontal resolution of 2048 or above and medium degree of realism
• CQ - Cinematographic Quality: textures with horizontal resolution of 2048 or above and high degree of realism

Image Properties

Naturally, the images should be seamless (tilable) so that seams are not visible on the rotating planet, neither on the stitch nor at the poles.

3d rendering software with unwrap functions is recommended, since it is extremely inefficient and troublesome to create seamless textures in 2d programs.

Planet textures required

[source: klauss]

• Diffuse color map (the actual planet texture)
• Night map (with city lights); needs to have alpha channel for the transparent areas. Compression type must be DXT3.
• Specular map as usual.
• Cloudmap... not so usual. The cloudmap contains color in the color data - but base, unlit color. Until now, I couldn't find a case where the color portion of the texture wasn't uniform, so I might drop color "texture" for a uniform color "parameter" - but in any case, the texture contains the cloud's basic color in the color portion (fully white for earthish textures), and "thickness" in the alpha channel. What I did to create the current cloudmaps: transfer the color (grayscale) channel to the alpha channel, adjust its "dynamic distribution", kind-of gamma correction, to avoid saturation of the alpha channel as much as possible (it looks bad), and filled the color channel with white. Thickness means that - the thickness of clouds. It indirectly translates to their height. All clouds are based on the same level (they usually are in reality, minus some exceptions), and grow upwards as much as the alpha channel tells it to.
• Normalmap as usual (though normalmaps are presently not required, they aren't any different from unit normalmaps: RGB with normal data, Alpha with height data).

Development Tools, Tutorials

GIMP

GIMP - the GNU Image Manipulation Program is quite versatile; to work with texture files, you'll need DDS plugin (if it's not installed already).

A good starting point for e.g. gas giant texture maps is the 'Solid Noise' filter.

There is a way to make planetary twisters like Uranus or so, using the Gimp. First you must create the gas texture, and then apply the distort filter into Filters>Distortions>Deformation. Then set the deformation type to "counterclockwise swirl", and the make one or two swirls. This will generate swirls at the surface.

On the other hand, if you like a hurricane zone, for example Jupiter's Great Red Spot, you can do it very simply: first select a ecliptic small zone, which will be the future hurricane. Then apply the filter Filters>Distortions>Lens Crystal, and apply a bit crystal lens distortion. Then, deselect that selected zone, and apply Filters>Distortions>Deformation, and set the deformation to "move", and move the left and right sides of the elliptical form a bit, just to make the effect of undercloud.

POV-Ray

[Links:3D_Applications#POV-Ray|POV-Ray (Persistence of Vision Raytracer)] with its unique scripting approach and through a large base of available texture, pigment, and material functions provides almost unlimited possibilities to creating surface maps.

Maps can be exported by using a spherical camera setting: camera {spherical angle 360}

Blender

[Links:3D_Applications#Blender|Blender 3D]

Scripts for blender can be created using Python. No application of blender for creation of planet surfaces is known to us currently. Submissions are appreciated.

Tutorials

Some great tutorials can be found at Solar Voyager. They are geared toward 3dsmax and Photoshop, but are general enough in scope that they could be easily adapted to GIMP and POV-Ray.

Including and Testing

Systems Substitution Testing

In the .systems file of the systems where you saved the game (data/sectors/SectorName/), search for the planet that you want to test your texture on and replace the current texture in the 'file' statement with your texture, e.g.

• Take: <Planet name="Wiley" file="planets/rock.texture" ...>
• Replace with: <Planet name="Wiley" file="planets/rocky_wiley.texture" ...>

Note: You can search in data dir using the command grep -R "rock_water.texture" sectors

Should your planet texture not be listed in the sector definition files, you can edit the system config file "sectors/testsystems/planets.system" to change your texture on one of the existing planets and then run Vega Strike with the planet test mission:

./vegastrike test/planets.mission

Editing Systems

In some cases it is required to tweak the universe in order to add new textures. A very good HowTo explains the road to be taken here.

• HowTo:Edit_Systems with
  • HowTo:Edit_Systems:Milkyway
  • HowTo:Edit_Systems:System_Files

Selection and Vetting Process

Some Thoughts

While many textures are still with the DQ (development quality) status, it is important to quickly raise the quality of all textures to release status and beyond. In this stage, following the selection (or vetting) process might not be of the highest importance. However when replacing visually appealing textures or raising the overall quality to CQ (cinematographic) it is of advantage to share your decisions with the whole community. This is exactly the purpose of the selection and vetting process.

Enthusiasm, the strong motivation to contribute his own work, see it published in a release, and be part of the community, often brings the danger along of falling into the pitfall and want to contribute and replace too many textures at the same time. The more advanced in quality and visual appeal the textures become the more important it becomes to create a very distinct and personal look to the particular texture or even planet, since the ultimate goal is to have an individual surface for each planet.

Ultimately, nobody really knows how extra-solar planets look like but here are some references that might inspire you to create an individual, unique, and personal texture:

• The planet name might give you some hints
• The planet type says something about possible surface type
• Analyze the essence of the existing texture in color, structure, area division
• Inspire yourself by other works of art (paintings, computer generated art, astronomical sites, science-fiction movies)

And of course, push your tools to their limits.

Once you have chosen a replacement candidate and have one or more proposals...

The Process

If you are not sure that your texture meets the basic requirements, then please open a forum topic posting your textures. Here's a summary of requirements:

• Format: dds (with .texture extension)
• Ratio (horizontal:vertical): 2:1
• Size: following the POT rule (power-of-two)
• Resolution: min 2048x1024
• Tilable (seamless): horizontally and vertically
• Quality: RQ or CQ

If a texture that you have created meets the above described requirements, then:

• Open a poll for a reasonable period of time (e.g. 2 weeks) and describe:
  • which texture(s) you'd like to replace
  • show which are the candidates
  • describe briefly the method of creation
  • If you'd like to replace more than one texture, describe how you would assign the favorites of the poll to the individual textures

• After a set period of time
  • announce the winners
  • and call the poll closed

• Then
  • Submit the textures to svn (in case you have commit rights attributed), or
  • through the forum ask a developer with write access to submit them (e.g. the maintainer of this page, pyramid).

Submission Process

Requirements

If you have svn commit access, then you will need nVidia's free texture tool nvcompress to transform your original textures to optimized dds textures. Get the tool here: NVIDIA Texture Tools

The following applies to NVIDIA texture tools version 0.9.4. More recent versions have not yet been tested.

Due to a bug in handling 1 pixel mipmaps in the original version, you will be further required to patch the tools with safemode's patch. This can be obtained here: save nvidia-texture.patch file

Patch the texture tools, compile, and install them.

Texture Optimization

Transform your original texture using nvcompress using the DXT1 format.

nvcompress -bc1 textureoriginal1.png texture_dds.texture

Verify the optimized texture either by opening it with the GIMP and making sure that 12 mipmap layers (for 2048x1024 resolution) are contained in the file, or by checking it with

nvddsinfo texture_dds.texture

Lightmap textures require the alpha channel to be included in the compressed texture. Use the DXT3 format to compress:

nvcompress -bc2 lightmap_master.png lightmap_texture_dds.texture

Committing to SVN

If you have write access to svn then submit the textures after going through the community selection process. Otherwise, please call through a forum topic a developer with write access to submit them.

As of May 2008, svn has two directories for texture data:

• /masters/textures that holds the original textures and also source files that were used to create the textures
• /data/textures that holds the optimized dds/DXT1 textures

Development Needs and Tasks

Proposed development roadmap:

• Phase 1 [91%]: Replace existing textures with at least 2048x1024 textures (release quality). Exceptionally sol textures should have minimum resolution of 1024x512 since hi resolution maps for solar system bodies are hard to find for all objects.
• Phase 2 [ 0%]: Expand the set of textures to include more variety in milky_way.xml
• Phase 3 [ 0%]: Develop cinematographic quality surface (planet, lights) and atmosphere (cloud/weather) maps

List of tasks for textured planet surfaces: Development:2D_Images#Orbital_Planet_Surfaces

Procedural Surfaces

At the time of writing (February 2008) no known implementation of procedural orbital planet surfaces exists in Vega Strike.

However, an attempt has been started and you can find some more information in the following thread:

• seamless planetary descent with automatic mesh generation

References

References apply both to textured and procedural approaches if not stated otherwise.

Software, Tools

For a comprehensive list of tools, please see:

• Links:Graphic Applications
• Links:3D Applications

Wiki References

Planets and Systems

• Listing and description of planet types: Manual:Planet_types
• Editing Systems using milky_way or system files: HowTo:Edit_Systems

Development Roadmap

• Improved planet textures (Higher quality/Fractal Enhanced?): Development:Roadmap#Aspects_for_consideration
• List of tasks for textured planet surfaces: Development:2D_Images#Orbital_Planet_Surfaces

Forum References

Texture Requirements

• 4.4 release work
• Artwork/data overhauls

Development Tools

• Tools for creating planet textures

Examples, Including, Testing

• Orbital planet surfaces: gas giants
• Orbital planet surfaces
• Some New Planets
• stand clear. planets coming through

Submission Process

Development Needs and Tasks

• Shady Planet...
• YASP (Yet Another Shady Planet) ;-)

Improvement and Development Proposals

• Auto-Enhancing Textures
• Fractal Generation System
• More pretty stuff: atmospheres and planet surfaces

Planetary Flight Topics

• The official "Seamless Planetary Flight" thread
• Theoretical planetside mode

External References

Gas Giant Surfaces

• Jupiter Atmosphere
• Jupiter (planet)
• The Clouds of Jupiter
• Planetary Remote Sensing - Jupiter
• Atmospheres of the Gas Giants
• Solstation Jupiter
• The Cassini Instruments - Jupiter

Image References

• Io and Europa over Jupiter
• Celestia Jupiter Map
• Celestia Neptune Map
• Bjorn Jonsson's Planetary Maps

Tutorial References

• "Make a planet" tutorial by Greg Martin
• "Advanced planet creation" by alyn

Author: pyramid