There's a lot of confusion about the tiled rendering feature and it's complicated by the fact that there are a few known bugs with tiled rendering that can trip you up if you're not aware of them. This tutorial is about the ins and outs of tiled rendering, what those known bugs are and how to effectively use the tiled rendering feature.

WHY use tiled rendering?

Tiled rendering was created to get around the 'Windows can only address 2GB of RAM at once and large renders of complex MW planets can easily run out of addressable RAM' problem. So, if you need to render a large image (larger than about 1,440,000 square pixels (pixel width times pixel height)), and especially if the planet file you plan to render is complex, then you should use tiled rendering.

Another use of tiled rendering can allow you to do a primitive sort of 'network render' where more than one machine works on a single image at one time. I'll talk about that in more detail after some basics of Where and How tiled rendering is set up and used.

WHERE do I find tiled rendering parameters?

To use tiled rendering, you must first create a custom render setting that has the tiled parameters set. On the render settings menu, choose 'Settings'. In the dialog that comes up, use the menu item 'Create New Setting' to begin defining a new render setting. Give this new setting a name and set up the Anti-Aliasing, Geometry Detail and Shadows checkbox as desired. The Width and Height parameters are the full dimensions of your final image. The actual tile parameters are under the Advanced Settings control stack expando-widget. This screenshot of the Settings dialog shows an example tiled render setting which will be used throughout this tutorial:

Some things of note:

• Don't worry about those first three Advanced Settings; the Bucket Size, Sub-Prim Threshold and the Redo Buckets checkbox. More information about those parameters can be found on pages 29 and 30 of the v2 supplemental manual and you should not need to change them (though, depending on the planet, it may make sense to turn Redo Buckets off...)
   
  
• Tile Size: tiles are square, so there's only one dimension to specify. Don't make your tiles too small! There is a known bug where too many tiles will cause MojoWorld to crash when it goes to assemble the tiles into the final image. The exact number of tiles that causes a crash seems to vary on different Operating Systems - but you should be safe if you keep the total number of tiles under 250. A good minimum tile size to consider is about 500 pixels. A tile size of 1000 is probably ideal.

  Figuring out the total number of tiles:

  Take the total Width of your image and divide it by your tile size. Round UP if you get a fractional value, no matter how small. Next, take the total Height of your image and divide by the tile size. Again, round the value up. The number of tiles you will have will be the result of those two numbers multiplied together.

  For example, in the render setting shown in the screenshot above, 12000 pixels wide divided by a tile size of 800 pixels is 15. And 8000 pixels tall divided by the tile size of 800 is 10. 15 times 10 is 150, so this image will be cut into 150 tiles. The tiles will be numbered 0 through 149. If I'd chosen a tile size of 1000 instead, the total number of tiles would be 96 (12 * 8) and they would be numbered 0 through 95.

• Border Size: The border size is the number of pixels one tile will extend into its neighboring tiles. Unless your planet uses large displacements, the border size can be quite small. A non-zero border size will mean that not all tiles will be exactly 'tile size' pixels square. In the render setting example above, most of the tiles in the middle parts of the image will be 820 pixels square: 800 for the tile size, and 10 pixels added on to each edge; top, left, bottom and right.

  This diagram of a tiled render setting may help explain - the image is 600 wide by 320 tall (pretend it's really 10 times as big ;) and the tiles are 100 pixels square (again, pretend it's really 10 times as big, 'cuz there's no reason to use tiled rendering on an image this small...). The border size is 10 pixels.

  

  Tile # 5 is 110 pixels by 110 pixels. It's square, but that's just a coincidence of it being a corner tile and that the overall width of the image was evenly divisible by the tile size. Tile # 7 is one of those 'out in the middle' ones that's also square and is tileSize + (2 * borderSize) which amounts to 120 pixels square. Tile # 21 is the odd size of what's left over when dividing the height of the whole image by the tile size - plus one border width, by a 'normal tile width', including the borders, making tile # 21 120 pixels wide by 30 pixels tall. That's just the way it is with tiled rendering - not all of the tiles will be square, particulary along the edges.

• For the Start Tile and End Tile parameters, I'll go into more detail in the next section, on the Hows of tiled rendering.

HOW to use tiled rendering

The most important thing to know about tiled render settings is that they do not use tiling at all unless the job is put into the Uplink Queue by choosing the Process Later... menu item on the Render Settings menu and then processed in the Uplink Queue. As you should always do when creating a new Uplink Queue job, click on the 'Save to Disk' icon to pick a file name and folder to write to. For tiled rendering, it's a good idea to create a sub-folder to hold all of the tiles and the final assembled image.

Another known bug - Uplink Queue items are not portable across machines, so if you intend to use the tiled rendering feature to do a 'network render' (having more than one MojoWorld session work on an individual image), you'll want to follow this set of steps:

• Create your world and select the view to render.
• Save your world file.
• Copy this world file to all machines participating in the render.
• Start MW on each machine and have them all open their respective copies of the world file.
• Select the tiled render setting on each MW session.
• Select 'Process Later...' in each MW session.
• Click the 'Save to Disk' icon in each MW session.
  Ideally, you'll be able to select a network-visible folder as the destination for all tiles, but that's not a requirement. What is a requirement is that you use the same filename for all of them, for example, "foo.png" - this will create output files named "foo_tiles00000.png" through "foo_tiles00149.png" - if we were using the example render setting defined above.
• Use the expansion of the Render Settings -> Advanced Settings on each machine to specify the tile ranges for each session.

Stitching tiles

MojoWorld will automatically stitch whatever tiles it has together into a whole image any time an Uplink Queue finishes. It doesn't matter whether all the tiles are there or not. If tiles are missing, the space will be filled in with solid black. In the example of the job spread across three machines, assuming all three MojoWorld sessions are writing to the same network-visible folder, the job that finishes first will write a final image file consisting of all the tiles currently available. The second job to finish will also stitch the tiles together - overwriting the partial image file written by the first stitching. And then, the last MW session to finish will stitch together all of the tiles into the final image.

If the folder being written to is not a network-visible folder, then you'll need to collect all of the tiles onto one machine in a single folder, then start a MW session and open the planet file in question, create a new Uplink Queue job with the same file name and render a single tile - either the smallest one (which will probably be the last one in the lower right corner, for a tiled render that has remainders on the width and height like the example diagram above), or the fastest one (which will probably be one of the sky tiles, and it'd be easiest to just do the first one). For this final job, it's easiest to specify the range as Start Tile -1, End Tile 0. Or, if the lower right corner tile is very small, use Start Tile 149 (or your total number of tiles minus one), End Tile -1. When that queued job of a single tile finishes rendering, the entire image will be stitched together.

One more known bug

There are a couple common preset cloud layers that have their color driven by a texture which uses 'Slope' as the input coordinates. I'm pretty sure that when those presets were created, the author was thinking, "the color of the clouds at this point will depend on the slope of the planet directly under this point", which indeed would be cool, but alas, is not how things work (but would be how things work if one were to use XenoArch's Planet Slope plugin...). What really ends up happening is that the first chunk of cloud to be rendered uses whatever slope value the renderer last had the last time it was rendering the planet, so clouds with a color texture driven by slope actually end up with a quasi-random color. When a render job is a single image, that psuedo-slope value remains constant for the whole image. But, when the render job is tiled, a new psuedo-slope value is grabbed for every tile - so, tiles end up being very different looking.

Similarly, some preset Sun Light colors have a slope-driven color texture, and this will cause the same effect. I have not yet tested whether or not those few planets with Ambient lights that have slope-driven color textures cause tiling problems or not. I'm thinking that they probably will not have problems, because the ambient light affects the planet and the planet knows what its slope is. Perhaps there would be a problem for imported models and/or MW primitives if they spanned more than one tile in a world where the Ambient light source had a slope-driven color texture - so watch out for slope-driven color textures on anything other than the planet itself.

Back to Generator Tutorials

Home