New Terrain Early Shots

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!
Post Reply
kinjalkishor
Gnoblar
Posts: 3
Joined: Sun Jun 28, 2009 10:04 am

Re: New Terrain Early Shots

Post by kinjalkishor »

I am trying Caves and Overhangs in my engines, I am trying Octtrees for that. This makes possible for making height map type operation on walls and ceilings. Is this good enough solution?
User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
x 10
Contact:

Re: New Terrain Early Shots

Post by DanielSefton »

kinjalkishor
Gnoblar
Posts: 3
Joined: Sun Jun 28, 2009 10:04 am

Re: New Terrain Early Shots

Post by kinjalkishor »

Thanks, Daniel, The Discussions on that page are really very helpful. I am not using metaballs, but cubes/voxels basically. But there is a lot of info there and ideas. 3D Textures/Voxels is what I am really after.
User avatar
Oceax
Gnoblar
Posts: 19
Joined: Wed Sep 10, 2008 4:14 pm

Re: New Terrain Early Shots

Post by Oceax »

I implemented the new terrain in my editor and i use a decal cursor on the terrain material. Now i have a problem with the terrain material not being affected with light(only directional caelum sun in scene). Sometimes its working and sometimes not working when i start the editor. What can be the reason for this? Its very random ... sometimes i can launch the application three times in a row without any problem and then the 4th time i have no light on the terrain and the 5th time it works again :?
Last edited by Oceax on Tue Jul 07, 2009 6:55 pm, edited 1 time in total.
User avatar
Xplodwild
Goblin
Posts: 231
Joined: Thu Feb 12, 2009 3:49 pm
Location: France
x 13
Contact:

Re: New Terrain Early Shots

Post by Xplodwild »

Does the terrain is already editable ? Or this function isn't ready yet?
Also, will there be "brushes" like in ETM ? And will we be able to edit vertex height manually ? It would be really cool to do infinite seamless terrains :)
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: New Terrain Early Shots

Post by Praetor »

Height is available to be edited in "raw" form. It's the lowest level, but the most powerful. There are no brush systems in place now, but you could fairly easily create a brush-based system on top of what is available with the raw height data access and the dirtyRect functions.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany
x 1

Re: New Terrain Early Shots

Post by xadhoom »

@Oceax: Random errors might occure because of the buffer overflow error sinbad fixed today!

xad
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: New Terrain Early Shots

Post by jacmoe »

Keep in mind that this really is work in progress.. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

Has anybody been able to write out to file? I have the following code from Sinbad's examples (thanks by the way!):

Code: Select all

Ogre::DataStreamPtr stream = Ogre::ResourceGroupManager::getSingleton().createResource("Terrain.terrain");
Ogre::StreamSerialiser ss(stream);
mTerrain->save(ss);
The file "Terrain.terrain" is created, although its 0 bytes, nothing in it. The terrain is definately showing up, and I'm definately calling this code after the terrain is created. For example, you could just stick this code in the PlayPen, in the Terrain test function, at the end, and its the same.

The other code I have tried is this:

Code: Select all

FILE* fp = fopen("Terrain.terrain", "wb");
Ogre::DataStreamPtr stream(OGRE_NEW FileHandleDataStream(fp));
//Ogre::DataStreamPtr stream = Ogre::ResourceGroupManager::getSingleton().createResource("Terrain.terrain");
Ogre::StreamSerialiser ss(stream);
mTerrain->save(ss);
fclose(fp);
Which results in the exception "Invalid operation, file is not writeable".

I'm on win7, and I thought this might be somehow related to needing admin permissions, but running the exe as admin causes same behavior.
Creator of QuickGUI!
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

Hm, after some more investigation it seems the first code I posted works, but the second doesn't. (using ResourceGroupManager method worked, file was in another location, and is ~6mb) But now, I'm trying to verify that the Terrain.terrain file was created correctly, I've commented out my terrain creation and instead added:

Code: Select all

Ogre::DataStreamPtr stream = Ogre::ResourceGroupManager::getSingleton().openResource("Terrain.terrain");
Ogre::StreamSerialiser ss(stream);
mTerrain->prepare(ss);
But an exception occurs: "Invalid operation, end of file on stream".

Getting close! If anybody has saved/loaded the new terrain from file, please post. :)
Creator of QuickGUI!
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

Thats how i export in ogitor:

Code: Select all

std::fstream fstr(filename.c_str(), std::ios::out|std::ios::binary);
Ogre::DataStreamPtr stream = Ogre::DataStreamPtr(OGRE_NEW Ogre::FileStreamDataStream(&fstr, false));
Ogre::StreamSerialiser ss(stream);
m_Handle->save(ss);
but havent tried reloading actually :)

ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Oceax wrote:I implemented the new terrain in my editor and i use a decal cursor on the terrain material. Now i have a problem with the terrain material not being affected with light(only directional caelum sun in scene). Sometimes its working and sometimes not working when i start the editor. What can be the reason for this? Its very random ... sometimes i can launch the application three times in a row without any problem and then the 4th time i have no light on the terrain and the 5th time it works again :?
The terrain normals are calculated in a background thread (assuming you have Boost available), therefore there may be a slight delay in the lighting appearing (this is deliberate, it shows the threading is working!). I've never had it take more than about a second on my machine though, although that will get longer as I add shadowing. When the data is loaded from a terrain file rather than built from an image or raw data, the data can be loaded rather than calculated for a faster initial display. If it never appears, check the log for errors, maybe the background thread crashed out or something. I'm fixing things all the time...
KungFooMasta wrote:Getting close! If anybody has saved/loaded the new terrain from file, please post. :)
This may not work flawlessly yet, I've been adding new things without re-testing the save/reload sequence because I've been concentrating on fixing issues with the real-time editing recently. I'll get to it.
Enrico
Gnoblar
Posts: 20
Joined: Thu Jun 07, 2007 12:44 pm

Re: New Terrain Early Shots

Post by Enrico »

Nice! :shock:

How do you plan to add support for caves or dungeons into the terrain? WIll it be possible to convert the heightmap based terrain into a "real mesh"?

Thanks,
Enrico
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Enrico wrote:How do you plan to add support for caves or dungeons into the terrain? WIll it be possible to convert the heightmap based terrain into a "real mesh"?
There are a few ways to deal with this, but converting the terrain into a mesh isn't one I would use. You can use portals, or you can 'carve' areas out of the terrain by performing extra renders using geometry which represents the tunnels / caves, either pre-setting the depth so the terrain doesn't render over it, or clearing the depth buffer where they are rendered, so you can render the internal geometry afterwards.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Now with shadows:
newterrain_9.jpg
newterrain_9.jpg (110.5 KiB) Viewed 5000 times
newterrain_10.jpg
newterrain_10.jpg (99.64 KiB) Viewed 5000 times
These are lightmaps calculated on the CPU in a background thread. They're not completely flawless yet, and can use some post-processing / filtering, but they help with the realism.
The nice thing is that you can edit the terrain in real-time, and provided you don't hit a massive area at once the shadows keep up with the edits quite interactively. If you do edit large areas at once there's a slight delay as the background thread recalculates the lighting.

Adding these does make the appearance of lighting on the terrain a bit slower to kick in if you import from an image (the default resolution is 1024x1024). I'm considering separating the background process into separate tasks (delta / LOD recalculation, normals and shadows) so that the faster ones can complete first, but since this only affects initial import I will probably do this later (lightmaps etc are all stored in the native terrain file format so loading from this at runtime will have no lighting startup lag)
User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany
x 1

Re: New Terrain Early Shots

Post by xadhoom »

Wow, looks very nice. Reminds me a bit of the Crysis approach of calculating light changes in the background to cope with day-night cycles.
How is the light direction/colour etc determined? Do you set a reference light or is it a more generic approach (e.g. to be able to use spherical harmonics or AO results)?

BTW: I encounter serious texture issues with the brown ground texture. It seems to float heavily depending on the view angle. Is this a parallax issue?

xad
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

There's no colour right now, just intensity - that way it's 3 times smaller (PF_L8) and you can always recolour it in the shader based on primary light colour. It's currently set by setting a light direction separately in TerrainGlobalOptions - tracking a Light had too many potential issues with dealing with lifecycles and this can only handle one directional light anyway.

The texture issues are probably parallax artefacts yes - I don't really see them unless I get very close to the terrain. You can always change the scale / bias values to change this.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: New Terrain Early Shots

Post by jacmoe »

It looks beautifully lively. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

Looks good!

I have a feature request or need more understanding related to the inputbias property. It seems the only way to control the height of a terrain as it looks in the 3d world is through the input bias. Is it possible to instead have a variable where users can set the max height difference they want? For example say I create my heightmap in L3DT and I know the terrain is X units from lowest to highest point. How can I translate this information into Ogre? Seems I would have to constantly adjust the inputBias until the terrain looked similar to that shown in the L3DT editor. Maybe I'm going about things the wrong way? I just see a "total 3d height variation" property more useful than an "input bias which stretches the height data" property.
Creator of QuickGUI!
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

KungFooMasta wrote:Looks good!

I have a feature request or need more understanding related to the inputbias property. It seems the only way to control the height of a terrain as it looks in the 3d world is through the input bias. Is it possible to instead have a variable where users can set the max height difference they want? For example say I create my heightmap in L3DT and I know the terrain is X units from lowest to highest point. How can I translate this information into Ogre? Seems I would have to constantly adjust the inputBias until the terrain looked similar to that shown in the L3DT editor. Maybe I'm going about things the wrong way? I just see a "total 3d height variation" property more useful than an "input bias which stretches the height data" property.
Lets say yout terrain should be between 300m and 900 m, below is the arguments

InputBias = 300 (minimum height)
InputScale = 600 (max - min)

//Depending on the formula FinalHeight = InputBias + (InputScale * heightmapvalue)
//Heightmapvalue is always 0.0f-1.0f range when read from an image)

ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

And remember, the input bias / scale are only relevant for image inputs, and are only there to resolve the fact that images typically have a limited precision. You can totally bypass the need for bias/scale and just input an array of raw floating point heights instead if you want. Internally, that's how they're stored anyway - there is no fixed min/max range, even if you import using a bias/scale you can edit the terrain to be well outside that afterwards.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Just a heads-up; to fix a potential race condition, when a Terrain object is destroyed, and when saving, it waits for any of its own deferred processes to finish, beacuse they will be accessing / updating data on the terrain. If you're running in debug mode with large terrains and lightmapped shadows, this can take a little while so if you find a delay when shutting down before you've seen lighting appear on your newly imported terrain, this is why.

I plan to improve the responsiveness later by splitting up the deferred processes, so they will be more easily interrupted and the cheaper aspects can be updated faster and later more expensive processes skipped if there's a reason to do so. But for now, just be patient with those background threads :)
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: New Terrain Early Shots

Post by CABAListic »

Hehe, with all those shiny background tasks, what happens if you compile Ogre without thread support? Just curious :)
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

sinbad wrote:I plan to improve the responsiveness later by splitting up the deferred processes, so they will be more easily interrupted and the cheaper aspects can be updated faster and later more expensive processes skipped if there's a reason to do so. But for now, just be patient with those background threads :)
.. and now I've done this. You'll get much faster initial lighting on the terrain now since normals are calculated first (still in the background) and synchronised with the main thread before the lightmap starts calculating separately in the background. The lightmap now updates slightly slower than it did before under real-time update scenarios, but other aspects (LOD recalculation and normals) update faster. Overall it feels more responsive I think.
CABAListic wrote:Hehe, with all those shiny background tasks, what happens if you compile Ogre without thread support? Just curious
It does everything synchronously instead, which means you get to wait a long time at initial import time before getting anything on screen, and the frame rate dives when you edit in real-time until everything is up to date :) Really the new terrain is designed very much with threading in mind; which is why I changed Cthugha to default to OGRE_THREAD_MODE 2 when Boost is detected.
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

I guess I meant input scale not bias. So basically if I want a terrain that ranged from min y = -500 to max y = 500, my input scale should be 1000. I guess I was thinking image input values would be [0-255] instead of [0.0-1.0]. So input data from an image is converted to 3d world heights (using input scale/bias), whereas if we supply an array with data to create the terrain, the array needs to contain 3d world heights already (no input scale/bias used). Is this right?
Creator of QuickGUI!
Post Reply