Races of the UNSEO – The Vugoa


The Vugoa really started as an expy for Traveller’s Vargr in my old Solar Union milieu, they’ve changed quite a bit since then. The Vugoa still have a largely canid appearance, and live in a similar ecological niche, but I haven’t decided yet if they are actually derived from Terran canines. Not uplifted in any case, but the World of the UNSEO does contain Echoes of Earth. On the other hand the Vugoa could be no more related to dogs than Aslan or Kzinti are to cats.

The Vugoa inhabit the planet Asdakseghzan, the planet previously partially mapped in Projecting a Map From Imagery: Photoshop and Flexify. I’ll deal with further details of the planet in a future post.

The social aspect of the Vargr was the strongest draw that led to the adoption of the Vugoa into my imaginary universe. I liked the idea of highly social(even, in GURPS terms, Chummy) intelligent people who find it very difficult or even nearly impossible to organize into large social groups. I’ve played around a bit with the notion of Vargr ‘Charisma’ in order both to enhance the alienness of the Vugoa and also to drive the formation of interesting cultures.

Pheromonal signals are universal among the Vugoa. There are essentially four social states among the Vugoa: alpha male, beta male, gamma male and female.

There’s a single alpha male leading each pack. All other males in the pack are betas, who follow the alpha and have essentially equal status(there is a small non-persistent variation based on the current reputation or esteem of each individual and his degree of confidence; even in a particular individual this will vary significantly with time).

The alpha male is the core of the Vugoa pack. The pheromone-driven ‘charisma’ of that alpha male is the cement that brings and holds the little group together. Hormonal changes that take place when a male accepts an alpha as his superior reduce the effectiveness of his own pheromones. This has hampered attempts to create more layered ‘packs of packs’. An alpha ‘baron’ that gives fealty to a higher alpha ‘king’ will find his ability to maintain cohesiveness in the pack will falter. Most likely he will simply become a beta in the pack of such a would-be king and most of his pack would simply wander off as gammas and free females to find or create a new pack.

Males who are not currently part of a pack(adolescents who chose not to join their parent pack and former members of a pack which has broken up) are considered gamma. Gamma males, sometimes referred to, very impolitely, by humans, as “lone wolf” Vugoa are continually in search of a compatible pack. If they fail to find a compatible pack, they will often form a new pack, with an alpha gathering a coterie of gammas with his charisma who will become the betas of the new pack. Even a highly charismatic gamma will only rarely challenge the alpha of an established pack as, in the event of a victory by the gamma, the members of the pack will seldom stay together under the gamma, but most will instead wander off as gammas themselves. A victory over an alpha will, however increase the charisma of the gamma in question, thus increasing his chances of becoming an alpha in a new pack. The most likely situation is that the gamma finds a pack with an alpha more charismatic than himself and joins that pack as a new beta.

Although packs typically disperse if the alpha is defeated or disgraced, packs can survive the death or willing abdication of their alpha. There is usually a transition period, during which the males are considered deltas(a temporary, transitional state, thus not really considered a fifth social status), the males vie among themselves to determine the most charismatic who shall become the new alpha. Thus have some packs persisted for many lifetimes. This is also one of the very rare opportunities for an outsider gamma to become the alpha of an established pack.

The female is generally something of a free agent within the pack structure. Females have far more traditional and legalistic social hierarchies. Females also tend to gather in larger, more geographically-structured social constructs. Females are also only loosely bound into the pack to which they ostensibly “belong”. Frequently, when the alpha male of a pack decides to move on to a different location, while the beta males will follow along, the females will frequently disperse to other packs in the area rather than leave.

Due in part to anatomical differences, males and females inhabit different, but parallel cultural models. While Vugoa females are receptive to pheromonal signals, and in fact produce pheromones of their own to communicate mood, sexual receptivity and the like, pheromones confer no persistent hierarchical status to individual females. The social order among females is both more fluid and more legalistic than among males. While females retain a sense of identity with their pack and its alpha male, they are much more capable of forming bonds with other females outside their pack. As the male order very much travels with the pack and its alpha male, the female order is far more territorial. This has proven significant in forming larger social conglomerations among the Vugoa.

Another structure that has been significant in the formation of larger social structures in Vugoa culture, is the pair bonding. Alpha males never pair bond, instead forming loose, temporary relationships with a small harem of typically young females who are generally considered as the pack’s females. Although formally the members of this harem are considered to be the alpha’s mates, they are, outside of the alpha’s immediate attention, available to any beta male of the pack who is not otherwise pair bonded. Older or more successful betas will eventually become pair bonded with one member of the harem, effectively removing that female from the alpha’s harem  and creating an exclusive mating relationship between the beta male and the female in question. If the pack’s alpha chooses to migrate and the pair bonded female refuses to follow, the beta male must stay with the female and become a gamma until or unless he can find a new pack in the area. This creates one of the strongest bonds between male and female Vugoa society as pair bonded males must stay under local female laws and alphas of older, well-established packs risk losing a significant part of their beta following if they choose to relocate, perhaps in protest to dictates of the local female legal structure.

The packlord structure in Vugoa society is based on a voluntary and conditional cooperation between multiple packs. “Packlord” is the term for an alpha male in this structure. Although packs are only weakly bound to a geographical area, the loose packlord confederacies are almost always geographically contiguous. Otherwise, packlord confederacies are very fluid geographically. Individual packs will frequently leave confederacies to join neighboring ones they find more conducive to their short-term interests or migrate to more hospitable realms. Such confederacies can often be found intertwined with more geographically-oriented polities. Areas considered to be ruled by ‘packlord governments’ are usually possessed of a highly fractious or tribalized female hierarchy. In these cases, even the female culture is nomadic in nature. Typically, this is found in marginal environments such as heavy jungles, high mountains or arid regions or in areas with primitive hunter-gatherer economies.

The monarchies of Asdakseghzan are exclusively led by one or more queens, no kings. The parallel female social structure has driven the creation of most large-scale political structures among the Vugoa, particularly the monarchies. In addition to packlord confederacies and monarchies, some areas of Asdakseghzan are under the control of city-states or even a few republics. Among geographical hierarchies, republics have the most male integration. While alpha males are loathe to subordinate themselves to the rule of a majority, fewer still would willingly abdicate voting power to other males. Thus male participation in republican governance is fairly common. This is unusual, as for the most part, unless faced with some kind of Lysistrata Gambit, most alpha males treat the feminine geographic states as little more than a formality.

The Vugoa, with their footloose males structured into small mobile pack groups and settled females structured into larger geographical societies, present an interesting challenge to the development and maintenance of persistently organized civilizations. The existence and success of such civilizations on Asdakseghzan is a tribute to the resourcefulness and intelligence of these canid alien beings.

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

Pixar’s 22 Rules for Storytelling

A very helpful bit of writing advice from the people at Pixar. Enjoy.pixar22rulesNow it’s time for me to apply Rule 11. See you soon!

The Astrographer

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

Protected: WIP: Ytosh Outline

This content is password protected. To view it please enter your password below:

Posted in World Building

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