|
Assume The Position
World Position, Object Position, Surface Position - what do they all mean? When should one be chosen over another? Object Position First up, Object Position. That one is easy to get out of the way. One theory was that Object Position, when applied to the Planet, would mean the same thing as World Position. That's _mostly_ true, but it seems to confuse the RTR mightily, so it's probably best to not use Object Position on textures or functions applied to the planet itself. The time to use Object Position is when the texture or function in question is being applied to an object. Qualifying that further, when a texture is applied to a simple objects that aren't UV-mapped - the default MojoWorld primitives. UV-mapped objects (imported meshes) will want to use UV Position coordinates. This render of six spheres uses two different materials. The only difference between the two materials is the coordinate system. The material applied to the spheres in the top row uses World Position. The material applied to the spheres in the bottom row uses Object Position. All the spheres are the same size. With the top row, the pattern of cyan and red blotches is all different, because the spheres are in different World Positions. The spheres on the bottom row all look the same, though, as the texture is in Object Position and is the same relative to each sphere. Note that an Object Position texture on spheres of different sizes will be different, because the texture is 3-dimensional and is centered on the object but not scaled to the object.
![]() Top row is World Position, bottom row is Object Position World Position and Surface Position There's no way to explain Surface Position without World Position and vice-versa. And it only makes sense to use Surface Position with textures and functions that are applied to the planet. The set-up goes a little like this - make a terrain texture and then use a clone of that same texture to drive the color on the terrain. This should make the colors exactly line up with the features of the terrain, right? Not quite... And so enters Surface Position. When a fractal driven by World Position is evaluated in the context of a height field, it automatically does an extra calculation to project the current position onto the surface of the planet and then figures the height from there. When it's a color texture, it skips the "project the current position onto the surface" step and just calculates the color where it's at. Using a Surface Position coordinate for a color fractal forces it to do the extra step of projecting the current position onto the surface of the planet. This will ensure that color textures using the same fractals as the heightfields driving the terrain will line up feature for feature. Depending where the camera is on the planet, this lack of lining up may be dramatic or it may be subtle. Some basis functions also seem to map closer than others - "more research needs to be done!"
Texture mapped in World Position
As an entertaining diversion - try putting a Surface Position mapped texture onto a simple primitive (I'd suggest a sphere). I imagine that someone will find a use for the effects resulting from that trick. |