A Little Eye Candy

Ladies and Gentlemen, for your viewing pleasure, Winchell Chung’s DY-100 orbiting a class-M planet. Maybe it’s a museum piece.

Clearly, I still need to work on the lighting. And that LunarCell planet? Meh…

Clearly, I still need to work on the lighting. And that LunarCell planet? Meh…

Thank you for your attention,
The Astrographer

Posted in Love and Rockets, Science Fiction | Tagged , , , , , | Leave a comment

Links I Almost Lost

Firefox and I recently had a run-in with a hard drive error. It turned out to be repairable and I recovered all my tabs and bookmarks, but I figured I’d post some of them here, because they have been beddy-beddy good to me.

Posted in World Building | Leave a comment

Hermes, Titan and Horizon Launch Vehicles


An oblique perspective view of the full Horizon 41 stack.

An oblique perspective view of the full Horizon 41 stack.

In the same alternative sixties that produced the Soviet KT-1 Moon Rocket, the United States had it’s own efforts at heavy lift. Some of the information, specifically span, will have to remain indeterminate until I get them modelled in Blender. Have to make it look “good” after all.

Goddard Hermes

The first is the 196-inch Goddard Spacerocket Corporation Hermes LV.

Hermes First Stage

Diameter: 4.978m
Span: ?
Length: 12.700m(14.830m including engines)
Dry mass: 8,923kg
Propellant mass: 199,439kg
Thrust: 3,790.80kN(vacuum) 4 x H-1
Isp: 289s(vac)
Total mass: 208,362kg

Hermes Interstage

Diameter: 4.978m
Length: 1.829m
Dry mass: 2,000kg
Protects the RL-10 engines on the second stage.

Hermes Second Stage

Diameter: 4.978m(9.347m including engines)
Length: 7.620m
Dry mass: 4,775kg
Propellant mass: 38,324kg
Thrust: 266.80kN(vacuum) 4 x RL-10A-1
Isp: 425s(vac)
Total mass: 43,099kg


185x185km, 28.5º         8,486kg
480x480km, 50º            7,492kg
185x35785km, 28.5º     1,990kg
185x35785km, 0º            689kg
185x ∞ km, C3=0            713kg

Douglas Titan

My next model is the bigger and newer 232-inch Douglas Space Systems Titan LV. No relation to any OTL rocket with a similar name.

Titan First Stage

Diameter: 5.893m
Span: ?
Length: 20.320m
Dry mass: 32,776kg
Propellant mass: 447,704kg
Thrust: 9,422.95kN(vacuum) 5 x E-1
Isp: 290s(vac)
Total mass: 480,480kg

Titan Interstage

Diameter: 5.893m
Dry mass: 2,000kg
Protects the J-2 engine on the second stage.

Titan Second Stage

Diameter: 5.893m
Length: 12.090m
Dry mass: 9,207kg
Propellant mass: 90,161kg
Thrust: 1,033.1kN(vacuum) 1 x J-2
Isp: 421s(vac)
Total mass: 99,368kg

Phoenix Adapter

Diameter: 5.893m
Length: 0.9650m
Dry mass: 2,500kg
Only used with the Phoenix manned capsule.

Capabilities(without Phoenix adapter)

185x185km, 28.5º           22,124kg
480x480km, 50º            19,721kg
185x35785km, 28.5º      6,528kg
185x35785km, 0º            3,451kg
185x ∞ km, C3=0            3,508kg
185x ∞ km, C3=15           1,376kg

Capabilities(with Phoenix adapter)

185x185km, 28.5º           19,623kg
480x480km, 50º             17,219kg

This one is clearly our American Proton.

USSF Horizon

Horizon_Right_OrthoA genuine Von Braunian Frankenrocket using pieces from the Douglas Titan and the Goddard Hermes to genuinely create “Cluster’s Last Stand.” Developed to loft the heavy Looking Glass spy satellite. Later made (in)famous by the McKinley Rocket Base incident.

Consists of Titan First Stage core with a cluster of two or four Hermes First Stage boosters. The Second Stage is a Titan Second Stage and it’s Third Stage is a Hermes Second Stage.

Capabilities(0 boosters + upper stage)Horizon 1

185x185km, 28.5º           25,340kg
480x480km, 50º            23,111kg
185x35785km, 28.5º      10,855kg
185x35785km, 0º             7,934kg
185x ∞ km, C3=0              7,983kg
185x ∞ km, C3=15            5,947kg

Capabilities(2 boosters, no upper stage)Horizon 20

185x185km, 28.5º           37,229kg
480x480km, 50º            33,599kg
185x35785km, 28.5º      13,949kg
185x35785km, 0º            9,424kg
185x ∞ km, C3=0             9,506kg
185x ∞ km, C3=15           6,388kg

Capabilities(4 boosters, no upper stage)Horizon 40

185x185km, 28.5º           49,524kg
480x480km, 50º            44,794kg
185x35785km, 28.5º      19,661kg
185x35785km, 0º            13,949kg
185x ∞ km, C3=0             14,053kg
185x ∞ km, C3=15           10,144kg

Capabilities(2 boosters + upper stage)Horizon 21

185x185km, 28.5º           39,038kg
480x480km, 50º            35,768kg
185x35785km, 28.5º      17,993kg
185x35785km, 0º            13,753kg
185x ∞ km, C3=0             13,819kg
185x ∞ km, C3=15           10,858kg

Capabilities(4 boosters + upper stage)Horizon 41Horizon_Top_Ortho

185x185km, 28.5º           50,516kg
480x480km, 50º            46,342kg
185x35785km, 28.5º      23,983kg
185x35785km, 0º            18,647kg
185x ∞ km, C3=0             18,724kg
185x ∞ km, C3=15           14,985kg

Posted in World Building | Tagged , , | Leave a comment

Soviet “Odin” Launch System

This is a bit of a side jaunt. I’m putting up information on an alt-N1 rocket I designed some time back.

KT-1(Krupnyy Transportnyy-Odin, N1-equivalent(-ish))

Blok A boosters(0,2,3,4 or 6)

Diameter: 5m
Span: 6.3m
Length: 15.84m
Dry mass: 28,460kg
Propellant mass: 214,002kg(incl. 2,500kg for boil-off and thrust build-up)
Thrust: 9,264kN(vacuum) 2 x NK-77
Isp: 318s(vac)
Total mass: 242,462kg

Blok B core

Diameter:   7m
Length: 29.67m
Dry mass: 74,135kg
Propellant mass: 854,700kg(incl. 10,000kg for boil-off and thrust build-up)
Thrust: 18,528kN(vacuum) 4 x NK-77
Isp: 318s(vacuum)
Total mass: 928,835kg

Blok V upper stage

Diameter:  7m
Length: 9.654m(7.154m above interstage)
Dry mass: 24,187kg
Propellant mass: 225,000kg(incl. 1,000kg for boil-off)
Thrust: 1,560kN(vacuum) 4 x NK-19
Isp: 347s(vacuum)
Total mass: 249,187kg

Blok VS high velocity stage(Vysokaya Skorost)

Diameter:  5m
Length: 6.452m(enclosed in payload fairing)(in TR-1 4.312m above interstage)
Dry mass: 4,475kg
Propellant mass: 20,610kg
Thrust: 147.88 kN(vacuum) 2 x RD-56M
Isp: 441s(vacuum)
Total mass: 25,085kg

NK-77 4-chamber rocket engine

Thrust(vacuum): 4,632kN
Thrust(SL): 4,578kN
Mass: 3,800kg
Size: 2.50m high x 3.00m wide x 3.00m long
O:F ratio 2.52 LOX:kerosene

KT-1 Launch System

KT-10   0 boosters;    1,178,022kg total mass
Payload from Baikonur
185 x 185km 51.6º orbit 24,974kg
430 x 430km 51.6º orbit 20,521kg

KT-12   2 boosters;   1,662,946kg total mass
Payload from Baikonur
185 x 185km 51.6º orbit 43,363kg
430 x 430km 51.6º orbit 37,231kg

KT-13  3 boosters;   1,905,408kg total mass
Payload from Baikonur
185 x 185km 51.6º orbit 51,555kg
430 x 430km 51.6º orbit 44,678kg

KT-14   4 boosters;   2,147,870kg total mass
Payload from Baikonur
185 x 185km 51.6º orbit 59,259kg
430 x 430km 51.6º orbit 51,658kg

KT-16   6 boosters;  2,632,794kg total mass
Payload from Baikonur
185 x 185km 51.6º orbit 73,434kg
430 x 430km 51.6º orbit 64,518kg

KT-1 High Velocity

KT-10 VS   0 boosters; 1,203,107kg total mass
Payload from Baikonur
185 x 35,785km 51.6º orbit 12,787kg(incl. circ. stage)
185 x inf 0º C3=0m/s escape 9,323kg
185 x inf 0º C3=15m/s escape 6,909kg

KT-12 VS 2 boosters; 1,688,031kg total mass
Payload from Baikonur
185 x 35,785km 51.6º orbit 20,187kg(incl. circ. stage)
185 x inf 0º C3=0m/s escape 15,066kg
185 x inf 0º C3=15m/s escape 11,377kg

KT-13 VS 3 boosters; 1,930,493kg total mass
Payload from Baikonur
185 x 35,785km 51.6º orbit 23,700kg(incl. circ. stage)
185 x inf 0º C3=0m/s escape 17,449kg
185 x inf 0º C3=15m/s escape 13,258kg

KT-14 VS 4 boosters; 2,172,955kg total mass
Payload from Baikonur
185 x 35,785km 51.6º orbit 26,692kg(incl. circ. stage)
185 x inf 0º C3=0m/s escape 19,714kg
185 x inf 0º C3=15m/s escape 15,041kg

KT-16 VS 6 boosters; 2,657,879kg total mass
Payload from Baikonur
185 x 35,785km 51.6º orbit 32,280kg(incl. circ. stage)
185 x inf 0º C3=0m/s escape 23,941kg
185 x inf 0º C3=15m/s escape 18,359kg

TR-1(Transportnyy Raketa-Odin) Launch System

Blok A mainstage with Blok VS upper stage. Proved completely useless…

Oh well.

Most of the weights and measures were worked out with the help of the instructions at McSheppard Aerospace Corporation for making KSP mods. The Silverbird Astronautics Launch Vehicle Performance Calculator was indispensable for determining vehicle performance. Thanks for the help, guys!

I like to think the Western press would start calling the KT-1 the Odin given half a chance. I prefer to think they’ll get that chance.

And thank you to my audience for excusing this little lapse into oddness,
The Astrographer

Posted in Love and Rockets, Science Fiction | Tagged , , , , | Leave a comment

PlanetCell on Blender Cycles – First WIP


An ordinary render of my procedurally-shaded planet. This took less than 3 minutes and 5 seconds to render.

An ordinary render of my procedurally-shaded planet. This took less than 3 minutes and 5 seconds to render.

For a long time, a very long time, I’ve been impressed by the abilities of the Flaming Pear LunarCell plugin for Photoshop. It quickly generates planetary surfaces that are, if not realistic, at least attractive and plausible to cursory examination. Mostly the former, but that’s not bad.

There are things, though, that I think could be improved. It’s not cheap, to start with. It’s not terribly controllable. I’d like to be able to manually guide creation with input masks. I also want the option of deeper control of the noise generation. I’d like to be able to toggle ice cover. In any case, the sea ice generation has been broken in the last several versions. Perhaps the biggest thing I’d like to get away from is Photoshop.

I like Photoshop perfectly well. Very much in fact. But for the purposes of this blog, I’d like to stick to applications that could be available to all or most of my readers. This isn’t the,”Look at all the Cool Junk I Have that You Don’t,” show, after all. Optimally, I want my readers to be able to benefit from my tutorials with no boundaries to entry higher than downloading a few free apps from the internet.

This is looking to be one of my successes at this. In the first iteration, I needed Blender for the noise rendering(the major point of the exercise), Photoshop(!) to flip and convert the RGB OpenEXR height bakes to greyscale TIFF so that I could feed them into GDAL in order to convert to BT format so that I could use Wilbur to create RGB-separated 24-bit color images that I had to feed into POV-Ray to flatten them into equirectangular! Whew. Try saying all that in one breath. A whole lot of work. A whole lot of bouncing around from one app to the next, and at least one expensive, not generally available app in the pipeline. After all that, you still had to use Wilbur to convert the POV-Ray color-hash back into a usable GIS-ready elevation format.

The current iteration does all the hard work of noise generation and rendering of equirectangular maps into one(so far very sloow) procedure inside of Blender(well one per image). Once that’s out of the way, the color imagery and any 8-bit masks are good to go, out of the box. Just add worldfiles. For the heightmaps you’ll need something like FDRTools to convert the RGB OpenEXR to RGB TIFF(FDRTools doesn’t seem to have any functionality to convert files to grayscale) and GDAL to convert the TIFF into a usable 32-bit GIS format. Then you’re ready to play with your data in QGIS, GRASS, Wilbur or whatever floats your boat.

Now, this is definitely a work in progress. It’s slow, I think at least in part ’cause my node tree wasn’t all that thought out. I was kind of floundering as to how to do this to start with so what work I’ve done is a bit of a mishmash of half-completed ideas. So this’ll probably need a full-on refactoring before I’m done, but(at least until the Blender cycles engine gives me a way to save full float bumpmaps directly) it should be adequate for my purposes. Hopefully you will find it useful as well.

Rather than walking you through the creation of this thing, I’m going to post the blend file so you can examine it at leisure. I’ll try to explain the function of the parts, what I was trying to do in building them that way and how they can be used.

First of all, this thing is overly complex and seriously needing a full refactoring. The main idea in the organization of node groups was to divide operations into small “labs” for such things as heightfield generation, land and sea texturing and distribution of land and sea elements. Ultimately, I’d like to reduce the inputs on each group to those that would be most commonly used, with less often accessed parts being well labelled inside the various group nodes. I’m not there yet.

So let’s go over what I do have, starting at the left side of the network. The Texture Coordinate node provides “Generated” coordinates to all the basic position dependent nodes(mostly noise textures). This ensures that the coordinates are always 0..1 on x:y:z, regardless of how you move or rotate the object. Important for animation unless you want the texture to change as the planet moves in its orbit. Very off putting when that happens…

Next comes the Height Group. This would be my Height Control Lab, the bread and butter of the whole concept. For the core of PlanetCell this hasn’t gotten anywhere near enough attention as yet. In my defense, I wanted to assemble a generally functional whole and then go back to improve the details later.

Let’s start by looking at the control inputs. We’ll do this for all the nodes and groups.

Type controls the kind of Musgrave fractal used. This can have the values, “Multifractal,” “fBM,” “Hybrid Multifractal,” “Ridged Multifractal,” or “Hetero Terrain.” These control the appearance of the fractal function. The fBM, or fractional Brownian Motion, type is largely homogeneous, while the others are, in various ways, more heterogeneous. For manual editing work, I like a homogeneous noise for its controllability, but as the generator for a planetary landscape heterogeneous is usually the way to go in my opinion.

Basis controls the noise basis for the Musgrave fractal used. The possible values are, “cell,” “perlin,” “uperlin,” “simplex,” “usimplex,” or “gabor.” Perlin or uperlin, which can also be referred to as “snoise” or “noise” respectively, are, as the name implies, Perlin noise functions. Simplex or usimplex are, similarly, Perlin simplex noise functions, a somewhat faster, in my opinion somewhat more attractive noise. Cell noise is simply a discrete grid of random values, rather like the Add Noise filter common to many painting programs. There is also the option to use a Gabor noise basis. This is significantly slower than the other basis functions, and, because of the way the Musgrave node was written, the various Gabor control parameters are not available. I’m hoping eventually to be able to add various Voronoi-based Worley basis functions as options, but that will require a complete rewrite of the OSL Musgrave node. Definitely a lower priority. Musgrave generally works best with a basis that provides values in the range -1.0..1.0, so it is better to use a perlin, simplex, cell, or gabor basis than the unsigned uperlin or usimplex basis. The unsigned basis functions remain as options to provide flexibility and because the programmer was too lazy to bother filtering them out. Why go to the extra effort to remove flexibility that does no harm? Play around, you might get good results, but understand it’ll be harder to get a decent image with the unsigned basis functions. A good guide to this sort of thing is always Ken Musgrave himself.

Dimension is the Hurst exponent, commonly given as H, of the Musgrave fractal. In short, this controls how rough the Musgrave fractal is. A value of 1.0 will give a fairly smooth fractal and 0.0 will give a very rough effect.

Lacunarity is the frequency gap between each octave of the Musgrave fractal(if it seems like most of the inputs in this group control the fractal then you’ve been paying attention). Typically somewhere around 2.0 is a good value. Higher values will tend to roughen up with fewer octaves(thus faster) than smaller values. I suspect that lower values will produce fewer artifacts, but I can’t prove that.

Detail is the number of octaves of compounded noise in the fractal. There is a hard limit of no more than 22.0 octaves. The more octaves you use the slower the rendering. From the Musgrave article linked above more than about log2(screen resolution)-2 octaves are wasted. So for a 4096×2048 map 10 octaves should be altogether sufficient adding one octave for each doubling of resolution or subtracting one for each halving.

Offset and gain are still a bit of a mystery to me. Multifractal and fBM don’t use them. Hybrid Multifractal and Ridged Multifractal use both. Hetero Terrain only uses offset. Just play around with them…

Displace is a vector that allows you to move the center of the fractal in 3d phase space. This allows you to change the character of the fractal without reseeding(which is good, because you can’t reseed). Every time you want a different world, just change the displacement values.

Scale controls the frequency of the noise. Smaller values lead to larger features, larger values lead to smaller features. Because scale is a 3d vector, you can do special effects like using a larger value of scale in the z direction to compress features in the N/S direction. That could be useful for creating a cloud cover map. Typically, the x and y scales should be the same unless you are going for some odd effects… A scale of somewhere around 2.0 in all dimensions is often good for our purposes.

Vector is basically the position vector of each point on the surface of the object. For most purposes, just leave that on the Generated texture coordinates.

Time takes advantage of the fact that we’re using four dimensional noise. If you want to animate the surface of the planet, you can connect that to a driver. I haven’t studied that yet, so you’re on your own…

Exponent, intensity and final offset were early experiments of mine. I’m not sure how useful they may prove. Exponent raises the raw elevation values to a power(by default 1.0), intensity multiplies the powered value by a factor(default of 1.0) and final offset adds a value to that(default of 0.0).

The internals of this group were pretty well exposed, except for a couple of hardwired nodes that were intended to map the output value from -1..1(theoretically) to 0..1. I may change some boneheaded parts in the future, but for the casual user there really isn’t much to fiddle with under the hood.

The next node is the Land Shader group, which I essentially copied from the Blender Stack Exchange. I’m not using it at present, but in the future I expect to use something very like it to add climate zones(tropical, desert, temperate, land ice, sea ice, etc.). Ultimately, I’ll need to add some sort of noise effect to break up the spatial zones a bit. This is here mainly to give some idea of part of where I’m going with this.

The Land Coloring and Sea Coloring groups are simply noise-based textures for, as the names imply, the land and the sea. The controls on these are kinda funky, and ultimately I’d like to have similar(but less funky) control groups for multiple climate types. At present, these things are way over complicated. I am not entirely unhappy with the land texture, though and may poach it for a desert shader(maybe). Parts of the sea shader could prove adaptable to a cloud shader when I add an atmosphere in the future.

The Land/Sea Mix group mostly exists to hide the, rather spaghetti-like, graph I used to control the sea level and distribute the land and sea shader effects accordingly.

The Bump, Diffuse BSDF and Material Output nodes are standard and self explanatory. The isolated Image Texture node is present to allow for baking textures to uv. For the color imagery, you can simply save to png and you’re good to go.

For the bumpmaps, things get a bit more complicated. Since I can’t output directly to grayscale float, I need to use a Color Ramp to create a linear grayscale RGB for output. Since these clamp all inputs outside of the range 0..1, I need to rescale my heights to that range. To prepare for Bumpmap output connect either the Height output from the Height group or the Flatsea Height output from Land/Sea Mix to the bottom Value input in Set Bump Min(Add). Connect the Color output from Test Bump to the Color input of Diffuse BSDF and disconnect Bump from the Normal input of Diffuse BSDF.

Make sure the 3D View is visible and set to Camera View with Inner Camera set as the camera in Scene properties. Incrementally reduce the value in the upper value input of Set Bump Min(Add) until some blue appears on the 3D View, then raise it just enough to reduce the blue to a few points(For Flatsea Heights, the entire ocean might turn blue). Once you’ve got the lower limit set to your satisfaction, begin raising the value in the lower input of Set Bump Max(Multiply) until some red appears on the planet surface and then step it back by small increments until no more than a few isolated points are red. Once you are satisfied with the results, disconnect Test Bump from the Diffuse BSDF node and connect the Color output of Bump Color to the Color input of the Diffuse BSDF. Now you can render your chosen bumpmap or heightfield. For best results, save the bumpmap to OpenEXR as a full float.

The color imagery, as I’ve said is ready to go, out of the box. Just add a pgw worldfile and Robert is one of your parents’ brothers. Because the OpenEXR seems to be essentially unheard of in GIS circles, you need to convert that into a tiff, then you can feed the tiff into GDAL to make it into something more GIS-ey. Ordinarily, if I was using Photoshop to do the conversion, I’d also reduce the image to a single channel greyscale. Because, I’m trying to get away from expensive software of limited availability, I’m using FDRTools instead. So far as I can discern, FDRTools doesn’t have an option for greyscale output, and GDAL doesn’t do color. At least not directly. Fortunately, GDAL has the -b option to choose a particular channel or “band” of the input file. The bands are numbered from 1, and we know we have three identical bands in this file, so, to convert to Virtual Terrains BT format, the command looks like this,

gdal_translate -b 1 -of BT [Location_of_input_file]/[Name_of_input_file].tif [Location_of_output_file]/[Name_of_output_file].bt

Now you can manipulate this to your heart’s content with a variety of GIS tools.

Obviously, this still needs work. I need to implement variation of shading with latitude: ice and snow, deserts, jungles and other such things. I’d like to add atmospheric effects, at least to the beauty shots(low priority). More significantly, this thing is unaccountably sl-ooo-ow. I’m not entirely sure why. Part of it, surely, is my 2008 model MacBook, but LunarCell runs in a couple minutes or less in 4kx2k res, while this takes hours. POVRay renderings are pretty quick, too. Texture baking, and ordinary renders in Blender seem to be much quicker as well. I may need to compare total time for baking, preparation and map rendering using POVRay. I’m thinking it’ll likely be faster if a bit more laborious. I can probably shave some time off of the baking or equirectangular baking time if I understood shading a little better, but I think there might be a speed issue with Blender’s equirectangular camera…

Please feel free to post any questions(I try to write clearly, but clearly I fail…), comments(“You’re covrage of this suject is very thought provoking. I will surely be read this of the future,” or, “This is very good approach to subject, but you SEO optimization need work. Read http://www.SEOcrap.com for further helpings,” are likely to fall prey to my cruel and overzealous spam filter. Sorry…), or suggestions(speed optimizations would be very appreciated :) !)

Thank you for appeasing my inner attention hog!
The Astrographer

An equirectangular render of the same planet, with the same set of shaders. This took several hours. I promise a no-prize to the first person who can explain this. Seriously, WTF?!?

An equirectangular render of the same planet, with the same set of shaders. This took several hours. I promise a no-prize to the first person who can explain this. Seriously, WTF?!?

Posted in Mapping, World Building | Tagged , , , , | Leave a comment

Shield Volcanoes and Calderas

Olympus Mons on Mars. A gigantic and striking example of a shield volcano with calderas.

Olympus Mons on Mars. A gigantic and striking example of a shield volcano with calderas.

Trying to come up with coherent advice for this fellow trying to create an island over on the Cartographer’s Guild, I ran across a sometimes successful method for creating a shield volcano with one or more calderas. This should be good for making your own private Mons Olympus or Hawaii. A variant on this might prove useful in creating impact craters, but I’m not really going to delve into that. Focus!

I’m going to make a quick build of this using nothing but the Mound filter on Wilbur. The effect, I’m sure, could be improved with additional noise and erosion effects. Again, focus!

I’ll start with a 1024×1024 blank map. To keep things sane, I’m just going to have this thing pop up out of a flat plane. No worries about developing the rest of the island or other landmass upon which this volcano may be growing.

Figure 1. Shield Selection

Figure 1. Shield Selection

First, using the freehand selection tool with feather set to 1.0, select a roughly circular base for your volcano.

Next, we’ll invoke the Mound filter(ctrl-M or Filter>Fill>Mound).


Figure 2. Shield Settings

Because I want to give this shield a bit of a lip above the surrounding plains like the edge of Mons Olympus on Mars, I will set the minimum height to 300 meters. I arbitrarily choose a maximum height of 15000 meters, making this lower than Olympus Mons, but definitely more of a Martian volcano than Terrestrial. For a shield volcano on an earthlike planet 5 or 6 kilometers above sea level would be a really tall shield. Set the Operation to Add and Noise to zero.

Now click the Edit Profile button. Your goal here will be to create a fairly steep-sided flat-topped profile. I usually start by entering a value like 0.9 in the Non-Linearity and hit Apply several times till I like the shape. Next hand

Figure 2. Shield Profile

Figure 3. Shield Profile

draw a flatter top to the curve, trying to keep it continuously rounded and monotonically increasing to the right. Repeated applications of Smooth, Non-Linearity and Normalize will help. With luck and a bit of work you’ll end up with a curve similar to the one below. With more luck, experience and effort you could get better results. This is pretty quickly thrown together.

Figure 3. First Caldera Selection

Figure 4. First Caldera Selection

Next, we want to create a caldera. Select a large round area near the top of the previous mound. Invoke the Mound tool with the Minimum Height set to zero and the Maximum Height set to a negative value equal to the desired depth of your caldera. In this case, -3000. Most of the time you’ll want a much steeper dropoff around the edge of the caldera than the edge of the shield. A few more applications of Non-Linearity, perhaps flattening off the top again, followed by more Smoothing and Normalize should do for that.

Figure 5. First Caldera Settings.

Figure 5. First Caldera Settings.

Figure 6. Caldera Profile.

Figure 6. Caldera Profile.

To give an overview of the problem cases of making subsidiary calderas, I’ll go through the process of making a caldera completely within the larger caldera, and one that lies across the edge of the larger caldera. As we go along, it should become clearer what I’m talking about.

First we’ll use the freehand selection tool to select a roughly circular area completely within the larger caldera.


I’m going to make this one a bit shallower than the larger caldera, so let’s use a maximum height of -800. Otherwise, use the same settings as before. For more interest, you could use a different Profile for each caldera, some could be steep, while others are gently sloping. For this exercise, the previously generated Profile will do just fine.

For this exercise, let’s make a larger subsidiary caldera that crosses the edge of

Figure 8. Edge Caldera Selection with Inner Caldera visible to left.

Figure 8. Edge Caldera Selection with Inner Caldera visible to left.

the first caldera. It’ll still be smaller than the main pit, but bigger than the other sub-caldera.

Before I do anything else, I’ll Select>Feather the selection twice with a Sigma of 1.0. After I feather the selection I’m going to Filter>Blur>Gaussian Blur the area pretty radically. Perhaps three times with a Sigma of 8. This will tend to

Figure 9. Edge Caldera blurred.

Figure 9. Edge Caldera blurred.

make the existing edge a lot less visible in the final new caldera. You can definitely blur it more for better results, but for now… Hurry, hurry!

Before making our Mound(hole), we want to harden the selection back up. Select>Modify>Binarize with a Threshold of 128, then Select>Feather with a Sigma of 1.0 to bring its hardness back in line with what we’ve done before.

I’m going to make this caldera deeper than the main one, so set the Maximum

Figure 10. Result with Edge Caldera in place.

Figure 10. Result with Edge Caldera in place.

Height to -5000. You might have noticed that the maximum and minimum values have been reversed. They should probably have been something like Outer Height and Inner Height, but the programmer seems to have intended this as a tool for making hills not holes. I’m just being contrary here.

Figure 11. Final Result with embellishments, not all successful.

Figure 11. Final Result with embellishments, not all successful.


After doing all this, I tried to embellish here and there, adding inner subsidence to calderas and additional calderas. I even tried to add a smaller cinder cone to the side. When this failed miserably, I made a try at creating a landslip on the side of the shield. You can tell by the results that this is quite a ways short of being ready for primetime.

Figure 13. Greyscale map of elevations. Should be 16-bit...

Figure 13. Greyscale map of elevations. Should be 16-bit…

Figure 12. Perspective view of the final result, prominently showing the attempt at a land slip.

Figure 12. Perspective view of the final result, prominently showing the attempt at a land slip.


I have also posted the resulting heightmap in hopefully 16-bit png, and a simple opengl perspective view.

If you have any comments, complaints, questions, kvetches, kibitzes, or better ideas, please feel free to leave a comment.

If you use this technique, please drop a line to let me know how it worked for you, any rough spots you ran across or any alterations you made to get over those rough spots. I’d love to see what people with greater talent than myself might be able to do with this technique.

Thank you for your attention and whatnot,
The Astrographer.

Posted in Mapping | Tagged , , , | Leave a comment

Cratered Planets


Today, we’re going to create a cratered world using noise in planetGenesis. This has been a headache for me for some time. The result is far from perfect. I don’t think I’d use it as an elevation map for ground views, but it’s a decent “fractal forgery” from a distance.

First up, we’re going to create the basic heightfield in planetGenesis. Right-click, Add Noise>Worley>Summed Worley Modified by Perlin. Select the new node and set Neighbor to 7, Points per Cell to 4 and Height, Width and Depth to about 1. So far, not so good. Next, we want to add a warping noise to reduce the very ordered shape of this noise. Add Noise>Perlin>Perlin’s Noise. Leave the settings on this one largely alone except to alter the Length, Width and Height under Noise Size to about 1. Now, Add Function>Adjustments setting Scale to about 0.2. Shift drag a link from the output of the Perlin node to the input on top of the Adjust node. Now Add Combiner>Warp and connect the output of the Worley noise node to the right input on the Warp node and connect the Adjust node to the left input of the Warp node. To the output at the bottom of the Warp node connect a Musgrave HeteroFractallize node. The effect here is starting to look interesting.

As much as I like the look so far, I would like to add an effect similar to lunar maria. Add a new Perlin Noise node with Noise Size values of 1,1,1. Add Function>Range, I set the Lower End to -0.1, the Ramp to 1.0 and the Value above range to 1.0. Connect the output of the last Perlin node to the input of the Range node. Feed the outputs of the HeteroFractal node and the range node to a new Multiply node. Feed the output of the Multiply node to the  Terrain node and Run. Try opening the result in Wilbur, also add the same image as a texture in Lighting Settings. Let’s keep this as our texture.

In the Terrain node, change the image file name. Attach the output from the Range node to a new Adjust node, set the Scale on that to about 9. Attach the output of the new Adjust node to a new Add node. To the other input of the Add combiner, connect the output of the Multiply node. Finally connect the output of the Add node to the Terrain node. This is basically to force the highlands to a higher elevation than the maria.

Our cratered planet with hillshade rendered in Wilbur.

Our cratered planet with hillshade rendered in Wilbur.

Now, in Wilbur, we look at the bumpmap we have just created with the previously created image as a texture. For what it is, the effect is pretty decent. For something I came across more or less accidentally and am still trying to refine, it’s pretty awesome. I think it may be possible to enhance the craters a little bit in Photoshop.

There’s a lot of controls in there with no obvious sense of what their results might be. I still recommend blind messing about over slavishly following instructions. That’s mostly how I found this… The Scale values in the Adjustment nodes and pretty much everything in the Range nodes are very sensitive to the values produced by the noise, so that may need rejiggering when the seeds are changed.

For the sake of illustration and to get you started, I’ve saved zipped up pG nodefiles for creating the bumpmap and texture images. Mess around with them, change the seeds to create different planets. Let me know if you come up with anything cool or use this for anything interesting.

Now, let’s look at this “in space.” I’ll start by launching Blender, and deleting the default cube. Next, I’ll create a UV Sphere of Size 3.000. Make sure all faces are Shade Smooth. With the sphere selected, I’ll add a new Material and a new Texture of Type Image or Movie. Load the bumpmap image. Turn Off the Color Influence and turn on the Normal Influence under Geometry.

Now, add another new image texture and load the texture image. Keep the Color Influence. Now render.

For now, I’ll leave it as an exercise for the reader to figure out how to extract the z-buffer to Photoshop and use it to composite the image with a Flaming Pear Glitterato background.

Hopefully this will be useful.

Thank you for your attention,

The Astrographer

EDIT: I forgot to post the planetGenesis nodefiles, so I’m posting them now along with heightfield and texture images rendered to 8k x 4k resolution, a nice composite image created in Blender and a blenderfile showing both how the cratered planet material goes together, and, if you check the nodes view, how the compositing was done. Here it is. Thank you for your patience…

Posted in Mapping, World Building | Tagged , , , , , , , | Leave a comment

Using “Planet” for 16-bit planetary maps


Reblogging a two year old post. Oldies but goodies…

Originally posted on Astrographer:

The map on this page got me to thinking about automated terrain generation again. I’ve discussed the inadequacies of most terrain generation before, and I stand by it. On the other hand, as Realmwright says, there are advantages to exploring and filling in an existing map. Much as die rolls serve to spur the imagination in the generation of other planetary parameters, so does a randomly genned map. That’s not to say I’d use a generated map exactly as is. As a geography guy I feel it’s a matter of honor to improve the terrains and maps I’m presented with.

I had originally thought that the map on Realmwright’s page was generated using Torben Mogensen’s Planet generator, but it turns out that the Donjon generator he links to is actually a working implementation of John Olsson’s(johol) old FWMG generator. The cgi on Mr. Olsson’s online app no longer…

View original 1,253 more words

Posted in World Building | 1 Comment

New Additions

In the menu, under World Builder’s Bookshelf, you’ll find two new additions to the site. With permission from Geoff Eddy, I’m mirroring his Creating an Earthlike Planet and Climate Cookbook pages. Some formatting is lost, but the valuable information is intact and I will try to improve the formatting issues if possible.

While I hope that Mr. Eddy’s pages will find a better home, I’m happy to at least keep them available.

Thanks are due to Geoff Eddy for the creation of such useful resources and the permission to disseminate them. I hope this will prove as useful to others as it has for me.

The Astrographer

Posted in Links, World Building | Tagged , , , , , , , , | Leave a comment

Projecting a Map From Imagery: MMPS and GIMP

On friday I created an equirectangular map(or a known portion of one…) from a partial image as from space using Photoshop and the Flaming Pear Flexify 2 tool. Photoshop is fairly expensive and Flexify isn’t exactly cheap. This means they aren’t universally available. I try whenever possible to create tutorials using freely available open-source or shareware applications. Today, I will try to do the same thing I did last time using GIMP and Matthew’s Map Projection Software(MMPS).
First, I loaded the jpg of my image of Asdakseghzan as seen from space into GIMP.
Zeta-GoldI resized the canvas into a square, using Image>Canvas Size… I’ll set both the width and height to match the larger of the existing values. In this case the image is wider than it is high, so I set the height to match the width to avoid losing any information. I hit the Center button under Offset, and told it not to resize any layers.
Next, I make a new transparent layer to act as a template for the placement and sizing of the circular area. With that layer selected, I use the ellipse select tool with aspect ratio fixed at 1:1 to select a circular area centered on the image and covering a maximum possible area. If necessary, use the tool options to set the position to 0,0 and the size to the height and width of the image. Select>Invert and fill the surrounding area with a dark color. Create another layer, fill it with another contrasting color, and move that layer beneath the image layer.
Now select the image layer. Move the layer till the round edge of the planet is close to a round edge of the template. Usually, I use the arrow keys to get this as close as posssible. Even if you get part of the edge matched up perfectly, the limb of the planet in the image will probably diverge from the edge of the template. If not, you’re golden, but if so you’ll need to rescale the layer. This was much easier in Photoshop. I’m not sure you get what you pay for, but there are perks.
Tools>Transform Tools>Scale to start the scaling process. Make sure Keep Aspect is checked. Grab the side perpendicular from the side where the image touches the template and drag till the limb follows the template. My planet image touched the template on the left side, so I stretched up and down on the top and bottom handles.
Now I had a pretty decent centered, maximally space-filling image, ready for reprojection. So I export it as a ppm. On my first try, I saved it as a jpeg and made a conversion using the ImageMagick mogrify facility, but that proved unnecessary.
Zeta-Gold_mergedMy initial plan was to forego dealing with my traced “map.” It wasn’t really all that hot, and the scale and shift process in GIMP seemed a bit horrific. Well, with a bit of practice, scaling and adjusting the position of layers didn’t seem quite as bad, and more practice seemed like a good idea. So I did it anyway.



I decided to just show the thumbnail, ’cause there’s a LOT of whitespace here!







As you can see, the fit isn’t quite as precise as with the version I made in Photoshop. With a lot of effort, I could have made it better, but without transparency sizing is a frustrating endeavor. In order to maintain the tracing as a separable element, I hid the other layers and created a version with just the tracing itself. This is what I would project…

Now we get onto the CLI shell. The commands here assume you’re using some sort of UNIX-based OS like Linux or Mac OS X. Microsoft commands will differ somewhat.

First, I changed my working directory to the location of my images. Next, I gave the following command to reproject the contents of merged_image into map_image:
{location of MMPS}/project -i orthographic -w 2048 -h 1024 -lat -7 -long 7 -turn 2 -f merged_image.ppm > map_image.ppm

Optimally, the app would be on the search list, but the name “project” conflicts with one of my gis tools, so I have to use the full path. Your mileage might vary.

When MMPS was done projecting the basic composite, this was the result.
I also projected the tracing.
I loaded that into GIMP as a layer on top of the other elements. Because the PPM format which MMPS uses doesn’t support transparency(so far as I, or apparently MMPS, know), I had to select the empty areas and make them transparent using a layer mask. This was made easy by the high contrast between the background elements and the tracing. If I had been working in black and white, it would have been more involved.
Asdakseghzan_mapWhile the process of positioning and scaling the elements was more difficult, I managed this in about half the time I took with Photoshop. There are a number of reasons for that. I’ve had more experience with the process, for one. I also did this in a more hurried and slipshod way; I spent a lot of time in Photoshop refining the fit between elements. The major difference, though, comes down to the crashing problem. If I hadn’t been required to restart the program and retrace the process from the beginning several times(Photoshop usually crashed on the first attempt to open the Save As dialog after using Flexify), the Photoshop would still have been somewhat quicker. Better Transform tools will tell. You may get something for what you pay for, but free is still pretty darned attractive.

Now that we have these existing elements properly projected(more or less), now it’s time to add in the rest of the world and bring this stuff into more robust mapping tools. That’s for the next few posts.

Thank you for reading. Please feel free to comment, leave suggestions or ask questions.
The Astrographer

Posted in Building a Worldmap, Mapping, Planetary Stuff, Projects, World Building | Tagged , , , , , , , | Leave a comment