Building Better Worlds

Design for RepRap Mendel inspired wooden 3D printer

2010-06-08T15:11:00.001+03:00

I've been working on a simple design for a RepRap Mendel inspired 3D printer, buildable from wood and metal beams (I've abandoned my previous boxed reprap design for now). The design goals are:

Keep the design simple
Keep construction easy
Keep material costs low
Keep the machine functional

I used OpenSCAD for the design. It's a CAD program that creates the model from a script. This allowed me to make the design parametrized, allowing you to specify the size of the used wooden beams, motor type, rod diameter, and target size of the machine as parameters. My script even prints out a part list with the measures of each part and the calculated print volume (unfortunately it isn't possible to calculate hole drilling positions).

Not counting fasteners, bearings, or the print head, the current design has 40 parts; 16 lengths of wooden beam, 6 threaded rods, 6 smooth rods, 5 pulleys, 3 belts, 3 motors, and the print surface. The maximum print volume for the current default configuration is 25*20*20 cm.

By tilting the side support rods inwards towards the top I hope to increase the resistance against sideways shearing forces.

I haven't designed the print head yet, I'll probably take a closer look at what nophead, wade, and the mendel and makerbot teams have achieved in that area, and maybe just go with pre-printed parts for it.

The OpenSCAD files are available on github, feel free to play around and borrow from them. Once I've built the design and verified that it works well, I'll upload it to Thingiverse.

Additional screenshots:

Setting up Hudson on port 80 on a Debian or Ubuntu machine

2009-11-26T00:52:00.006+02:00

To my delight I discovered there is a debian package of Hudson nowdays. Installing it was pretty straightfoward, but I wanted to configure hudson to be visible on my server at myserver/hudson, instead of myserver:8080, for a project I'm in. That turned out to be quite a bit more complicated, but I got it done in the end and documented the process here for others and my own future reference.

My server is running Ubuntu 8.4 Hardy, but the instructions are relatively generic.

Installing Hudson deb package

The Hudson package is not in the default repositories, but that wouldn't be too useful anyway as it would be hard to keep up with the frequent Hudson releases.

Installation instructions for installing the deb package, or see the wiki page for more discussion.

By default the hudson deb package will install hudson in /var/lib/hudson, which also contains a config.xml with some options. Command line options can be found in /etc/default/hudson. The hudson log is in /var/log/hudson/hudson.log. You may want to run

    tail -f /var/log/hudson/hudson.log

while debugging the installation.

You can start Hudson with:

    sudo /etc/init.d/hudson start

Hudson should now be running on port 8080 of your machine.

Remember to register a user and set up access control if you are running the machine on the public internet.

If needed, you can stop Hudson with:

    sudo /etc/init.d/hudson stop 

Hudson on port 80

To set up Hudson to run on port 80 (the normal http port) instead of 8080 you could edit /etc/default/hudson and add --httpPort=80 to HUDSON_ARGS. However, running a service on any port below 1024 requires the service to be run as root on Linux, which is not such a good idea for a compex Java application. If you try to start hudson with the --httpPort=80 argument in /etc/default/hudson, you'll get a "java.net.BindException: Permission denied" exception in the log.

It appears the standard procedure is to run apache (or another webserver), and configure it to hand over processing of a certain path to Hudson. Mod_proxy seems to be the way to go.

Hudson Prefix

We want to see hudson running on servername/hudson/. The first step is to change the prefix hudson uses, so we get from servername:8080/ to servername:8080/hudson/. To do that, add

--prefix=/hudson

to the HUDSON_ARGS string in /etc/default/hudson and restart Hudson with e.g.:

    sudo /etc/init.d/hudson force-reload

Apache

If you don't have apache installed, use

    sudo apt-get install apache2

to install it.

mod_proxy

In many distributions it should be included by default with apache, but you may need to install the mod_proxy module separately:

    sudo apt-get install libapache2-mod-proxy-html

In any case you need to enable it with:

    sudo a2enmod proxy

    sudo a2enmod proxy_http   

By default it is configured to deny all proxying, so edit /etc/apache2/mods enabled/proxy.conf to allow proxying:

    ProxyRequests Off

    <Proxy *>

        Order deny,allow

        Allow from all

    </Proxy> 

[Note that messing up proxy configuration could leave your server as an open proxy, so proceed at your own risk. I'm just copy pasting code from documentation without fully understanding it...]

In your /etc/apache2/sites-enabled/ directory there should be some file like 000-default or similar, with settings for the site. Add proxy configurations in it for mapping the /hudson path on the website to localhost:8080/hudson:

    ProxyPass /hudson http://127.0.0.1:8080/hudson

You can of course use some other path than /hudson too, in that case remember to also use it with the Hudson --prefix parameter above.

In my case the file looks something like:

    <VirtualHost *> 

        # various stuff ....

        ProxyPass /hudson http://127.0.0.1:8080/hudson

    </VirtualHost>

You can stop and restart apache to enable the new configuration, or just use:

    /etc/init.d/apache2 force-reload

And you can follow the apache logs for troubleshooting by running

    tail -f /var/log/apache2/error.log

Good luck, and feel free to suggest improvements to this configuration in the comments.

Configuring irssi with UTF-8 and spell checking

2009-05-25T12:57:00.006+03:00

I'm switching to using IRC with irssi running in a screen instance on my virtual server. The advantage over running xchat or similar on the desktop is that one can connect from anywhere and disconnect in between without loosing the backlog.

With scripts for irssi it's possible to get most of the comforts of a GUI client, such as nick coloring (nickcolor.pl) and spell checking (spellcheck.pl).

I had some problems getting nordic characters to work, but the solution was to switch everything to utf-8:

The terminal

In gnome terminal menu, Terminal->Set character encoding->UTF-8

The remote environment

Add export LANG en_GB.UTF-8 to the end of ~/.bashrc

The screen session when starting irssi

screen -SU irc irssi (creates a screen instance named 'irc' using UTF-8 that runs irssi)

In irssi

/set term_type utf-8

So not really out-of-the-box as in some GUI clients, but hopefully a bit easier to google now.

The spellcheck.pl script didn't work with UTF-8 out of the box either, aspell needs the --encoding=UTF-8 parameter passed to it to work with non-english characters.

To install spellcheck.pl for irssi with utf support:

Log in to the machine you run irssi on
Install aspell:

sudo apt-get install aspell libtext-aspell-perl aspell-en aspell-de aspell-fi # and so on for the languages that you want spell check dictionaries installed for

cd ~/.irssi/scripts # if the scripts directory doesn't exists, create it
wget http://scripts.irssi.org/scripts/spellcheck.pl #downloads the original spellcheck.pl

Edit spellcheck.pl and find the line

    $speller{$_[0]}->set_option('sug-mode', 'fast') or return undef;

Add a new line after it and save:

    $speller{$_[0]}->set_option('encoding', 'utf-8') or return undef;

In irssi, write /script load spellcheck.pl
You can specify what language spellchecking should be used in different channels by typing /set spellcheck_languages NetworkName/#channelName/TwoLetterLanguageCode in irssi. Default seems to be english.

Update:

Aspeller seems to be a bit more user friendly spellchecker, as it doesn't spam the window with spelling suggestions, just highlights the misspelled words. Unfortunately it doesn't allow specifying channel specific languages. There's also spell.pl.

Boxed Reprap Design 0.3

2009-04-18T14:18:00.010+03:00

Here's screenshots of latest version of the boxed RepRap design I've been working on. It has some major differences from the last version, such as a completely mobile toolhead platform, and a fixed bed. The electronics were also moved on top instead of underneath.

First an overview shot:

A 50*50 cm acrylic door covers the front. The upper front panel hides the electronics, and can have holes added for status LEDs and the like.

The top also contains the plastic feedstock, and has room for additions (such as a small dust extraction system for milling for example). The heat generated by the electronics and the ATX power source is fed into the box, to help keep up the ambient temperature to enable warp-free printing.

The above picture shows the Y assembly, sliding back and forth on skateboard bearings running along aluminum L beams.
The X assembly.

And the Z assembly, without mounting holes for the toolhead yet. I was thinking of some kind of automatic head switching system, but decided to just build for manual switching using wingnuts to start with.

In total, the effective work area is around 30*30*15 cm, and the external dimension is around 50*60*60 cm.

I've got the tools and materials (although the Plywood I got is a bit bad quality - don't use class C and D plywood for this kind of projects), so I'll start cutting up and putting together the pieces now.

Flowpaint 0.2 released

2009-04-03T14:30:00.006+03:00

Last weekend I released version 0.2 of Flowpaint, my open source paint program project.

Here's the short summary:

Flowpaint version 0.2 is now released! It adds undo, detailed parameters for brushes, a 'recent brushes' - feature, dramatical speedup by dynamically compiling code, and a new set of default brushes. In addition tablets with pressure are now supported also with the Java Webstart version. Flowpaint is still in Beta phase, use with care.

And here's the full release announcement and download links.

I was demonstrating it live at a comics festival in Tampere on the weekend, in between manning the Pirate Party table there. It was a nice event, with a quite good match between the target audience of Flowpaint and the people there (our table was in the room for independent and self-publishing comic artists).

There's several features I'd like to add that I think could be useful for editing comics in Flowpaint. One such is the ability to compose one picture with several frames that show other pictures that are updated when the original pictures are updated. This concept could also be used for things like brush strokes textured with a picture. In addition, tools like procedural brushes or images could be utilized for creating picture components once and re-rendering them with different parameters to quickly create unique detailed backgrounds (simple examples would be a forest or city composed of randomly placed tree / house outline images).

First I have to get more of the basic features implemented and working though. Layers and picture loading are being requested in the poll on the Flowpaint homepage (the results from the previous poll are archived in the wiki). The rendering quality is also lacking, brush strokes look a bit jagged, and there's some artifacts when a brush stroke turns. I'm going to extract the rendering logic into a separate library, Rasterfun. It will allow loading and displaying Flowpaint images also in other (Java/Scala) applications. One other usage for it could be to render fractal / procedural landscape heightmaps for games (such as my Skycastle project) - in this case Flowpaint could be used as a map editor. This requires defining a good file format to represent Flowpaint images in.

Putting a RepRap in a Box with a Mill

2009-03-11T21:52:00.014+02:00

I ordered the BitsFromBytes RepRap kit v 2.0 last summer. I put it together just in time for the Alt Party 2008, and even got it to extrude a bit. Above is a picture of it at the Pirate Party booth, nicely illuminated by a 12V RGB LED rail. Thanks to the guys at the party who helped me to wire up the heater and test it!

However, there were multiple problems with it, and I shelved it for half a year and went to work on other projects (the major problem was that I had decided to try using ball-chain with custom drive wheels instead of the standard (but expensive) drive belt)

I took a look at it again recently, but decided to try building an own design from scratch instead of fixing it (yes I know, probably more work, but I'm a designer at heart :) ). Hopefully some useful insights come from this new project.

My goal is to create a simple design that can be easily constructed with a small amount of standard parts from a well sorted hardware store (plus electronics ordered over Internet from e.g. the rrrf store). The design should be relatively modular, with possibility to easily remove the different axis assemblies and toolheads from the box for maintenance and upgrades (the laser cut RepRap designs take a lot of time to put together, and to take apart and put back together if you want to change some part..).

I decided to put the 3D Printer in a box, as it seems that printing in a hot ambient temperature around 50-70 degrees Celsius eliminates the warping of plastics. A box also provides a sturdier frame, which could allow operating a CNC mill with the same positioning system, opening up an additional range of materials, as well as circuit board milling and drilling. The box also neatly contains the unit together with fumes and dust, making it nicer to use in a home.

I made this initial design in SketchUp, which is an excellent tool for this type of work (unfortunately I could only get version 5 to work with Wine under Ubuntu).

The box itself can be made from MDF board or Plywood with 3 cm wide wooden beams to support it. It's a bit small in this design, I'm planning to make it 50 cm wide and 60 cm deep and high in the next design iteration. I placed the stepper motors outside the box, as they are rated for at most 80 degrees celsius.

I use threaded rod to drive all three axes in this design, it's probably ok for milling, but maybe somewhat slow for 3D printing. On the positive side, the wooden box design makes it a bit easier to switch to a belt drive later if needed. Another alternative would be to use larger diameter threaded rod with some gears to speed it up.

The Z motor movement is transmitted through a bevel gear that slides along a rotating square-profile aluminum extrusion. I'm not sure how well that would work, and it would also require a custom-made part, so I will probably change it in later design iterations. This picture should illustrate it:

The stepper motors will be attached directly to the lead screws like this:

A possible improvement could be to add smaller diameter aluminum tubing to the stepper motor end to achieve a tighter fit.

It's not visible in the pictures, but I'm planning to use skateboard bearings attached to an L shaped aluminum extrusion for the linear bearings, as described on buildyourcnc.com.

I put the electronics in a drawer underneath the main box, so that they can be easily accessed, and so that heated air can be blown from the power unit and stepper controller cooling fins up through a vent to the main box, to create the preheating required for warp-free plastic extrusion.

I'm currently working on a second version of the design, which rearranges things (changing to a moving x axis and stationary bed to allow automatic tool change, and moving electronics and dust collection to the back of the machine instead of a drawer). I will post more when I get the design finalized and start building.

Edit: Added closeup of z platform.

Representing real resources in a virtual world

2009-02-21T13:57:00.003+02:00

In a virtual world with self replicating or easily constructible complex objects, there is a certain conflict of resource usage between the virtual world and the real world. Something that is easy and cheap to construct in the simulated world can bring the real world computer system simulating it to a crawl.

A way to restrict unlimited growth is to introduce environmental resistance in the virtual world. For example, building things could require resources, and running them could require energy, both of which could be in limited supply.

However, if a reasonable approximation of the real world is simulated, the resources and energy requirements will be quite hard to balance so that the simulating computer is not either overburdened or clearly underused.

A solution to this could be to introduce tokens in the virtual world that correspond to real world constraints and resources. For example, to construct a new object would require an object token, which approximately represents the amount of memory used by one object, and the amount of processor power required to simulate its interaction with the environment. To run some scripts / AI routines in the virtual world would require a token that represents the approximate CPU time used by a script (loops and recursion would be either disabled, or done on subsequent execution callbacks, to keep the CPU usage of a single script each world update more or less constant).

The tokens would be initially placed in a free pool. To create a new object / script in the simulated world, free tokens would be needed. Tokens could be requested from the pool and divided randomly between the requesters (or just dropped into random places in the simulated world). Tokens could also be exchanged between objects within the simulated world (for example by destroying an object and taking its tokens, or trading tokens for virtual money, depending on the type of simulation).

The object and CPU tokens could either completely replace other simulated resources (for a Tierra style abstract simulation), or used together with, or embedded in, conventional resources in more complex simulations (e.g. require lumber, metal, and an entity-crystal to craft an item in a fantasy themed gameworld).

The total amount of tokens in the simulation could be kept constant, or the amount adjusted based on memory and CPU load by adding or removing tokens from the free pool.

Flowpaint 0.1 Released!

2008-11-24T13:27:00.005+02:00

Flowpaint version 0.1 has been released!

It's my first open source project that I have gotten as far as a public release :-)

I've been staying up until four (or even nine) the recent weeks and weekends working on it, but it's been mostly fun hacking. I automated as much as possible of the release process also, so it should be much less work for the next release. I'm doing cool stuff like autogenerating the changelog from the google code issue database (I'll post the python code in a later post), and injecting the release version and build number into property files baked into the application jar.

For the next release (which I hope to finish in a month, just in time for xmas) I'll have to refactor the rendering system and include undo history in it (that could be somewhat challenging). I'll also get to add input sliders for brush parameters (that should be fun). I wrote down my ideas for the painting rendering pipeline in some design notes in the Flowpaint wiki.

Starting the FlowPaint project

2008-11-14T01:36:00.006+02:00

One of my long term goals is to create a good paint program. I have several features that I'd like to see in a paint program, but that none of the current ones have.

I have some code for a half started one in the scratchpad directory of Skycastle, but now I went ahead and created a separate project for it. As usual, the hardest thing is to come up with a name - FlowPaint is refering to the state of flow that happens when you are immersed in painting - the application should support the workflow, instead of interrupting it.

You can find the development site of FlowPaint on Google Code.

Among other things, I want to render brush strokes as continuous textured areas, instead of repeatedly stamping a brush outline at short intervals along the stroke path like most existing paint programs do.

Here's the result of an evenings prototyping with Scala:

The stroke segment is defined by a start and endpoint, and the brush angle at the start and end. The renderer loops through the pixels to render, and calculates the position along the brush path, and the distance from the center of the path for each pixel, and then uses those values to query the brush implementation for a value. In this case the test brush returns a gradient to white towards the edges of the brush, and a gradient from red to yellow along the path of the brush. But it's also easy to write a brush implementation that instead uses a texture instead of a gradient to determine the color for each pixel. This opens up a lot of possibilities for the artist to produce complex patterns easily.

The prototype shows that the basic stroke segment rendering algorithm works, but performance is still a possible issue (the application will need to render a lot of segments fairly quickly, and re-render a part of the entire image when it is zoomed or panned significantly). A further spike to test out more optimized ways of rendering is likely needed (I scrapped my earlier plans for using 3D rendering, as render to texture isn't supported on the Intal graphics card on my tablet PC, and it would have caused a lot of trouble anyway).

Scala was very nice to work with. The prototype uses 9 small helper classes for things like Points, Lines, Brushes, etc. Often these are just one line in Scala. In Java each of these would have required an own file, and a lot of broilerplate accessories and constructor parameters, probably around 50 lines per file, including blank lines and comment lines. With Scala I can focus on thinking about the algorithm instead (the whole prototype is around 200 lines now, including blanklines and a few comments). I'll definitely continue using Scala for FlowPaint and future projects.

Curvy Component Connections

2007-09-13T01:36:00.002+03:00

Above is a representation of the component graph used to generate the procedural texture in the previous blog entry (click image for full size version). The components are created with the NetBeans Visual Library, which seems very well suited for component based graphs.

I implemented a custom Bezier spline based connection path. I feel that it is easier to read and understand than one with straight lines, or non-overlapping connectors automatically routed in a manhattan grid (axis aligned, only right angles). The curvature of the connection adds some extra information; it is easier to see if a connection is going backwards or forwards, or spanning a long distance or a short one.

Researching splines took a surprising amount of time again, there was no simple cut-and-paste Java code available either. I found the Unraveling Beizer Splines article on GameDev.net informative and simple (despite some typos in the code), the Wikipedia article on Bezier curves has nice animated graphs, but was a bit too theoretical to base a quick implementation on.

The resulting Java spline code is available, if you want to use it.

On The Fly Compiled Procedural Textures

2007-09-08T20:51:00.002+03:00

The procedural textures from the last time now have source code generated and stitched together for each component, and compiled on the fly using Janino. A trippy example texture can be seen above, created using four sin components, connected to inputs that change over the texture area, and outputs for producing red, green, and blue color channels.

The rendering time seems to be around 1 second (compared to about 5 seconds with a non-compiled implementation). I suspect the difference will be more marked with more complicated textures, as there is some overhead when the data is copied to a BufferedImage for rendering.

I ended up having to implement a Topological Sort algorithm for the dependency ordering, and a Cycle Detection algorithm to prevent creation of cyclical dependencies between components (I implemented that after spending about six hours trying to figure out what was wrong with the other algorithms, when there was a simple typo in the example code, causing a cyclical dependency). This paper on various graph algorithms was an useful reference.

Implementing the graph algorithms wasn't that straightforward, so I was considering using some existing graph library instead, especially as the next step will be to visualize the component graphs and edit them in a UI. However, it seems there are not many library aimed for graphs of components that can be connected to each other through input and output ports except for JGraph, which is a bit daunting in its complexity. A promising alternaive seems to be the NetBeans Visual Libray, which is aimed at graph visualization and graph oriented modeling. It would seem to be a perfect fit, provided it doesn't depend on all of NetBenas (doesn't seem to), and has a flexible enough model, and customizable visualization.

Playing With Procedural Textures and Code Generation

2007-09-05T23:39:00.001+03:00

I'm working at a procedural texture system for Skycastle at the moment. The intent is partly to get a useful and fun texturing tool to play with, and partly to create a spike for exploring what a more generic component oriented procedural content editor should be like.

Based on some initial tests that just calculated random pixel values, it soon became evident that having components calculate the values and request calculated values from other components would be quite slow, so I decided to explore on-the-fly code generation. Janino seems to be one of the established libraries in this area. Janino has the advantage of not needing the Java compiler (which is only available in the JDK, not the JRE), instead it actually implements a large subset of a Java compiler.

Currently I'm doing some prototyping on what generated code would look like (by just writing it out by hand). An interesting looking result obtained with four sin functions and some constant parameters for them is shown in the screenshot. It is still slow (about 5 seconds for a medium size window on my T60 laptop), so I was thinking of including the whole pixel iteration loop in the generated code, to eliminate any method calls for each pixel.

Skycastle on Launchpad

2007-07-23T22:15:00.001+03:00

I came across Launchpad recently. It seems to be a kind of common bug tracking and release management tool for open source projects, initially created for the needs of Ubuntu, but opened up so that any project can use it.

It's geared slightly towards larger projects, but it does provide a working looking bug tracking and release planning tool, so I decided to use it for Skycastle.

Vector graphics figure for isometric game

2007-07-12T02:50:00.002+03:00

Here's the result of some experimentation with using vector graphics for rendering player figures.

It composes the figure from 'bone' shapes that are basically a line with rounded ends, where each end may have a different thickness. It also has a cell shading like shadow on one side, and antialiased highlight and shadow outlines (this helps to hide the otherwise quite jagged polygon outlines). The cell shading is just going down the middle of the bone currently, it will probably look better once it is bent a bit to either side.

I'm planning to divide the arms and legs still so that the figure has elbow and knee joints, and add hands and feet (I already did a test of a rotating arm with a hand earlier, and it looked nice).

For the head, I was thinking of drawing eyes, eyebrows, and mouth on it with simple antialiased lines. The hair could probably be approximated with a few polygons.

On the skirt front and back a custom bitmap image will be pasted, using a skewed bitmap renderer similar to what is used for walls.

So far I'm pretty happy with the result, with a bit of tweaking it should be a passable cartoon like figure. The next step is to figure out how to animate it..

Isometric Fun

2007-07-10T01:44:00.001+03:00

I started working on an isometric game engine over this weekend, this time written in Python. I was inspired by the One Laptop Per Child project, and was thinking that some of my world editing ideas go well with their constructionist learning philosophy.

The end user experience could be something akin to building and playing with Legos together with friends, although the building blocks should be larger and more functional. No built-in game goals, but players might be able to define ones themselves. Maybe there could be some kind of toggle to switch between Build and Play modes.

The limited memory footprint of the OLPC laptop (no hard drive, only a few hundred MB of flash memory) imposes restrictions on the amount of media and map data that can be stored in a conventional way, so I'm also planning to experiment with procedurally created maps and graphics (the map above is defined with one ProbabilityMapFill, that selects between normal and flowering grass tiles, one WalledMapFill, that builds walls around a specified area, and a SolidMapFill, that fills the same area with an earth tile).

The mesh-networked nature of the One Laptop Per Child machine also means that this would be a peer-to-peer game, not a conventional client-server setup. Anyone could start or resume a game session, and invite others. Constructs and pieces of landscape created in a session should be possible to keep for later, and to share with others.

I'm not sure yet how side-tracked I'm going to allow myself to get with this project, but so far Python is relatively nice to code with, despite a few oddities and the lack of an IDE with rename and code navigation features.

Setting Up Skycastle Project Infrastructure, Take Two

2007-06-19T20:00:00.001+03:00

Update: I recently moved the Skycastle website hosting to NearlyFreeSpeech.net, as sourceforge was slow and a bit unpractical to use for a mediawiki.

In my first blog entry from end of 2005 I was looking for a hosting and wiki solution for the Skycastle project. I've settled for using SourceForge for hosting, after they started to support SVN.

However, I hadn't really set up any satisfactory wiki for the project. I've been using Mediawiki a bit over at the WorldForge wiki, and really like it's advanced features.

I finally spent last Sunday setting it up on Sourceforge - it is actually possible, although it requires some work (like writing a database driven mail sending script, as direct mailing from web applications on SourceForge is not allowed - I still have to do that).

There are various instructions on the net for how to set it up, although they are not very clear or complete in all cases (on Mediawiki help pages, on László Monda's page).

As an aside, SourceForge also seems to offer a wiki solution now, but it didn't look too impressive - it seems to lack categories, templates, and a lot of other useful things found in Mediawiki. Running Mediawiki also allows me to tune its appearance so that it can be used as a respectable homepage for the project.

Google Summer Of Code - 3D Rendering Pipeline for Geotools

2007-06-19T19:52:00.001+03:00

I'm participating in the Google Summer of code program this summer, working on a 3D renderer for Geotools.

This will be a good opportunity to get familiar with the Geotools library - it might be usable for storing geographical data in Skycastle. I'll also try to make the 3D rendering pipeline usable for real time low altitude rendering with relatively high detail - usable for games, as well as various interactive geographical visualization applications.

Real time generation and rendering of realistic landscapes

2007-04-16T12:49:00.001+03:00

A Dutch landscape painting from 1820 (by Adrianus van der Koogh). A challenging goal to aim for in landscape generation and rendering.

I haven't used this blog much yet, but I was thinking of starting to blog regularly now. So to clear up the backlog, here's my masters thesis on landscape generation and rendering, finished in the autumn 2006.

In it I review a number of algorithms for generating and rendering various aspects of landscapes, from terrain to plants, buildings, and the sky. I also discuss a bit how to use ecotopes to distribute the landscape features naturally.

I tried to illustrate it throughly and make it easy to read, so feel free to check it out. Apart from some of my not-so-interesting building generation experiments in the middle it's mostly a review of existing approaches with a few ideas and improvements of mine thrown in. It can serve as a kind of pre-study for a landscape engine.

Here's the abstract:

With the increasing size of virtual landscapes in games and other applications there is a growing need for generation algorithms that can help designers to produce large realistic landscapes. Parametrized procedural and fractal systems provide this, and also enable on-the fly data generation that minimizes required storage space. Ecotopes provide a way to introduce natural variation in automatically generated landscapes by varying the generation parameters based on the location. Interactive performance can be achieved by using geometry with a level of detail that decreases with the distance to the observer. In this thesis I evaluate different algorithms for generating and rendering terrain, vegetation, buildings, cities, and the sky. New algorithms are sketched out for terrain generation through successive uneven mass deposit, elevation map modifying textures, river system generation, pattern based city generation, and weather modeling. A subdivision based house generation algorithm is also presented and partially implemented. Finally opportunities for further research in conveying emotions with landscapes are identified.

Setting things up

2005-11-28T00:25:00.001+02:00

Hello, and welcome to my blog!

I'm planning to use this blog to publish news related to the Skycastle project, as well as general ideas about virtual world coding, design and anything tangentially relevant, such as AI, computer graphics, or software development processes.

(Skycastle is an attempt to build an open source MMORPG engine in Java. More on it in later posts and on the wiki.)

I'm currently in the process of selecting wiki and source hosts for Skycastle. I have been keeping the code on SourceForge, but as CSV requires a network connection to add or remove files it makes it impractical to edit the source on a laptop while commuting as I do currently, so I have been looking at JavaForge (they provide subversion support). (EDIT: Now that SourceForge also provides SVN, I'm staying there).

The wiki at JavaForge didn't look too impressive though, so I'm considering either using wikispaces or my own server machine (which is on a relatively slow ADSL line). I'm leaning towards wikispaces currently. (EDIT: I'm currently planning to run a Mediawiki on SourceForge instead)