Introduction

I'm afraid there's no way around it, we have to talk about math. Just a little bit, though. Hopefully it'll be grounded in what you remember from introductory Geometry. This is going to assume that you've played around in MojoWorld Generator and have seen some of the terms used in creating textures, such as 'World Position'. There's so much to know about that we'll have to take a sort of spiral path through the information. My advice is to not worry about making sense of it until you've read through the pieces more than a few times.

While I'll mostly be concentrating on the Generator UI, I'll also throw in some discussion of the Pro UI. When I refer to terms such as 'Surface Pos', I'm using the names you'll see in the Generator UI DDLBs. For the most part, the Pro UI should use the same names, but not always. The example that makes me say, "d'oh!" is World Position - in the Pro UI list of Leaf Nodes, it's listed as World Pos. D'oh!

Space - Four, Three, Two....

MojoWorld is built to handle four dimensions. It's most commonly experienced in only three, however. For the discussion here, I'm going to simplify it down even further to only two dimensions. So, instead of a spherical planet floating in space, I'm going to talk about the flatland planet that's a circle on an infinite plane.

The place we'll start is at the origin. That's the point (0,0) at the center of our infinite plane. The MojoWorld planet is centered on the origin point of the MojoVerse. In this Mojo-centric universe, the moons and rings and the sun all orbit around this origin point. Coordinates in World Position are measured in meters starting from this point. The North Pole of this simplified diagram has an X coordinate of 0 and a Y coordinate equal to the radius, R. The South Pole also has an X coordinate of 0 and its Y coordinate is at the radius' distance in the negative Y direction, -R. If the radius of our flatland Mojo planet is 6,000,000 meters, then the North Pole is the point (0,6000000) and the South Pole is (0,-6000000).

The set of all points in the infinite plane comprise the set of World Position points. The set of all points that are the planet's radius distance away from the origin make up the set of Surface Pos points.

Fig. 1 - A graph of the Universe

The point (X,Y) shown happens to be not only a point in World Position (by virtue of being in the plane), it is also is a point in Surface Pos (by virtue of being on the red circle). The point (X',Y') is a point in World Position, but because it is not on the red circle, it is not a point in Surface Pos.

How Mountains Are Made

Mountains on the MojoWorld planet are created by driving the Mountain Height parameter with either a Generator UI texture or a Pro UI function graph (or some wicked combination of both). The vast majority of the time, the texture creating the Mountain Height will use World Position coordinates. When using the Generator UI to edit textures which create the Mountain Height, the list of input coordinates on the various texture leaf DDLBs is conspicuously short. That's because many of the input coordinates come from the Mountain Height texture itself - you can't measure or use altitude until there's a Mountain Height texture to supply it. Therefore, Altitude is one of the input coordinates missing from the list of possible coordinates to use for creating the Mountain Height texture.

Although both World Position and Surface Pos are listed as valid inputs for Mountain Height textures, due to the way the Mountain Height is calculated, those two inputs are actually the same. When the Mountain Height texture is in World Position coordinates, the data extracted from the texture actually comes from where that texture intersects the Surface Pos portion of MojoSpace.

Here's a picture that will hopefully clarify things - it's basically the same diagram as above, showing the X and Y axes, the red circle which corresponds to Surface Pos and instead of a nice graph paper background, the space is filled with a greyscale texture:

Fig. 2 - Surface Pos intersecting with a value texture

When the Mountain Height texture gets turned into mountains, the texture is evaluated at the Surface Pos and then the surface of the planet at that point is displaced by that value. Here's a tiny section of the process, simplified with a fake sort of Sparse Convolution that I drew in Photoshop:

Fig. 3 - Deriving mountains from a value texture

The red line corresponds to the Surface Pos red circle of the previous diagrams. The blue line represents the mountains created by the underlying greyscale texture. Where the red line crosses a light point, the terrain raises above the red line. Where the red line crosses a dark point, the terrain dips below the red line. Note that we're only concerned with the value of the texture at the red line. The rest of the texture is ignored for the purposes of creating the Mountain Height.

The texture driving the Mountain Height parameter in MojoWorld actually outputs numbers, not grey values, and those numbers will be the amount that the terrain should be raised or lowered relative to the planet's radius, in meters. To make mountains that are as tall as Mt. Everest, the Mountain Height texture needs to output values around 9000. To make valleys that are as deep as the Marianas Trench, the Mountain Height texture needs to output values around -11000. Most MojoWorld planets have Mountain Height textures that output values on a much more extreme scale.

The planet's radius defines the absolute 'sea level' of that planet. More on that concept is covered in the next part on the contour line material. The planet's radius also matters for parameters of the atmosphere and the altitude of cloud layers. For example, if you have a cloud layer whose altitude is 3000, but your terrain texture outputs values between 6000 and 24000, then you won't see that 3000 meter cloud layer at all because it's below ground.

Why Surface Pos?

Or better yet, why World Position? Why are there two similar coordinates at all and when would you want to use one over another? The only time it really matters is when you're trying to get a color texture to line up precisely with the terrain formations.

Fig. 4 - Coloring a terrain

For example, here's a color texture that's a clone of the very same texture used to generate the terrain from Fig. 3. But the terrain is calculated, by definition, at the Surface Pos. And where that bright green line is, intersecting with the very high pointy mountain that's sticking out of my diagram (sorry about that ;) - instead of being colored bright orange near its peak, it instead is colored black because in World Position, the texture is black there! However, if you force the color texture to also be calculated in Surface Pos, it all works out as desired - the color then lines up with the terrain.

Deriving Latitude

Back up in Fig. 1, the flatland planet has North and South poles. For both of those poles, the X coordinate is 0. Also, when the Y coordinate of any point is 0, that represents a point on the Equator of our flatland planet. Therefore, if we could grab only the Y coordinate of any point in World Position or Surface Pos, then we'd know whether it was in the Northern Hemisphere (positive values) or in the Southern Hemisphere (negative values). In fact, if we could convert the range of -6000000 through 6000000 to a range of -90 to 90, we'd have latitude. The trick is - how do we get just the Y coordinate of a point in World Position?

As it turns out, there's a Pro UI node to do that (surprise, surprise!). It's called 'vector element' and it works like this:

Fig. 5 - Vector element used to derive latitude

The elements of the World Position vector in the real three dimensional MojoWorld are (X,Y,Z) and the Vector element node, being written by a programmer, numbers those 0, 1 and 2. So, in order to get only the Z coordinate (which corresponds to the north/south axis in the three dimensional world), the Vector element's 'element' parameter needs to be set to '2'. As for the rest of the graph, the output can go anywhere you'd normally put the output of a Latitude node, so that's why the image of the function graph above stops where it does.

I can hear you saying, "but we already have a Latitude node, why bother with all this?" No reason, particularly, other than to re-enforce the connection between what World Position is and how it relates to the actual MojoWorld planet. That, and doing it this way may be a little bit faster, calculation-wise, than using the Latitude node. Also, we'll be revisiting the Vector element node when we get around to talking about building procedural textures for MojoWorld primitives.