....and Venus was her name... Initial data conversion and renderings of Venus Written by Paul Bourke June 2002 A number of these images appeared on an ESA (European Space Agency) poster titled "Venus Express, Next Stop Venus".

In 1978 the Pioneer orbiter entered an elliptical orbit about Venus. One of the many experiments was a radar system to measure the topology and other surface features of the planet. The resulting topology data is relatively low resolution (1 degree on average) and unsuitable for anything more than local average planet radii. In 1990 the Magellan spacecraft entered orbit about Venus and started a much higher resolution survey, on average approximately 1/22 degrees. The data is presented as three maps, one for each pole and one as a Mercator projection centered at the equator. Unfortunately the resulting datasets are far from clean. The most obvious problem with the data are large areas of missing height values. This is clearly seen on the North, South, and Mercator topology images on the right. The first hurdle then for a whole planet topological model is to fill in the missing regions as best as possible. This was accomplished by using the base topology from the Pioneer mission which didn't have the same missing data regions (except for the poles). For the smaller scale structure a fractal perturbation was used that had the same fractal dimension as the neighbouring region. The resulting renderings shown below for the two polar regions, the technique was quite successful even for the large missing wedges. This was the desired effect for renderings where a significant part of the planet is visible. The regions with missing data are still noticeable if one gets too close to the surface but these regions will simply be avoided in any subsequent low level renderings and animation. North Pole South Pole Similarly, the missing data artefacts aren't noticeable from the following four renderings at each compass point about the equator. Equator, Longitude: 0 degrees Equator, Longitude: 90 degrees

The images below are representations of the topology, the lighter the grey value the higher the elevation. The regions with no data are clearly visible as black wedges (poles) or stripes (Mercator). North pole data South pole data Mercator data (sideways) Equator, Longitude: 180 degrees Equator, Longitude: 270 degrees

All the renderings above were created using PovRay version 3.5 along with custom data filtering software.

The evaluation reported on here was performed to not just determine whether Terragen could render the topology, atmosphere, and lighting as desired but to determine whether it could be used for large scale rendering and animation projects. In particular, "minutes" of stereoscopic movies at the 1024 or 1280 pixel resolutions and secondly planetarium style fisheye animations at the 4000 pixel resolution. Importing Real Topology There are two ways of importing real topological data into Terragen, using one of the supported file formats (currently 8 and 16 bit maps) or creating ".ter" terrain files directly using the documentation provided. I personally found the second approach gave me more intuitive control over the height scaling and offsets. Creating Flight Paths The version evaluated here supported the creation of snapshots which contain mostly camera attributes. These can be saved to a text file (script files), the user can then write simple utilities that read these key frames and apply his/her favourite interpolation algorithm and finally write out a new script file. The format of the .tgs files is well documented, although the parameters that can be animated here are a small subset of what could be animated, essentially the camera, the sun, and clouds. Animation Frames While Terragen will diligently render all the frames in the script files discussed above, there are some annoying aspects and limitations in the current version. In particular, the current file names are of the form "Frame nnnn". A vastly better approach would for the BaseName in the "InitAnim" set-up command in the script to be in the form of a C style format string, eg: "seq_%04d.tga". In any case, there is enough functionality at the moment to create camera based animations. QuickTime Panoramic and Cubic Movies Terragen internally creates both panoramic and cubic QuickTime movies. using standard multi-pass algorithms. Unfortunately the cubic images, while they can be saved separately, are inconvenient for creating planetarium dome content because the cube is not aligned with the camera view direction. I wouldn't classify this necessarily as a bug, see later for cubic and fisheye images that are aligned to the camera coordinate system rather than the word coordinate system. Creating Stereo Pairs The approach for stereo pairs is the same as discussed earlier for animations, a utility is written which reads a .tgs file, possibly interpolates the frames, and finally writes out a new .tgs file for each eye. The stereo setting provided by the user is just the eye separation. Since Terragen doesn't support offaxis frustums the method for creating correct stereo pairs is as discussed here. Briefly, the user chooses a focal length (distance to zero parallax), from that an eye separation is chosen (typically focal length / 30). The desired window width and aperture (converted to zoom for Terragen) is increased given the formula on the link given above. After the images are rendered they are trimmed back to the desired size, the left image is reduced from the left and the right image is reduced from the right. Creating Fisheye Images (planetarium) The standard way of creating fisheye images (hemisphere) using software that doesn't support fisheye rendering for dome displays or planetariums is to render onto the sides of a cube (90 degree aperture) and resample those views to form the fisheye image. This method has the additional advantages that the horizon of the fisheye can be changed to suit the range of dome angles as well as being able to support offaxis dome projection. The same approach is taken as for the stereo pairs, a .tgs file is created in Terragen, a separate utility program reads that, interpolates as required, and spits out another .tgs file with 6 frames per original frame (one for each side of the cube). Terragen then renders this new .tgs file. In reality a number of .tgs files are created for distributed rendering. The "trick" is to create the camera heading, pitch, and bank angles for each side of the cube, remembering that this has to be done in the camera coordinate system. That is, unlike the QuickTime VR case already supported within Terragen, the view direction passes through the middle of the front face, the right vector passes through the center of the right face, and the up vector passes though the center of the top face. An example of a cube created with a camera pitched down by 35 degrees and banked by 10 degrees is shown below. The resulting fisheye is Distributed rendering The animation stereoscopic/cubic/interpolation utility was further modified to create multiple animation scripts that can be used for one of a number of rendering processors running on different machines. At the time of writing there is not a dedicated renderer but the Windows version of Terragen can be run in command line mode and functioned under the "WINE" environment on a large Linux cluster. wine --debugmsg -all "Terragen.exe" /exit /hide /w test.tgw /t test.ter /s test.tgs all Notes The horizontal aperture is 2 atan[1 / zoom] The vertical aperture is 2 atan[imagwidth / (imageheight zoom)] Coordinate system is right handed. A heading of 0 is looking down the y axis, positive heading is clockwise when looking down the z axis towards the origin. To determine the local (camera) coordinate system, start with the camera looking down the y axis, the x axis to the right, and the z axis up. Apply the bank (rotation about y axis), then the pitch (rotation about x axis), and finally heading (rotation about z axis). The heading angle is measured positive if clockwise when looking down the axis towards the origin, bank and pitch are positive anticlockwise! Bugs, problems, or "wouldn't it be nice" The line terminators in .tgs must be carriage returns '\r' not linefeeds '\n'! This is a different definition of a "text" file that UNIX based users are used to. Perhaps the most obvious problem is a black ridge on the horizon. While this can often be removed by fiddling with the atmosphere coverage the success was mixed and while it could be made to magically disappear for stills, it didn't seem possible to reliably fix it over an animation run where the camera height might change. In a sense this is not a bug but a limitation of a finite flat surface, a fix that would work most of the time would be to extend the sky below the horizon. It would be nice if each frames within a .tgs file could have an associated name. Bug: the single name in the header of the .tgs file is currently ignored in the Mac version. File extension on images from an animation would be nice. Currently pict file are called "Frame nnnn". TGA file export would be nice on the Mac version, currently only PICT is supported. Many/most animation houses (including myself) base original frames around TGA files. Why save an alpha channel in the Mac PICT files if it's never used? A render only engine (no windows at all) or even better, a Linux render only engine. Linux is the perhaps the most common OS for large clusters. The command line rendering of frames supports the rendering of "all" frames as well as a single frame, equally useful would be an option to render a range of frames.