Scape: Terrain editing on the GPU [Src+Demo now available!]

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Scape: Terrain editing on the GPU [Src+Demo now available!]

Post by Giliam »

It's been a few years already since I worked on this, but here it is:


It uses Ogre as a platform-independent graphics engine, on which I wrote my own paging terrain renderer system,
as the 'standard' one (PLSM 2, I think) didn't suit my specific needs.

The terrain editor allows the user to apply (pressure sensitive) brushes of procedural algorithms.
The actual operations that follow from these brush strokes are also fed into Ogre as quad render calls using custom pixel shaders,
updating as many ping-ponged page render targets as needed.

This project was part of my master thesis in 2008 at W!Games. But only recently I got permission to fully share it.
I just finished an article explaining the rendering part of the project:
http://www.decarpentier.nl/scape-render

The thesis can also be downloaded from that page for additional details.
Soon, I hope to find the time to write a follow-up article focusing on the procedural algorithms, the brush pipeline, and the GPU brush shaders.
And after that, I intend to share the whole code base, if someone is interested (It's left in an unfinished state, and comes without any guarantees).

[Edit 7 Jan]:
By now, the next two articles on Scape's internal details are online as well, covering most of its noise-summing procedural algorithms.
http://www.decarpentier.nl/scape-procedural-basics: Covers a new efficient implementation of 2D Perlin noise, together with a number of common turbulence functions.
http://www.decarpentier.nl/scape-procedural-extensions: Discusses two novel procedural algorithms that generate old and eroded(-looking) terrain.

[Edit 30 Jun]:
Last month, I added an article about Scape's CPU & GPU brush pipeline on my blog at http://www.decarpentier.nl/scape-brush-pipeline.
Furthermore, I open-sourced the project and updated its prerequisites (now depends on Ogre version 1.8.0). See http://www.decarpentier.nl/scape for an overview of the project and all the links to the source code (package or Mercurial repository), the articles, the research and binary (which includes the user guide and programmer's documentation as well).

Let me know what you think.

Kind regards,
Giliam de Carpentier
http://www.decarpentier.nl/
Last edited by Giliam on Sat Jun 30, 2012 10:08 am, edited 5 times in total.
User avatar
tod
Troll
Posts: 1394
Joined: Wed Aug 02, 2006 9:41 am
Location: Bucharest
x 94
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by tod »

WOW! :shock: :shock: :shock: This looks amazing!
Maybe someone could adapt it to work on Ogre terrain.
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by Alexiss »

Amazing ! This deserves kudos.
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by Jabberwocky »

Very nice.
The terrain looks extremely detailed. How many verticies is the map in the video? Are you generating normals somehow to add to the detail of the terrain?
Image
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by Giliam »

I believe this was a 4K x 4K map.

The squares you see at 1:04 in the clip are the actual vertex quads (the grid is rendered as a toggleable 'procedural effect' in the pixel shader, as is the red brush).
So, the brush stroke you see at 1:10 in the movie updates millions of samples a number of times (as a stroke is implemented as a series of discrete 'brush instances').

The normals are solely based on vertex information, and calculated on the fly when 'page height textures' are converted into LODed 'tile vertex buffers' on the CPU.
(The page heighttextures need to be downloaded to main memory anyway for undo support purposes, amonst other reasons).
This process happens when a terrain page is edited, but also when a tile changes its LOD. (In Scape, pages and tiles are two different concepts and are even differently sized).
This is all done asynchronously, amortizing costs over multiple frames when necessary.
kneeride
Bugbear
Posts: 807
Joined: Sun May 14, 2006 2:24 pm
Location: Melbourne, Australia

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by kneeride »

omg, that is amazing.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by duststorm »

I'm really impressed :o
Also really curious to what effects you used to shape that terrain. They seem to be very effective to quickly create convincing terrain features.
So I understand those procedural effects are implemented as shader programmes?
This part I'm not fully sure about (didn't have the time yet to read everything, sorry): do the brush effects get applied on a heightmap image or are they applied on the terrain vertices and is a heightmap generated afterwards?
I applaud you for wanting to share this with the Ogre community.
Developer @ MakeHuman.org
drwbns
Orc Shaman
Posts: 788
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California
x 24

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by drwbns »

Definately very cool :)
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by Giliam »

First of all, thanks for the compliments and kudos.

I just finished a new article on Scape, explaining some the algorithms used to edit heightfields on the GPU in Scape.
I also included an FX Composer testbed project, so you can play around with the procedural pixel shaders.

http://www.decarpentier.nl/scape-procedural-basics

Hope you people find this useful.

Kind regards,
Giliam
User avatar
Crystal Hammer
Gnome
Posts: 317
Joined: Sat Jun 23, 2007 5:16 pm
x 77
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by Crystal Hammer »

Wow, this is awesome ! This leaves CPU editing way behind (e.g. 2k x 2k with 30fps (20 fps or less for bigger size brushes). And the directional brushes are great.
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by Alexiss »

Yay ! This is really cool :-) I'll read this soon.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by duststorm »

Thanks a million for sharing this information.
I'll be reading up on it as soon as I find some time :)
Developer @ MakeHuman.org
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by Giliam »

Someone asked me if I had a less synthetic example of the multiprojection advantages I mentioned in my first article.
In case someone else was wondering the same thing, here's a comparison between a Y texture projection and a blended XYZ projection for a pretty extreme heightfield in Scape:

Image

See http://www.decarpentier.nl/wp-content/u ... arison.jpg for a full-size version
User avatar
sleo
Gremlin
Posts: 171
Joined: Sun Jun 05, 2011 6:49 am
Location: Vodka Federation
x 18

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by sleo »

Very good ideas and their realization. Thank you for sharing knowledge and writing digestible articles.

I liked your idea to use involution of surface normal for blending XY,YZ,XZ-planes projections for texture sampling. It is very fast. But there is also more popular technique called triplanar projection mapping or triplanar texturing, which uses some constant to tighten up the blending zone. I think this is especially important for blending normalmaps of different materials (dirt, grass, rock, snow, etc.). But maybe because you use noise-based dithering it is not so much important. Here is screenshots there I compare your method vs triplanar method:

Image

Image

Without tighting a 45 degree slope will use 0.5 + 0.5 blending which for example seen on mountain slope on the right and overall texture mapping looks smeared.
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]

Post by Giliam »

Hi sleo,

Thanks for the time you took to compare the techniques! It's nice to hear this kind of stuff is now called 'popular', unlike the situation in 2007 (when I wrote this shader) when this was all pretty new and undocumented. I do like to point out that both 'my' projection and the 'popular' triplanar projection were (originally) designed to project ONE texture on any surface. It's not designed or tweaked to blend different materials, like snow on rock. I don't think that will ever work properly under all circumstances. Let me clarify: You ended your comment with a case of a 0.5 + 0.5 blend, but that will happen with ANY triple projection technique for a fixed normal of (for example) [0.71, 0.71, 0], including mine and the technique you mentioned. So, any plane sloped at 45 degrees would mix 50% rock with 50% snow, resulting in a quite ugly effect. To mix materials, I use a mix of height and slope 'smoothstep-like' ranges, while those ranges can be varied from one place to another using a (random noise) texture. The mix of those three inputs works in many more cases than simply basing it only on slope. (And the look of the ranged clamp in the triplanar projection is a special case that is also possible to recreate in this more general solution). But for optmization's sake, I can understand why you would mix these different concepts as a way to decrease the number of texture reads in the pixel shader. But in that case, I would still recommend a more customizable solution, instead of using those magic numbers in mentioned in GPU Gems 3 chapter 1 (assuming you used that):

float3 blend_weights = abs( N_orig.xyz ); // Tighten up the blending zone:
blend_weights = (blend_weights - 0.2) * 7;
blend_weights = max(blend_weights, 0); // Force weights to sum to 1.0 (very important!)
blend_weights /= (blend_weights.x + blend_weights.y + blend_weights.z ).xxx;

Speaking of which, when I looked at this GPU Gems code, I noticed this multiplication by 7. This is completely useless. You'll get the same result without this multiplication, because the end result is divided by the same multiplication factor in the last line.. So, just leave that out (if you didn't already notice that yourself).

But back to the topic of comparing the two techniques. Which one is really 'better' in a game is probably too subjective and context-sensitive to say. A too narrow transition, and you'll get something resembling seams. To wide, and there's too much smearing. But for cracked rock surfaces, it's probably better to smear instead of seeing a seam, while overly-blended snow just makes no sense, making a more seamy but narrower transition preferable. But the problem seemed interestingly enough this morning to do some quantitive testing. :-)

Image

The popular triplanar (from the GPU Gems 3 book) is denoted as 'max(0, Abs(Normal) - 0.2)'. The Abs(Normal) is basically the triplanar technique without the minus 0.2, or equivalently, the square root of my technique. The Normal^2 (or, in code: Normal*Normal) is my technique. The weights in all three cases normalized afterwards (if necessary), so the sum of the weights is always 1.0.

As you can see, the 'popular' technique smears the least in the nearly-on-axis directions (up to +- 14 degrees deviation or so), while my technique smears least in the nearly-completely-off-axis angles. Interestingly enough, the on-average smear, or blended slope (i.e. (weightX/cos(degrees)) + (weightY/cos(90-degrees))) of the texture projection is even slightly LESS with my technique (1.2729 versus the popular's value of 1.2749).

So, in this light, it makes sense that the transitional surface area in your particular scene is 'smaller' when using the popular approach that it is with my technique. But if the terrain would be more 'hilly' instead of more horizontally/verically-aligned (and, consequently, the area of the terrain's surface closer to 45degrees would be relatively larger), the opposite is likely to become true.
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Giliam »

I just added a third post on Scape to my blog.
This time, it covers two novel and more advanced procedural algorithms, again including shader snippets, a lot of images, and an FX Composer project to experiment with.

One generates mountainous terrain (still using the classic 'Ogre' skybox, as you can see :-) ):
Image

And the other is more desert-like:
Image

The algorithms are still based on mixing Perlin noise functions.
But they apply them in a more complex way, mimicking stuff you would expect from some types of erosion simulations.

The new article:
http://www.decarpentier.nl/scape-procedural-extensions

Hope you like it.
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by DavlexDesign »

G'day Giliam,

Very impressive understanding of fractal mathematics, I've been mucking around with my own versions of fractals for a while now, but these make mine look quite plain.

would it be OK with you if I try and implement some of this stuff in my setup http://www.ogre3d.org/forums/viewtopic. ... &start=500 ?

Alex
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Giliam »

Thanks!
And that project is also pretty awesome!

Scape has been collecting dust for more than three years now (due to legal rights stuff), but now that I've got permission to share it, I hope that (parts of) it can be (re)used in one form or another, (and perhaps find someone who might be interested enough to start extending it as-is, once I release the code in a month or so, as I've got too many other project I'm currently working on already :? ).

So if you think you can use anything for your own project, by all means! (but a little credit would be appreciated, of course. ;-) )
Good luck!

Giliam
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Alexiss »

Hi Giliam,

Any news on Scape ? :-) I'd really love to have a peek at the sources !
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by duststorm »

Alexiss wrote:Any news on Scape ? :-) I'd really love to have a peek at the sources !
I think it's fully published. Have a look at the articles he referenced in the first post (there are three of them).
You can download the shader sources there. That's really where all the magic happens.
As for terrain and editing, you might be able to implement them with Ogre::Terrain and use ogitor, for example, as the editor.
Developer @ MakeHuman.org
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Alexiss »

duststorm wrote:
Alexiss wrote:Any news on Scape ? :-) I'd really love to have a peek at the sources !
I think it's fully published. Have a look at the articles he referenced in the first post (there are three of them).
You can download the shader sources there. That's really where all the magic happens.
As for terrain and editing, you might be able to implement them with Ogre::Terrain and use ogitor, for example, as the editor.
Well, I was asking because he mentionned "once I release the code in a month or so" in his last post here.
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Giliam »

Hi guys,

My apologies for not responding.
I had to move quite unexpectedly a month ago and I've been having trouble getting internet ever since.
Hopefully in 6 weeks or so, I'll have had the time to settle, publish the final article online, and prep Scape's source code for anyone to use.
The topic for the final article on Scape is the cpu & gpu brush pipeline.
Again, sorry for the delay.
Regards,
Giliam
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]

Post by Alexiss »

Thanks, that's great news.
Looking forward to your article !
Giliam
Gnoblar
Posts: 14
Joined: Wed Dec 14, 2011 12:24 am
x 25
Contact:

Re: Scape: Terrain editing on the GPU w/ custom renderer

Post by Giliam »

I finally got around to working on my blog again, and uploaded another article on Scape.
This time's it's about Scape's editing pipeline, using input from the user to drive the brush-based system, splitting the operations into smaller and smaller pieces of information, before finally being executed as either CPU loops or GPU render calls to update the terrain. It also covers the brush type presented at the end of the movie clip, where the procedural noise is influenced by the brush stroke's direction.

Image

Here it is:
http://www.decarpentier.nl/scape-brush-pipeline
Post Reply