Scape: Terrain editing on the GPU [Src+Demo now available!]
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Scape: Terrain editing on the GPU [Src+Demo now available!]
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/
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.
- 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
WOW! This looks amazing!
Maybe someone could adapt it to work on Ogre terrain.
Maybe someone could adapt it to work on Ogre terrain.
-
- Halfling
- Posts: 74
- Joined: Wed Aug 10, 2011 2:11 pm
- x 11
Re: Scape: Terrain editing on the GPU w/ custom renderer
Amazing ! This deserves kudos.
- Jabberwocky
- 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
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?
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?
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU w/ custom renderer
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.
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.
- Nauk
- Gnoll
- Posts: 653
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 36
- Contact:
Re: Scape: Terrain editing on the GPU w/ custom renderer
Damn nice! congratulations
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
Support me on Patreon
-
- Bugbear
- Posts: 807
- Joined: Sun May 14, 2006 2:24 pm
- Location: Melbourne, Australia
Re: Scape: Terrain editing on the GPU w/ custom renderer
omg, that is amazing.
- 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
I'm really impressed
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.
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
-
- 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
Definately very cool
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU w/ custom renderer
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
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
- 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]
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.
-
- Halfling
- Posts: 74
- Joined: Wed Aug 10, 2011 2:11 pm
- x 11
Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]
Yay ! This is really cool :-) I'll read this soon.
- 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]
Thanks a million for sharing this information.
I'll be reading up on it as soon as I find some time
I'll be reading up on it as soon as I find some time
Developer @ MakeHuman.org
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]
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:
See http://www.decarpentier.nl/wp-content/u ... arison.jpg for a full-size version
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:
See http://www.decarpentier.nl/wp-content/u ... arison.jpg for a full-size version
- 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]
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:
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.
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:
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.
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU [Updated: 20 Dec]
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.
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.
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.
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.
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
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 ):
And the other is more desert-like:
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.
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 ):
And the other is more desert-like:
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.
My blog: http://www.decarpentier.nl
- 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]
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
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
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
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
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
My blog: http://www.decarpentier.nl
-
- Halfling
- Posts: 74
- Joined: Wed Aug 10, 2011 2:11 pm
- x 11
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
Hi Giliam,
Any news on Scape ? :-) I'd really love to have a peek at the sources !
Any news on Scape ? :-) I'd really love to have a peek at the sources !
- 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]
I think it's fully published. Have a look at the articles he referenced in the first post (there are three of them).Alexiss wrote:Any news on Scape ? I'd really love to have a peek at the sources !
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
-
- Halfling
- Posts: 74
- Joined: Wed Aug 10, 2011 2:11 pm
- x 11
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
Well, I was asking because he mentionned "once I release the code in a month or so" in his last post here.duststorm wrote:I think it's fully published. Have a look at the articles he referenced in the first post (there are three of them).Alexiss wrote:Any news on Scape ? I'd really love to have a peek at the sources !
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.
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
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
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
My blog: http://www.decarpentier.nl
-
- Halfling
- Posts: 74
- Joined: Wed Aug 10, 2011 2:11 pm
- x 11
Re: Scape: Terrain editing on the GPU [Updated: 7 Jan]
Thanks, that's great news.
Looking forward to your article !
Looking forward to your article !
-
- Gnoblar
- Posts: 14
- Joined: Wed Dec 14, 2011 12:24 am
- x 25
- Contact:
Re: Scape: Terrain editing on the GPU w/ custom renderer
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.
Here it is:
http://www.decarpentier.nl/scape-brush-pipeline
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.
Here it is:
http://www.decarpentier.nl/scape-brush-pipeline
My blog: http://www.decarpentier.nl