Development:Orbital Planet Surfaces

From VsWiki
Revision as of 18:57, 13 February 2008 by pyramid (talk | contribs) (→‎Procedural Surfaces)
Jump to: navigation, search

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

References

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

Wiki References

Planets and Systems

Development Roadmap

Forum References

Texture Requirements

Development Tools

Examples, Including, Testing

Submission Process

Development Needs and Tasks

Improvement and Development Proposals

Planetary Flight Topics

External References

Gas Giant Surfaces

Image References

Textured Surfaces

Texture Requirements

Summary of Texture Requirements

Textures ready for submission should fulfill:

  • Format: png or jpg
  • 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, but the files can be named either png (preferred) or jpg (alternative). This decision will depend on the number of files where the names appear, and your skill and time to find, replace, and test them.

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.

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 data4.x 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 as usual.
  • Specular map as usual.
  • Night map (with city lights) 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).
  • Replacement of existing textures with a resolution below 2048x1024
  • Replacement of existing textures that are ugly

Development Tools

2D Image Manipulation Programs

GIMP

Gimp is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems, in many languages.

Gimp already comes with a great variety of scripts and the library can be extended with your own C, Perl, Python, or Script-Fu plug-ins.

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 Uranius 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 geneare swirls at the surface.

On the other hand, if you like a huricane zone, like some gas planets at solar sistem, for example like the great red one at jupiter, you can do it very simply: first select a ecliptic small zone, who 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 eliptical form a bit, just to make the effect of undercloud.

3D Rendering Free / Open Source Software

POV-Ray

POV-Ray (Persistence of Vision Raytracer) is a high-quality, totally free tool for creating stunning three-dimensional graphics. It is available in official versions for Windows, Mac OS/Mac OS X and i86 Linux. The source code is available for those wanting to do their own ports.

With its unique scripting approach and through a large base of available texture, pigment, and material functions there are almost unlimited possibilities to creating surface maps.

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

Blender

Blender is the open source software for 3D modeling, animation, rendering, post-production, interactive creation and playback. Available for all major operating systems under the GNU General Public License.

Scripts for blender can be created using Python. No application of blender for creation of planet surfaces is known to the author. Subissions are appreciated.

3D Rendering Commercial Software

LunarCell

LunarCell is a Photoshop compatible plugin that allows you to create instant planets. Create fractal, reality-based, or just strange worlds in seconds. It includes real clouds downloaded from weather satellites and comes with dozens of presets, and you can design your own planets too. LunarCell also generates maps for 3D animation, fantasy mapmaking, and QuickTime 5 cubic VR.

Including and Testing

Systems Substitution Testing

In the .systems file of the systems where you saved the game (data4.x/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.png" ...>
  • Replace with: <Planet name="Wiley" file="planets/rocky_wiley.png" ...>

Note: You can search in data4.x dir using the command "grep -R "rock_water.png" 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.

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 (maybe named as png or jpg)
  • 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.png

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

nvddsinfo texture_dds.png

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 September 2007, 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
  • \data4.x\textures that holds the optimized dds/DXT1 textures

Development Needs and Tasks

Proposed development roadmap:

  • Phase 1 [60%]: Replace existing textures with at least 2048x1024 textures (release quality)
  • 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:


Author: pyramid
Retrieved from "https://wiki.vega-strike.org/mediawiki/index.php?title=Development:Orbital_Planet_Surfaces&oldid=14661"