Development:System Backgrounds

Development

---

Introduction

This page summarizes concepts and approaches to creating space backgrounds compatible with Vega Strike.

Backgrounds in space are sphere mapped textures arranged in a cube-shaped sky box, so you will need to give us a set of six images.

The engine generates stars with low density, defined distribution, without anti-aliasing, and without lens effects (except for the in-system stars). It is recommended to try two approaches when generating your textures - textures with and without background stars - then compare the results, and choose the best one. Vega Strike engine will always render it's stars on top of the background texture. A general recommendation for rendering with or without stars cannot be given since it will very much depend on the density and size of the stars that you will make, as well as the amount of lens effects that you apply. As with any other art for VS, it may be an iterative approach of creation, review, and improvement until approval. If you get near Sol, the VS engine can (configurably) generate stars based on a map of 4000 nearby stars that were processed a few years back. A bigger list would still only have stars in something resembling a sphere around Sol.

Development Needs and Tasks

We could always use more space backgrounds. Ideally, each system in Vega Strike deserves a unique background.

Please head over here for a list of open tasks: 2D Images - Space Backgrounds

Proposed development roadmap:

• Phase 1 [58%]: Replace existing textures with at least 1024x1024 textures (release quality)
• Phase 2 [ 0%]: Expand the set of textures to include more variety per system
• Phase 3 [ 0%]: Develop cinematographic quality backgrounds

Space Backgrounds

Backgrounds in space are textures arranged in a cube-shaped sky box, like a cardboard paper that you can fold together to a box with the texture remaining on the inside of the box.

Creating space background from original images (e.g. Hubble) is not recommended. What you usually would do in such a case, is to map an original image (if you choose use real universe imaginary, though I would recommend to make sure that the original image is not copyrighted) to the inner side of a sphere and then rotate a 90º angle camera four times around one axis (faces 1-4) plus another two times (faces 5-6). This means that at current minimum resolution of 1024x1024, in order to get the same quality without enabling texture interpolation, you would require an original image with at least 4096 pixels (1024 x 4 (one-axis rotations) and truly ridiculous 32768px for 8192px faces. Here we have two good reasons not to use original images as the basis for our space background (copyright and high original resolution). It is rather essential to create your individual space background to use in Vega Strike. Resolution should be no issue with any 3d rendering programs.

Each system uses 6 cube faces each with maximum 1024x1024 resolution. You can go up to whatever your card memory will take, I guess maybe around 8192x8192 if there are not too many ship types in the system with a 256MB VRAM card. However high resolutions might utilize the VRAM too much in the presence of many different textures in the same system (ship types, planets, rings, suns, stations) so we have opted for maximum resolution of 1024x1024 for now.

With a 1024x1024 textures and a standard FOV of 37.5 degrees we are viewing about 427 pixels on the screen ( = 4*1024*37.5/360). With a monitor resolution of 1280 this corresponds to one background pixel being stretched to 3 screen pixels ( ~1280/427 ). To get a clean image we would need at least a background face resolution of 3*1024x = 3072x, which not being POT would make it 4096x (2^12) and end up in 64MB VRAM usage per system background (shock!) while the 1024x1024 resolution makes it only 4MB.

We are currently encoding backgrounds with DXT1 which has a very high compression ratio (8:1 without alpha channel) and the banding is more prominent. It is a known behavior with smooth hue gradients and DDS compression.

Texture Requirements

Generic Image Requirements

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

Specific Image Requirements

We require six images that make the six sides of the imaginary box: back, front, right, left, top, and bottom.

The texture graphics format currently recommended for the game space backgrounds is png format, but the file extension must be renamed to bmp. VS engine automatically recognizes the image format. This means that you can e.g. save your image in png format and then rename it to bmp and internally it will be still recognized as png format. The name change is required because you cannot specify the extension in the system description files and VS assumes the images are named with bmp extension.

The image ratio horizontal:vertical must be 1:1 (assuming pixel ratio of the map is 1:1), since the texture is mapped to a cube with equal edge dimensions. 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 per skybox face should be a power of two (POT). Really, NPOT (non-power-of-two) textures are 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:

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

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.

Committed textures are classified as:

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

Data Compression Requirements

Space backgrounds are non-transparent, hence DXT1 compression will suffice. Assuming a very large distance to viewer the compressed textures do not require mipmaps. This can be achieved with nVidia texture tools using the command:

• nvcompress -bc1 -nomips background_original.png background_data.bmp

Creating and Naming

You can use one of those tools described further down in tutorials. The following descriptions were tested with the settings used in the POV-Ray tutorial.

After creating your images you'll probably need to rename their suffixes to be compatible with Vega Strike format. This little map should help you get the orientation and namings right.

If your texture core name is "blue2" you will have to produce the six images "blue2_1" through "blue2_6" with the correct orientation. Now take those suffixes (indexes) and rename them as follows: "blue2_1" to "blue2_back", "blue2_2" to "blue2_right", you are getting the hang of I guess. Continue until texture part 6. You may easily create a small script to do the job for you. Note: the underscore "_" separator is essential in your final textures.

At this point you may want to decide if your new texture should replace a low quality texture, i.e. become generically available for several systems, or if you want to make a system specific background. The first case is applicable at this stage of the development, where still many backgrounds present low artistic quality (DQ). Later, you may want to prepare specific system textures. At this stage the background core name should correspond to the system name. In the latter case (only) editing of the system file before submission will be required.

Now you should be ready to go to the next step of verifying your space background inside Vega Strike.

Including and Testing

First of all, copy your six texture files to the data/textures/backgrounds directory.

The easiest way to test your new background is by trying it out in the test system. Edit the system configuration file "sectors/testsystems/planets.system" (yes, the same one you can use to test your planet textures) to change your texture at the beginning of the file

<system name="Sandbox" background="backgrounds/blue2"

Then run Vega Strike with the planet test mission:

./vegastrike test/planets.mission

Once you are happy with your texture, choose a system that you want to put it in. To generally (for all systems that are using it) replace e.g. the old "blue2" background you can search in data directory using the command

grep -R "blue2.png" sectors/*

In case you are creating a system specific texture, adapt the system background description directly.

This should give you a list of sectors using that texture. Now you can copy and edit a save file to be located in exactly that system (view instructions here) you'd like to evaluate.

Finally, please verify that the texture meets the basic requirements. In summary:

• Format: png; Extension: bmp
• Image Ratio (horizontal:vertical): 1:1
• Size: following the POT rule (power-of-two)
• Resolution: minimum 1024x1024
• Seamless: horizontally and vertically
• Quality: RQ or CQ

If all test are satisfactory, you can proceed with the community review (vetting) and submission.

Selection and Vetting

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 (assuming your work has 'some' artistic quality). 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 wanting to contribute and replace too many textures at the same time. Take it slowly. Since the ultimate goal is to have an individual background for each system, 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 and system.

Ultimately, through availability of abundant imagery, we can get an idea of the visual marvels that space offers to us. Anyhow, here are some considerations that might inspire you to create an individual, unique, and personal texture:

• If you want to replace a background, analyze the essence of the existing texture in color, structure, spatial division, and try to come up with something similar (in essence, not appearance)
• Inspire yourself by other works of art (paintings, computer generated art, astronomical sites, science-fiction movies), real images (NASA, Hubble, ...)

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. Please verify the summary of requirements above.

If a texture that you have created meets the texture 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
  • display your candidates
  • briefly describe the method of creation and tools used
  • 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

AKA: Committing to SVN.

You will be required to submit:

• Six image files (with bmp extension, the correct orientation and naming)
• A system file if you are not replacing an existing background but have created a new system specific texture

In addition you may also submit:

• the source code or project file used to create the textures
• a credits text file stating you as the creator of that work, plus any additional info you may want to supply (real name, experience, thoughts on the image, license type (CC, or GPL))

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 or private message, 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 (if you are willing to share them so that larger resolutions may be produced in the future if required)
• \data\textures that holds the textures used in game.

Tutorials

HDR Shop

[Source: PhpWiki from September 28, 2003 10:49 | Author: Spiner]

Once you have your image done load it into HDRShop and choose Image/Panorama/Panoramic transformations.

Under your source image(left side of menu) there will be a format option(should say mirrorball) choose mirrorball closeup. now on the right side (destination image, keep new image) under format choose Cubic Environment vertical cross.

You should now have a cross with only half the image in it.(saves anything but will call it "image 1")

Now to the second part.

Go to your original image and press "V", that will turn the image 180. Now go to the panorama transformations again. Choose Mirrorball closeup under source image, and cubical map under destination image. Now before you transform the image go to "3D Rotation" and choose arbitrary rotation. and choose settings. Under X axis change it to 180. leave Y and Z 0.

Ok now we have the rest of the cross. save it.(this will be called image 2)

Now go to image/calculate; under image a choose your first image(Image A) and for image b choose the second image (image b); leave c and d alone.

This will calculate the image and put it together to have one seamless image.

Note that this also makes your image double so try to change image b before you transform it.

[2003 | Author: hurleybird]

And another way i found out how to make cube maps is this...

If you have a texture which can be tiled then you can use longitude/latitude to cubic environment (note, you want to add stars AFTER this is done, not before) then you can get some really nice effects.

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 any kind of graphics.

A sequence of textures can be exported by using spherical camera setting:

     #declare skybox_part = mod(frame_number-1,6); //range [0-5] 
     #declare camera_texture_Vegastrike = 1; //1=true 0=false
     camera { location <0,0,0> angle 90 right <1,0,0> up <0,1,0>
        // turn the cam based on the current frame [0-5]
        #switch (skybox_part)
           #range (0,3) // first 4 frames: turn from left to right
              rotate (90*skybox_part)*y
           #break
           #case (4) // frame 5: look at the sky
              #if (camera_texture_Vegastrike) rotate -90*x rotate 90*y
              #else rotate -90*x #end
           #break
           #case (5) // farme 6: look at the ground
              rotate 90*x
           #break
        #end // End of conditional part
     }
  #end //camera 6

References

Software, Tools

For a comprehensive list of tools, please see:

• Links:Graphic Applications
• Links:3D Applications

See Also

• Panoramic Image Conversion with HDR Shop
• "Make a Realistic Star Field" tutorial by Greg Martin

Author: pyramid