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

[Giliam]

I've not posted this on my blog yet as I want to extend the documentation a little bit more first, but I've just finished packaging and uploading my first Scape bin+src release.

Please note that, as I think I've said before, Scape is an older project already, and I don't intend to spend a lot of time on it anymore, as I'm too busy working on other projects. So feedback, questions and comments are very welcome, and I'll work on a short 'programmers guide' pretty soon, but please don't expect a lot of updates/upgrades for Scape any time soon (but if other people will like changing/extending/incorporating/maintaining the code, that's more than fine by me. )

The source release contains the build instructions to build/install Scape and it's prerequisites using Ogre 1.4.6 and Visual studio 2005 or 2008. Other versions are (currently) not supported. The binary release should (hopefully) run out of the box on most Windows machines that have DirectX9 installed (, although I haven't tested anything at all on 64-bit machines...). All source code is release under the Simplified BSD license (which is quite similar to Ogre's license).

Let me know what you think!

Scape 0.1.0 binary pack: http://www.decarpentier.nl/downloads/sc ... -win32.zip
Scape 0.1.0 source pack: http://www.decarpentier.nl/downloads/sc ... 1-vc90.zip



Giliam

[duststorm]

Wow, thank you for sharing all your hard work so generously.

How wonderful it would be if this got ported to latest ogre, and integrated with ogitor

[Nauk]

Thanks for sharing Giliam, great work and very interesting to look under the hood

[dark_sylinc]

Whooooooaaaaaaa!!!!!! I could kiss you!!

I've been wondering why there haven't been a project like this in the free field. And with source code!! I love you.

One question: When importing, I can't choose the scale of the terrain (width & depth + height). Is this not possible? Do I have to code that on my own? (don't worry about me for that, I can do it)
What is the current scale? 1 pixel = 1 Ogre unit? And for height? For example 16-bit images... 0 means -1000? what's the scale?

Thanks a lot!!!

Badass thesis is badass.

[Crystal Hammer]

Awesome ! Thanks for sharing.

Unfortunatelly for me exe crashes at start, looks liks some dll depencency problems. I have VS2008 installed so msvc*80.dll are present, and have DirectX SDK too, from Feb. 2010. I can't see any d3dx9_*.dll or D3DCompiler_*.dll in Dependency Walker, so I could see which version aren't they needed, or were they loaded dynamically in Ogre 1.4 ?
Anyone has an idea ?

If I had more time I would try compiling. I'm guessing there will be a lot of trouble to upgrade to Ogre 1.8, if there wasn't you had done some update to newer Ogre before, am I right ?

[jacmoe]

Really, really nice!

Does this project have a home on Bitbucket or other source code host ?
If not, it would probably be a good idea.

I'll try this on Linux.

[dark_sylinc]

Hi, I'm not the author but...

I have VS2008 installed so msvc*80.dll are present

I don't know which VC he used to build. If it was:
VC 2005, you're gonna need VC 2005 Redist
VC 2005 SP1, you're gonna need VC 2005 Redist SP1
VC 2008, you're gonna need VC 2008 Redist SP1
VC 2008 SP1, you're gonna need VC 2008 Redist SP1

and have DirectX SDK too, from Feb. 2010. I can't see any d3dx9_*.dll or D3DCompiler_*.dll in Dependency Walker

Normally you won't see them in Dependency Walker.
June 2010 was the last update. I recommend using the web installer because it will only download the necessary files you're missing (saves lot of time).
Or you can download the full installer
Also replacing Direct3D9_Rendersystem.dll with one you know that works (from Eihort) may do the trick. But it may end up being buggy.

Last but not least, if you're in Vista or 7, the Event Registry Log (Control Panel) may give you more detailed info about the crash.

[Giliam]

Thank you guys for all your kind words! I really appreciate it.

If I had more time I would try compiling. I'm guessing there will be a lot of trouble to upgrade to Ogre 1.8, if there wasn't you had done some update to newer Ogre before, am I right ?

This project has been collecting dust for four years (I won't go into it, but I've recently been given the rights to do whatever I want with it). When I coded it, Ogre 1.4.6 was the latest version. However, I did some hacking last year for a different project and was able to reuse the custom terrain render code with Ogre 1.7 without too much difficulty. The only really tricky hurdle was finding out that Ogre 1.7's interface for setting shader constants was changed semantically but still compiled fine without any warnings. But once that was out of the way, it was pretty easy. I have no idea if that would be true for 1.8 as well, and I never tried upgrading the (at least as complicated) terrain texture editing section of Scape. But anyway, the point here is that the lack of upgrades is not the result of porting difficulties already encountered.

One question: When importing, I can't choose the scale of the terrain (width & depth + height). Is this not possible? Do I have to code that on my own? (don't worry about me for that, I can do it)
What is the current scale? 1 pixel = 1 Ogre unit? And for height? For example 16-bit images... 0 means -1000? what's the scale?

That's right I'm afraid. However, if you're able to compile Scape yourself, you can easilty change the hardcoded values: Update 'getHeightfieldBufferSetManager()->create(_T("Project"), 4096, 4096, 0, 500, 512, 512);' in Engine/EngineCore/EngineCore.cpp to change the number of samples in both directions, and the min&max height value. So currently, a 4Kx4K map between heights 0 and 500 is always created (even though the actual heightfield values are always between the min and max of the internal heightfield representation format, so 0 and 65535, for example). And indeed, one pixel/sample is one unit. In theory you can change this by changing mWorldQuadSize in HeightfieldGeom.cpp, but currently the camera and brush radius rendering/editing don't compensate correctly for values other than 1.0, so I wouldn't recommend changing/exposing that right now. Also, as the editor is currently a standalone app, only the relative width/height ratio really matters anyway. Btw, a more hacky way to achieve the same without having to recompile would involve changing Bin\Materials\Programs\HeightfieldShaderCg.cg. For example, changing the line 'oPosition = mul(worldViewProj, localPosition);' to oPosition = mul(worldViewProj, localPosition * float4(1,10,1,1));' would scale the height's range by a factor of 10.

As a side note, it's also possible to change the internal representation of heightfield samples from 16-bit integers to 32-bit floats: Change the PF_SHORT_L in heightfieldBufferSet->create(_T("Render"), Ogre::PF_SHORT_L); in EngineCore.cpp to PF_FLOAT32_R, and select a different packer in the brush shaders: Open Bin\Materials\Programs\pack.cgh, change '#define PACK_IN 565' and '#define PACK_OUT 565' to '#define PACK_IN 32' and '#define PACK_OUT 32'. Lastly, change the '#else if ......' to '#elif .....' in the same cgh file to fix an issue that would otherwise still make it choose the wrong 'branch' (I'll fix that last part in the next release). Ideally, this would all be possible to do through the UI, but I had to finish my thesis at some point...

Unfortunatelly for me exe crashes at start, looks liks some dll depencency problems.

Thanks, dark_sylinc, for your excellent pointers. I hope they already fixed the problem. The Scape 0.1.0 binary was built using VC2005, so use this to install the studio redistib package. Scape comes with the original Direct3D9_Rendersystem.dll from the pre-built Eihort 1.4.6 SDK, and i think that was compiled against the DirectX 2004 SDK using dll version 33, or something. The DX9 webinstaller sounds like a good idea to check.

If Scape stil crashes, try to see if you can get some info from Bin/Scape.log (which is generated a.s.a.p. at startup) or run DebugView to see the log in real-time.

Again, thanks for all the feedback!

[dark_sylinc]

That's music for my ears! Thanks for the guidance.

Indeed, the only important is the Height vs Width (Depth) ratio. I need to check the code because the 4096 resolution limitation is problematic.

Thanks again!

[Giliam]

How wonderful it would be if this got ported to latest ogre, and integrated with ogitor

I have no plans to integrate Scape into Ogitor, as my time on Scape is already limited and I know nothing about the Ogitor or Ogre::Terrain. But it should be doable, as design-wise Scapes's terrain renderer (in the Engine/HeightfieldGeom folder) is largely decoupled from the terrain editor. The first thing that would have to be created is a way to sharing the internal buffer, requiring Ogitor to use the HeightfieldBuffer, Scape to use Ogitor's version of it, or (perhaps preferably) creating a new version of HeightfieldBuffer that acts like an efficient adapter to Ogitor/Terrain's representation. But, again, I've no experience with Ogitor/Terrain so I might be completely wrong here, and I don't plan to do this myself. But if someone else would want to give it a go, I might be able to give a few more pointers.

On the matter of porting Scape to use the latest version of Ogre, I've tried it today and it worked like a charm after changing only a dozen project settings and c++/cg code lines or so. The v0.1.1 release will therefore require Ogre 1.8 and at least VS2008 instead of 1.46 with VS2005. That is, unless most people here would prefer a version older than 1.8 (Ogre 1.7 for example?) as a Scape dependency. Any preferences?

(Perhaps, ideally I would maintain support for multiple versions, but as the version differences also include changing project settings, that would only be doable with minimal overhead when using build scripts instead of visual studio projects directly, and I've no plans to start doing that).

[Arkiruthis]

People like you are the reason I got into programming. Thank you so much for your generosity.

[duststorm]

The v0.1.1 release will therefore require Ogre 1.8 and at least VS2008 instead of 1.46 with VS2005. That is, unless most people here would prefer a version older than 1.8 (Ogre 1.7 for example?) as a Scape dependency. Any preferences?

I guess that is a very defendable choice. Given the current state of 1.8 and the fact that integrating such a feature in a project will probably happen in a phase where there is still enough room for change (eg. updating Ogre version would still be possible).
Maintaining multiple versions is a work intensive task.
But who knows, maybe a version for 1.8 will still be compatible with 1.7

[jacmoe]

I have no plans to integrate Scape into Ogitor, as my time on Scape is already limited and I know nothing about the Ogitor or Ogre::Terrain. But it should be doable, as design-wise Scapes's terrain renderer (in the Engine/HeightfieldGeom folder) is largely decoupled from the terrain editor. The first thing that would have to be created is a way to sharing the internal buffer, requiring Ogitor to use the HeightfieldBuffer, Scape to use Ogitor's version of it, or (perhaps preferably) creating a new version of HeightfieldBuffer that acts like an efficient adapter to Ogitor/Terrain's representation. But, again, I've no experience with Ogitor/Terrain so I might be completely wrong here, and I don't plan to do this myself. But if someone else would want to give it a go, I might be able to give a few more pointers.

Don't worry about that. The Ogitor team will take on that challenge eventually.

On the matter of porting Scape to use the latest version of Ogre, I've tried it today and it worked like a charm after changing only a dozen project settings and c++/cg code lines or so. The v0.1.1 release will therefore require Ogre 1.8 and at least VS2008 instead of 1.46 with VS2005. That is, unless most people here would prefer a version older than 1.8 (Ogre 1.7 for example?) as a Scape dependency. Any preferences?

It should of course depend on 1.8 as it's the current stable.

(Perhaps, ideally I would maintain support for multiple versions, but as the version differences also include changing project settings, that would only be doable with minimal overhead when using build scripts instead of visual studio projects directly, and I've no plans to start doing that).

CMake FTW.
Put it in a public repository and let people contribute if you want.

[drwbns]

I missed the post of you sharing the code. kudos!

[Xplodwild]

Thanks for the sources, it's really awesome to use.

I'm also planning to adapt your code to Ogre::Terrain so I can use it in my editor. I'll follow progress done on Ogitor (I hope there will be some announcement here if they got it working), and I'll report back my progress once I get to it if I'm done with it earlier .

[Giliam]

Version 0.1.1 has just been released!

I've added a central page on my website (http://www.decarpentier.nl/scape) to get the latest src & bin version from, together with all other Scape-related downloads.

Also, I've also pushed the code (together with a tiny wiki) to a bitbucket Mercurial repository for anyone to see and modify. (if anyone notices something weird about the settings, please inform me, as I'm new to Mercurial). See my website for details.

Other changes:

- Scape 0.1.1 is now built for/with Ogre 1.8 and is meant to be compiled with VC 2008.
- The user guide has extended a bit
- A programmer's guide was added.
- You're now able to change the number of samples in both directions, as well as change the height range from by modifying the settings file '/Bin/Settings/Startup.conf', instead of having to recompile.

[duststorm]

Version 0.1.1 has just been released!

Thanks a lot! Glad to see you are still actively maintaining it.
Hats off for the fact that you added documentation too.

[jacmoe]

Did anyone build this with Ogre 1.9 ?

[jacmoe]

I can compile 80% of the Engine, and then it fails in HeightfieldOperationGPUPage.cpp :

Code: Select all

void HeightfieldOperationGPUPage::tickActive()
{
//	HeightfieldBufferPage* page = mHeightfieldBuffer->getPage(mPageCoords.first, mPageCoords.second, HeightfieldBuffer::PAGEACCESSMODE_READWRITE);
	HeightfieldBufferPage* inPage = mOperation->getInOutHeightfieldBuffer()->getPage(mPageCoords.first, mPageCoords.second, HeightfieldBuffer::PAGEACCESSMODE_READONLY);

	if (!inPage) return;

	Ogre::Rect pageRect = inPage->getAbsoluteRect();

	if (mQuadPtr.isNull())
	{
		mQuadPtr = GPU2DOperationQuadBrushPtr(new GPU2DOperationQuadBrush());

My compiler complains about there being no default constructor available for GPU2DOperationQuadBrush.

[frostbyte]

crossing fingers...

[jacmoe]

I am moving on to the Editor project now.

I still haven't fixed the HeightfieldOperationGPUPage::tickActive issue.
I simply commented it out, so there will be a lot of dragons ...
A good start, though.

[N0vember]

Woooooow this is friggin great !
Just discovered it now and looked at the first video. Amazing.

I created a really small fractal generator that generates 2D images, now I want to try to plug it into this.
It is so fast that there may be a way to modify the parameters of the fractal and see the landscape evolve in real time.

Inspiration !!
I'll dive in the technical papers when I have time. Thanks for resurfacing this

[jacmoe]

If you manage to fix the HeightfieldOperationGPUPage issue..

My Scape fork is here: https://bitbucket.org/jacmoe/scape

[frostbyte]

naggy compiler...always complaining...
looking at the code he didnt explicitly inherit the constructor( on GPU2DOperationQuadBrush ) - weird that msvc let him do that...i know its supported only with g++/clang...any way better add this inheretance - before the dragon wakes up...
edit: just found constructor inheritance was added to msvc2013...maybe he's from the future?

also weird that such a fine project got so much complements but i don't think lots of people used it...
i realy liked the speed of large-area brushes...
maybe some insight of how it compares( benefits/downfaults ) to ogre paged terrain( beside the editing speed ) ?

[jacmoe]

It is odd.
My fork is the only one.
Better late than never, right?

I have been out of the loop for a while, but this is a good time to resurrect it, because with Ogitor we've grown seriously dissatisfied with the Ogre terrain component.
The material generator and awkward access to the terrain data makes it clunky and unresponsive.

This terrain engine, however..