Planetside Software's Terragen 3 has been out for a few months now. I thought I'd have a look and see what new goodies it has to offer and tell the community what I thought of them. Let's roll!
In their own words:
"Terragen™ is a powerful solution for rendering and animating realistic natural environments. Create entire worlds from your imagination, or import real world terrain datasets and use Terragen 3 to create the most realistic visualisations possible. You control the weather, landscape, rivers, lakes and oceans, suns, moons and stars. With Terragen 3 you have complete control..."
I can't mention outdoor CG shots without mentioning Terragen. Since this is a Terragen review I'll mention Terragen a lot - Terragen. (Contrary to popular belief I don't actually get paid by product mentions. That would be too easy.)
I remember using Terragen classic back when it was something like version 0.9 or some other primordial number. With the recent release of Terragen 3, the software has come a long way. Hats off to Matt, Jo, Oshyan and everyone at Planetside Software.
One thing I like about Planetside Software is that the staff are so involved with the user community. You can ask questions on their forums about the software and get real answers from the people who actually made it. A nice treat.
Basically, Terragen provides tools to make the great outdoors. There are different variants of Terragen, each catering to a particular audience and price point starting from free and going up. For this review, I was provided the flagship Terragen 3 Professional + Animation. It ships with 5 render licenses and supports 2D and 3D motion blur, FBX, but most critically, it permits rendering in component passes (i.e. zdepth, normals, diffuse, etc.) This is nice for meeting deadlines.
The concept is the same as other software: You render out each shading component as a separate file and then later recombine them in your compositing software to form the final image.
By rendering in layers, if the highlights are too bright or the water too blue or the clouds too pink or any number of other problems, it can be quickly tweaked in real-time in your compositing program without having to re-render a frame or an animated sequence, a process which could otherwise take days.
Render Layers were easy to set up an the options were numerous:
They pretty much worked as you would expect. This is probably my favorite new feature in terms of usability. Rendering to layers and later making adjustments in a compositor saves time. Time is money. While we're on the subject of rendering it's time for a short lecture you probably already knew.
Rendering at 8-bits per channel is bad. (Terragen supports rendering to 8, and 16-bits per channel.) An 8-bit per channel image, like an ordinary JPG, uses one byte per color component. That means 2^8 for red, 2^8 for green - you get the idea. That's 256 shades for each color, so in total any pixel could be one of 2^24 = 16,777,216 possible colors. Sounds great - but totally isn't. Here's why:
A dark blue sky gradient can't use the full gamut of all possible colors. It's dark blue! It favors the lower end of the blue channel, green and maybe a pinch of the red channel. The result can be visible banding in the individual channels and often the whole image. If you plan on later editing the image such as making gamma corrections or any other luminance shift, things get bad for two reasons.
1. Integer rounding: If a pixel of say the red channel had a value of 128 and you brighten it by 1.2%, that equals 153.59999.... Not an integer. Thus it gets rounded to 154. Do this enough and the image degrades. It gets so much worse though...
2. Clipping: This happens when you darken or brighten an image. By shifting luminance values up and down anything that exceeded 255 or goes below 0 gets thrown away. Several adjustments later and you have banding, blown out gray highlights and pure black shadows of doom. It's not pretty.
Higher bit depth to the rescue! Rendering at 16-bits per channel doesn't just give you double the number of colors as 8-bits per channel, it gives you 256 times the number of colors - per channel! That's over sixteen-thousand-times the number of total colors! (2^48 vs. 2^24).
Moral: Always work at 16 bits per channel. (If Terragen output 32-bit images we would work with those.) Once done editing, output the final 8-bit per pixel images for release on the web, etc. Also render in passes if you can help it. In the case of Terragen saving an openEXR will yield a 16-bit per channel image. You can also save 16-bit per channel tiffs if your software doesn't deal with openEXR.
Nations spend hundreds of billions of dollars mapping everything. In the case of the US they give this data away for free with no strings attached. (Pretty much any work of the US Federal government is public domain by default, so you're safe to use them in commercial work.)
The data sets are called Digital Elevation Models or DEMs for short. They come in many formats and resolutions. Some of these DEMs are familiar like geoTIFF, an ordinary 32-bit TIFF image with extra meta data, while others are in bundled formats, i.e. a folder containing many files; The files and the directory structure itself define the data format - it's complicated.
The good news is that Terragen 3 internally makes use of the the open source library gdal to read DEMs. What this means to you is it can automatically read a wide variety of DEM formats:
You used to have to rely on a lot of third party tools and translation scripts, sometimes even resorting to stitching huge 32-bit per channel DEMs together by hand. Things are a lot easier now. You simply open the largest file in the bundled format and Terragen 3 takes care of the rest. You can load multiple DEMs and they all appear in their correct positions relative to one another. If you enable Stichable border on all of your DEMs you can have Terragen automatically blend them together. I found a border blending factor of about 0.2 to work out for my Mt.McKinley (Denali) DEMs.
Now the real trick: Finding your patch of displaced mountains on a planet-wide scale. Most DEMs contain the latitude and longitude coordinates they were sampled from in the real world. By default Terragen pays attention. It places the DEMs on the planet sphere at their appropriate location. Unfortunately this isn't always what you want but is easy to change. I found I could copy the coordinates of my DEM's loader node (the northwest corner) and past that into the Lat long at apex of my planet sphere and it seemed to work out.
Adjusting the Lat long at apex basically offsets the planet's coordinate system so that the planet's origin is at (or near) the location of the DEM. (Terragen's coordinate system is internally such that has you move further away from the origin, accuracy decreases. When dealing with DEM data we reset our planet's origin to be the location of our DEM data to mitigate such effects.)
Probably the coolest and also the most difficult thing about Terragen, and especially working with DEMs, is realizing the sheer scale that you're working on. You can have an entire planet of endless terrain from ground level up to orbit and beyond. Distances are pretty much real-world measurements. To assist you there are your basic arsenal of measuring tools. I found the ability to right click in the 3D viewport and copy the coordinates of the mouse cursor invaluable.
One of the best places to get free DEMs is from the US Geologic Survey's National Map Server at: http://nationalmap.gov/viewer.html It's like Google Maps but a bit less user-friendly. In fact, you might cruise Google Earth to find a region with terrain you like and then go back to the National Map to download the DEMs. It takes a little practice, and failing that you might actually have to read the directions but it does work and they data they offer is fantastic. (Did I mention free?)
Sometimes you need to get geometry and shaders from Maya into Terragen. For non-trivial objects this turned out to be a little complicated and unfortunately there was no one but historical accidents to blame - No fault of Terragen.
FBX support in Terragen is pretty much limited to importing cameras, null transforms, omni lights and their animation data. Don't expect to import any geometry or textured objects, etc with FBX just yet.
You can export models from Maya to OBJ. Your shaders will all be converted to an MTL file so not all attributes will make it through the translation. In fact, almost none of them will. Everything gets converted to Ks, Kd, Ka, that's color specular, color diffuse and color ambient for those of us who don't speak MTL. There's also a few properties for respective texture maps, transparency and some vendor specific extensions. Point is: keep your shaders simple! Think Phong because MTL materials are Phong based. No fancy shading networks!
Positioning objects is now much easier and can be done directly in the Terragen 3 viewport using standard manipulator handles. You can translate, rotate and scale right in the 3D viewport, as well as press d at any time to drop your objects onto the terrain. It worked pretty much as advertised and made positioning props cake.
Unfortunately the road from Maya to Terragen has its bumps. When Maya has a 'color' attribute on a Phong shader, which has been mapped by a texture, the texture controls the resulting diffuse color of the object. That is, Maya will ignore Kd attributes in MTL files for objects which have a texture mapped map_Kd property. The texture's color is what gets used and whatever the color property was before gets completely ignored.
Terragen has its own ideas. It uses the Kd property as a multiplier for any texture map. Because Maya defaults to setting Kd to 0.0 for shaders which have been mapped, and Terragen uses 0.0 a multiplier for diffuse color - you objects appear black.
The solution was easy once I knew the cause. I simply dove into the subnetwork of my imported object until I found my Phong shaders. I changed their Diffuse color property to white and presto - solved. If I had to do this for dozens of shaders I would instead open the MTL files in a plain text editor and use a search-and-replace function. Basically just change all instances of:
Kd 0.00 0.00 0.00
Kd 1.00 1.00 1.00
for all shaders which have textures prior to importing the OBJ into Terragen. Just remember to change the display mode of imported objects in the viewport from bounding box to Show as Textured. (You can do that now too!) Also remember the scale in Terragen is real-world meters. There is a check box under the OBJ options of your imported object to source in cm.
Importing of OBJs usually worked but was sometimes quirky. This was mainly the result of every software having its own ideas about OBJ and MTL formats. There were times I would import an particularly dense OBJ and the network view would lockup but the rest of the software continued to work as per usual. It was strange and fortunately did not occur often. Nothing that couldn't be dealt with and probably fixed in future patches. Planetside Software actually fixes their bugs. A rare treat these days.
If you ever need a million Stanford bunnies or any other OBJ you import, such as rocks and plants, to be scattered over your terrain the new instance tools make this easy. Particularly cool is the fact that you can select individual instances and modify their translate, rotate and scale - or even delete them. It makes pruning the forest for that postcard shot of the lake much easier.
The quality of the global illumination algorithms in Terragen have improved a bit. It's subtle but noticeable. In fact, if you're a hobbyist looking for a low cost GI render for your OBJs, Terragen is a viable option. Because Terragen files themselves are XML based, with a little work you could even write your own scripts to auto-generate shaders and render settings, etc.
Obviously you can render stuff that isn't terrain and still benefit.
Terragen 3 is a major improvement over previous versions, especially due to the new render layers feature and the ability to interactively manipulate objects in the viewport. The new population controls are awesome as well. I especially appreciated the ability to select and reposition individual instances.
The only down side I ran into during my Terragen experience (after updating to the latest build) was every once in a while a render would finish but there were still a few blocks around the edges of the frame that never actually got rendered. This seemed to only occur when using the new sphere cameras. This can be fixed by cropping the image slightly but I have a hunch it was a bug.
Otherwise, Terragen was pretty stable despite me trying to break it. The thing that surprised me most was how efficiently it dealt with vast amounts of data I threw at it. I was able to feed it 32-bit tiffs over 16k pixels per edge from a high speed network file server and the render still chugged along turning out pixels without issue. Most other renders I tried to feed such textures to including some very expensive ones which shall remain nameless, choked and died with memory exhaustion errors. I don't know what brand of magic Matt includes in his code but it works!
For what Terragen 3 lets you accomplish vs. the price they're asking (there's even a free version) - it's totally worth checking out!
All supporting images are copyright, and cannot be
copied, printed, or reproduced in any manner without written permission
Kurt Foster (Modulok) falls somewhere between programmer and visual effects artist. When not sifting through technical manuals, he takes on freelance roles in both programming and visual effects, attempting to create a marriage of technical knowledge with artistic talent. He can be seen helping out on the Renderosity Maya forum, when time permits.
December 2, 2013
Please note: If you find the color of the text hard to read, please click on "Printer-friendly" and black text will appear on a white background.
Please take a moment to join Renderosity's Newsletter List to receive news and information from Renderosity!