Showing posts with label minecraft. Show all posts
Showing posts with label minecraft. Show all posts

Tuesday, April 26, 2011

Starry night / topographic oceans

This has nothing to do with either van Gogh or Yes.

It's what I made of the volume beneath a Minecraft spawn point over a period of weeks, culminating in the use of a couple of simple Python filters.  The first converts 1% of a selected volume to glowstone.  The second converts all the blocks immediately adjacent to water into glass.  I used both on the ceiling of a 240x240x56 block volume, resulting in the following.

This view shows the effect of glowstone set in the obsidian ceiling. Sunrise is visible to the left; the far wall is too far away to render. The Temple of Rule 30 exterior is visible on to the right.

Starry Night
Replacing the ocean bottom with glass makes the ocean appear as a contour map of itself.

Topographic Oceans

Here's the MCEdit filter. It only replaces air adjacent to water with glass, so it's up to you to remove the rock/dirt/whatever from the surrounding volume before running the filter. Fair warning: I'm a Python newb.

from numpy import zeros, array

def perform(level, box, options):
 schema = level.extractSchematic(box)
 schema.removeEntitiesInBox(schema.bounds)
 schema.removeTileEntitiesInBox(schema.bounds)

 block_id = 20 # glass

 for y in range(1,schema.Height):
  water = schema.Blocks[:,:,y] == 9
  air = schema.Blocks[:,:,y] == 0
  
  # Shift the position of the water on this level to the four surrounding blocks and intersect this with air
  # to determine which sides should be contained in glass
  
  c= zeros(water.shape)
  c[:-1, :] += water[1:, :]
  c[1:, :] += water[:-1, :]
  c[:, :-1] += water[:, 1:]
  c[:, 1:] += water[:, :-1]
  glass = ((c > 0) & air) * block_id
  
  schema.Blocks[:,:,y] += glass

  # Now place glass below
  
  air = schema.Blocks[:,:,y-1] == 0
  glass = (water & air) * block_id
  schema.Blocks[:,:,y-1] += glass

 level.copyBlocksFrom(schema, schema.bounds, box.origin)

Saturday, March 5, 2011

Minecraft procedural texturing success

Followup to the Temple of Rule 30:  I made another attempt at mapping the output of a 2D cellular automaton to 3D objects in Minecraft and had better luck with a different ruleset.  It can work, provided you choose the rules carefully and work only with large objects.

Here's a sampling of various block mappings used with the same algorithm on a 125 block diameter sphere.

Subtle & mossy
Nested bands of ore
Not-even-remotely-subtle edition
Pig approves.


With a little more work, I might be able to recreate Planet Bitmap from STNG...

Hmm, there's an idea:  Glowing planets in the night sky.  Pity the world is 30 million blocks wide but only 128 blocks tall.

Wednesday, March 2, 2011

Minecraft, Python, and the Temple of Rule 30

I've noticed in my recent job search that Python is a commonly requested scripting language.  I haven't really had much interest in learning it; several years of Ruby (on Rails), a long stretch of Perl, and various other languages at various levels of abstraction ranging all the way down to assembler have made it quite clear that there are only so many ways to express a control flow statement.  I feel that a computer language, as with any tool, should include staying out of your way as a central part of its design philosophy.  Ruby is very good about that.

So why learn Python?  Because it's frequently used as an embedded interpreter.  It's used to control and extend other software.  But what does this have to do with Minecraft?  MCEdit includes a Python interpreter, and I've been using MCEdit quite a bit.

I decided one day that I'd try to clear a large ziggurat-shaped space underground using more or less the same techniques used for TNT drift mining, only without leaving any of the intervening walls standing.  I'd clear the whole space and make the walls nice and tidy.

Right.

As amusing as it is to blast the hell out of stuff in Minecraft, clearing layers of 5x5x5 chunks became mighty tedious by the 5th layer down, at which point the floor was roughly 45x45.  Roughly, because some very large dirt and gravel inclusions were making a mess of things.  There was still a long way to go to bedrock.  I have my kinks, but holding down a mouse button long enough to remove or replace c. 73,000 blocks and calling that "fun" isn't one of them.  It was time to bring the power tools into the sandbox.

A long editing session brought the the pattern down to bedrock, exposing an existing railway and a bunch of deep caves I'd explored earlier.  I cleared out the lava and cleaned up the walls.  Here's the result.  The floor is 125 x 125, with torches in the middle of each visible 5x5 face.


Great!  All done.  The simple repeating patterns of light and dark and the hundreds of pinpoint torches looked quite nice.  But after riding through it and viewing the room from many angles, I thought it was missing a little something.  How about some texture?

This is where Python comes in.  Why not script a volumetric texture generator and use it to "paint" the world?  I had a vague idea that cellular automata might be up to the task, rather than using discrete samples of continuous functions.  Water and lava already appear to follow CA rules, and Minecraft is basically a voxel space you can walk around in.  This seemed a perfect match.  Elegant, even.

It's been a long time since I played with CA.  It's a topic I revisit every few years as a sort of touchstone for how insanely fast microprocessors have become,  like watching real-time fractal renders on a GPU while still having a memory of waiting for a single low-res Mandelbrot render to fill in one scan line at a time on workstation-class hardware.  Well, it's 2011, and now we have Golly and people simulating Conway's Life inside Conway's Life (sort of) just because they can.  I love it.

I experimented with Golly for a while and decided to implement a Generations algorithm with NumPy.  Generations is Life-like, but cells which are marked for death are not zeroed out immediately; instead they age for a certain number of iterations before they are removed from the grid.  This spreads out the active growth regions and tends to make the patterns flow rather than shimmer.

After a lot of trial-and-error, I was able to fill a 3D selection within MCEdit using two dimensions for the CA grid and one for time.  It worked, and I learned a bit of Python and NumPy in the process.

There was only one problem:  The results looked awful.

Within Golly, iterations of the Generations rule are expressed as video, with subtle changes in color indicating the changing age of each cell.  The result is a gnarly, mesmerizing wash of color.

Generations rule S2/B13/15 starting with only 5 living cells,
at 20, 100, 500, and 1000 iterations



But regardless of how I mapped the CA into the world, the subtlety was lost.  It always looked either streaky or random.  Part of the difficulty was the deliberate lo-fi look of Minecraft itself -- a smooth color palette isn't really possible -- but it was mostly due to the translation of time into depth.

Back to the drawing board.  I could continue to tweak the 2D CA and mapping rules to look for a pleasing translation, but a different approach might be more appropriate for this particular application.

How about a 1D CA instead?  I could run a 1D rule to create a 2D array and then project that into the 3D world.  This simpler approach actually looked much nicer in tests.  The most complex part turned out to be the projection of the texture onto the "front" of an MCEdit selection volume which has no knowledge of where the camera is located.  I handled this by requiring that the center of one side of the selection contain nothing but air; it's assumed that the camera isn't inside a solid object.

Here's the final appearance.  All the torches have been eliminated and the walls "textured" with glowstone and obsidian based on Rule 30.


Sort of a cross between TRON and the Luxor Las Vegas.  :)

Sunday, February 13, 2011

Large Constructions in Minecraft

I've been goofing around with Minecraft single player since alpha-something-or-other.  Legitimate spelunking can still be fun, but I also enjoy building improbably large things.  This is really only made practical by the wonderful MCEdit.

Here's a 144x144x128 mob trap.


Outside view showing the scale of the building. (v.2, different world)


The top half is made of pitch-black spawning trays and short canals ending in 2x2 holes.  The bottom is mostly empty space, partly filled by a large number of falling / drowning traps.  The key to the design is the observation that the potential spawning zone is (currently, as of beta) a subset of a 17x17 chunk volume, which contains many millions of blocks, but the active mob cap is quite small.  The goal here is to both control most of the spawn volume and to kill everything in it as quickly as possible in order to allow new mobs to spawn.  None of the canals in the spawning zone is more than 15 blocks long.  Each one ends in a very long fall into shallow moving water, which then leads to a drowning trap for the mobs not killed by the fall.  The very bottom of the structure is just a network of collection canals.

The distant wall appears to be made of floating blobs because I converted all the rock in the surrounding areas into glass; the sky blue color is actually distance fogging and the blobs are everything that isn't rock.



I liked the "visible Minecraft" effect so much that I built a 10 km railway with all the surrounding rock, dirt, and gravel converted to glass.  Gold ore was converted to lightstone for additional underground illumination. 


The effect is visible at night through the bottom of the ocean.


Sunrise seen through a hillside.




And now for something completely different:  A forested crater which extends all the way to the rendering horizon.


Night view.


The original site was mostly ocean.  The crater was constructed in MCEdit by creating a very large sphere of dirt using the brush tool, then creating a slightly smaller sphere of air centered within the dirt, also using the brush tool.  Technically this was only a section of a sphere, as it was made much larger than the 128-block maximum height in order to keep the steepest part of the bowl shallow enough to hold trees.  The portion of the bowl above sea level was then deleted, and the crater rim integrated with the surrounding landscape in-game using pick, shovel, and dynamite.

But this just left a big bowl of dirt.  I wanted the area to be heavily forested.  How do you generate thousands of trees?

MCEdit filters to the rescue!  I learned enough Python to write a filter which picked random x,z coordinates within a selection block, located ground level, added a sapling there, and changed a nearby empty block to lightstone to help the sapling grow.  Then I entered the game and waited.

Once the forest was fairly dense, I dynamited several points on the rim and cleared out some of the foliage in order to create a network of waterfalls and rivers leading to pond in the center.  Next I added a rail terminus leading to my spawn point.  The last few steps were cleanup:  Removal of ungrown saplings and redundant lightstone blocks, both of which were performed with Python filters, along with a lot of detail tweaking in-game.

I'd originally planned to remove the lightstone after the trees were grown, but I found I really liked the effect at night.