Making noise with Maggy

This past week or so, whenever I can I’ve been tinkering with the visibility testing, and LOD’ing – but having no real success. Nothing I’m trying seems to either a) work, or b) work as I’d expected. I get something that seems ok, and then I pause the testing and pan back to find loads of patches rendered which shouldn’t be. So that’s still all up in the air at the moment.

To cheer myself up, I decided to start experimenting with more noise functions, scouring the web for any and all published examples, techniques etc that are fast enough for Maggy to use.

I now have quite the collection (15) and the results are largely all in the video. One thing I found whilst googling was that most sites happily yield code but don’t show what the output is (for all their uses) or happily show the output, but don’t yield code. My math days are long behind me, and basic awareness of what’s going on inside these noise functions is all I can manage!

So, my aim is to produce a static C library (as mentioned before) with all these functions and variants in, which are replicated on the GPU as GLSL shaders, with example images of the output! Then share this so everyone can make use of it for their own ends.

In the meantime, I’ve (kind of) created a simple shader template, which allows me to cut/paste a given noise function in without too much hassle. This has got me thinking of a ‘pre-shader-compile, compile’ stage. Shaders (in their raw form) are just text files of ‘C’ like code, which get passed directly into the OpenGL driver to compile and link into an executable binary on the GPU.

So, if I write a small parsing section before I hand it to OpenGL, I can use a bare-bones shader and then introduce a step like ;

#include “noise/perlin3d.h”

to bring in the text file containing that function. Voila, a data-driven, run-time compiled shader on demand.

At least, that’s the theory 🙂

Now I have all these wonderful toys, I need to start working on bringing them together to form a varied, credible terrain. Each will be data-driven, based on the planets geology, topographical selection, habitability, atmosphere, etc.

All of these noise functions have lots of parameters to tweak, and each needs a ‘valuable range’ defining as some of the valid values produce horrific visual output.

Then they need blending together in a controllable manner.

Then they need texturing.

Lots still to be done!



  • Facebook
  • Twitter
  • Myspace
  • Google Buzz
  • Reddit
  • Stumnleupon
  • Delicious
  • Digg
  • Technorati
Author: Mak View all posts by

Comments are closed.

Subscribe to The Dominium Observer Newsletter!