Creating a 3D Software Box with POV-Ray

Creating digital products is more popular than ever. Many potential buyers of downloadable software still appreciate seeing a boxed version of the software before they purchase – even if the box does not really exist. The image of a software box lends tangibility and makes the software feel more legitimate.

Earn with Bitconnect!Earn with Bitconnect!

This is a similar phenomenon to digital books. As we transition from a time when books were physically real and software used to come in a box towards a time when most content is digitally distributed, people appreciate the images that they traditionally associated with these forms of content.

In this tutorial I will demonstrate a way to make a professional quality software box rendering using POV-Ray. If you are not familiar with POV-Ray, please refer to our article on Getting started with POV-Ray.

Apart from those who wish to create digital products is another group of people who appreciate vintage software. I have chosen to use scans of a couple of vintage video game boxes to help illustrate the techniques in this tutorial rather than to use some arbitrary designs of non-existent software. As time marches on, it’s getting more difficult to find vintage items in mint condition. The techniques in this tutorial are also an exercise in digital preservation.

I selected Imagic’s colorful Atari 400/800 version of their Demon Attack game to showcase. With stripes that pass through the front, back and sides of the box it requires an accurate set of textures.

I’ve also chosen to re-create a digital version of Atari’s green box which their keyboard controllers (for the 2600 VCS game console) came in. Although this was actually a box containing hardware instead of software, I choose it to show how easy it is to create boxes of varying sizes.

Alternate Solutions for 3D Software Box creation

This tutorial requires that you install and use the free POV-Ray ray tracing software and then use it to render your 3D Box. You will need to modify the scripts below to suit your specific needs. This might involve a bit of a learning curve and certainly some trial and error. If you would prefer to check into other alternatives to creating a 3D software box, I have put together a quick list that you might find helpful.

As with ebooks, there are several 2D techniques that are designed to create pseudo 3D results. These are commonly available as Adobe Photoshop Actions or as dedicated software. While not true 3D, they can achieve some pleasing results. The following list contains a mixture of tutorials as well as software designed for the purpose of creating both pseudo as as well real 3D results.

Box Measurements

After I measured the height, width and depth of the boxes in millimetres I scaled the results up by a factor of four. I used a similar scaling factor in a recent 3D Ebook article. This just proved to be a convenient way to come up with pixel dimensions of the textures that were large enough for our purpose. Without the scaling factor the resulting renders would be of lower quality — in particular if the camera was close or zoomed in closely to our software box.

If you are rendering to a very high resolution you may wish to use a higher scaling factor. The more pixels you have in your textures the better they can maintain their quality at higher resolutions. This also applies when the camera is particularly close or closely zoomed in on your software box.
Earn with Bitconnect!Earn with Bitconnect!

Having sorted out the pixel dimensions that we will need for the various textures of our box the next step is to determine the size of our box in POV-Ray. In this case I simply divided the pixel dimensions by a thousand to get them into a workable scale for our POV-Ray scene. Below are the measurements of our two boxes in millimeters, along with the pixel dimensions of the textures we will be using (based on our scaling factor) and finally the dimensions of the boxes in POV-Ray units.

Demon Attack Box
dimension millimetres pixels (x 4) pov-ray units (% 1000)
width 139.75 mm 559 0.559
height 192 mm 768 0.768
depth 25.5 mm 102 0.102
Keyboard Controllers Box
dimension millimetres pixels (x 4) pov-ray units (% 1000)
width 139.75 mm 559 0.559
height 192 mm 768 0.768
depth 73 mm 292 0.292

The textures for each side of the box

Six distinct image textures will be needed for each of the six sides of our software box. Use your favorite bitmap and/or vector graphics software to build these images for your software box. Ensure to name the individual image files as below for compatibility with the script to follow.

In the case of the two boxes that I used for this article, they were of course real boxes whose sides were each scanned in and then cleaned up using a bitmap editor (the Gimp). Next I cropped the images and resized them to the required pixel dimensions.

Demon Attack Box Texture Images and POV-Ray dimensions
side filename pixels pov-ray units
front front.png 559 x 768 0.559 x 0.768
back back.png 559 x 768 0.559 x 0.768
left side left.png 102 x 768 0.102 x 0.768
right side right.png 102 x 768 0.102 x 0.768
top top.png 559 x 102 0.559 x 0.102
bottom bottom.png 559 x 102 0.559 x 0.102

Keyboard Controllers Box Texture Images and POV-Ray dimensions
side filename pixels pov-ray units
front front.png 559 x 768 0.559 x 0.768
back back.png 559 x 768 0.559 x 0.768
left side left.png 292 x 768 0.292 x 0.768
right side right.png 292 x 768 0.292 x 0.768
top top.png 559 x 292 0.559 x 0.292
bottom bottom.png 559 x 292 0.559 x 0.292

Planar Image Mapping

As the default method that POV-Ray maps texture images onto objects, Planar Image Mapping basically plots the texture’s pixels onto your object as though they were on a plane. POV-Ray supports several other Image Mapping types (such as cylindrical and spherical) but these are not appropriate for our software box.

If we were to use a single box primitive in POV-Ray to represent our software box and applied our texture using planar image mapping we would not get the result we desire. Only one side of the box would properly produce the texture. There is no way to define a separate texture for each side of our box using this technique.

As an example, the image below is a single box primitive which has had a texture image mapped to it using planar image mapping. The texture is aligned to appear on the front of the box properly. The texture then moves through the rest of the box primitive and comes out the backside of our box.

The depth of the box (above) has been exaggerated so that you can see the effect better. The sides of the box are painted with the edge pixels of the front texture and the back of the box (above right) results in a backwards or mirror-image of the texture. Not at all what we require in order to display a software box properly.

The solution to this problem is to create six discrete box primitives, one for each side of our software box. These will need to match the dimensions we described above and in the script below you can see that the thickness for these panels is described by the paperthickenss value.

As you can see in the image above, this approach allows us to image map a unique texture onto the individual boxes that we created. We position the box primitives to form our complete software box.

In the source code below we see a value describing the paper thickness, which is simply the thickness of the virtual paper used to build the software box. It really doesn’t matter what this value is set to as the paper’s thickness only goes inwards towards the center of the box and is not seen.

POV-Ray also supports the definition of Meshes, which are basically primitives made from a list of triangles. They can be texture mapped using UV texture mapping. This provides for yet another way to build our software box — but is beyond the scope of this article.

The Code

The following POV-Ray script creates a simple scene with a pair of lights, a camera and the software box itself. The softwarebox object consists of 6 box primitives which have been squashed to resemble the 6 sides of our software box. All of these primitives are brought together into the single object by using a CSG Union.

You can easily modify the dimensions of the box at the top of the script to suit your own project requirements. Enter the script below into your favorite text editor and save it into a directory on your computer that also contains all of your texture images.

#declare boxwidth = 0.559;
#declare boxheight = 0.768;
#declare boxdepth = 0.102;
#declare paperthickness = 0.01;

background { color rgb<1,1,1> }

camera { location <0.0,0.75,-0.75> look_at  <-0,0.05,0> }

light_source { <3,1,-2> color rgb<1,1,1> }

light_source { <-3,1,-3> color rgb<1,1,1> }

#declare boxfinish = finish {
	diffuse 0.9
	reflection {0.15}
	specular 0.75
	roughness 0.05
}

#declare softwarebox = union {

	// front
	box { <0, 0, 0> <boxwidth, boxheight, paperthickness>
		pigment {
			image_map {
				png "front.png"
				interpolate 2
			}
			scale <boxwidth, boxheight, 1>
		}
		finish { boxfinish }
	}

	// back
	box { <0, 0, 0> <boxwidth, boxheight, paperthickness>
		pigment {
			image_map {
				png "back.png"
				interpolate 2
			}
			scale <boxwidth, boxheight, 1>
			rotate <0, 180 ,0>
		}
		finish { boxfinish }
		translate <0, 0, boxdepth-paperthickness>
	}

	// top
	box { <0, 0, 0> <boxwidth, paperthickness, boxdepth>
		pigment {
			image_map {
				png "top.png"
				interpolate 2
			}
			scale <boxwidth, boxdepth, 1>
			rotate <90, 0, 0>
		}
		finish { boxfinish }
		translate <0, boxheight-paperthickness, 0>
	}

	// bottom
	box { <0, 0, 0> <boxwidth, paperthickness, boxdepth>
		pigment {
			image_map {
				png "bottom.png"
				interpolate 2
			}
			scale <boxwidth, boxdepth, 1>
			rotate <270, 0, 0>
		}
		finish { boxfinish }
	}

	// left
	box { <0, 0, 0> <paperthickness, boxheight, boxdepth>
		pigment {
			image_map {
				png "left.png"
				interpolate 2
			}
			scale <boxdepth, boxheight, 1>
			rotate <0, 90, 0>
		}
		finish { boxfinish }
	}

	// right
	box { <0, 0, 0> <paperthickness, boxheight, boxdepth>
		pigment {
			image_map {
				png "right.png"
				interpolate 2
			}
			scale <boxdepth, boxheight, 1>
			rotate <0, 270, 0>
		}
		finish { boxfinish }
		translate <boxwidth-paperthickness, 0, 0>
	}

}

object {
	softwarebox
	translate <-(boxwidth/2), -(boxheight/2), -(boxdepth/2)>
	rotate <0,-45,0>
}

After definition of the softwarebox object, comes the actual placement of it using the object declaration. The software box is first translated so that it is centered on the origin of the x, y and z axes. This makes it convenient when you want to rotate the software box to a specific angle for rendering.

Rotations in POV-Ray are centered at the origin of the axes. If the box is centered here too, it will rotate as you would normally expect. In the code above our software box is rotated 45 degrees negatively around the y axis. The camera is placed slightly above the software box. When rendered the scene appears as the image below.

It is important that the texture images for the sides of the boxes are accurate with respect to each other. Below is a zoomed in view of the side of our software box demonstrating that the textures do in fact match nicely.

By having defined our software box as a CSG Union we can easily create multiple instances of our box. The image below was created by using a while loop to create 10 instances of the Demon Attack box. I then added one of the green keyboard controller boxes for good measure.

#declare Index = 1;
#while(Index <= 10)
	object {
		softwarebox
		translate <-(Index/10),0,(boxdepth 0.0125)*Index>
	}
	#declare Index = Index + 1;
#end

Rendering to a transparent background

If you are uncertain about the color or underlying texture of the background that you will be using your software box image against (or if the background changes dynamically) it may be desirable to have POV-Ray render against a transparent background. This allows you to use your software box object on a variety of different backgrounds without having to re-render it.

The image above was rendered as a transparent PNG. Note that the JPEG/JPG image file format does not support transparency. When you request a rendering from POV-Ray, simply add +UA to have the Alpha Layer (transparency) included. Here is a quick example :

povray softwarebox.pov +UA +A0.0 +AM2
The +A0.0 and +AM2 above request that POV-Ray use high quality, albeit slow anti-aliasing while rendering.

Conclusion

This article has shown you how to create a 3D software box image using Pov-ray. A pair of vintage software boxes were used as examples.

You can re-create software boxes based on real world boxes using these techniques (as I did) or you can simply create software boxes that are not based on any real world counterparts. The script above should be flexible and easy enough for you to quickly render a variety of software boxes as you require.

Earn with Bitconnect!Earn with Bitconnect!

Speak Your Mind

*

Read previous post:
USB Connection Frustrations

It's estimated that 50% of all USB Connection Attempts end in failure.

Close