New Terrain Early Shots
-
- Gnoblar
- Posts: 3
- Joined: Sun Jun 28, 2009 10:04 am
Re: New Terrain Early Shots
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?
- 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
Did you see the Overhang Terrain Scene Manager?
-
- Gnoblar
- Posts: 3
- Joined: Sun Jun 28, 2009 10:04 am
Re: New Terrain Early Shots
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.
- Oceax
- Gnoblar
- Posts: 19
- Joined: Wed Sep 10, 2008 4:14 pm
Re: New Terrain Early Shots
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.
- Xplodwild
- Goblin
- Posts: 231
- Joined: Thu Feb 12, 2009 3:49 pm
- Location: France
- x 13
- Contact:
Re: New Terrain Early Shots
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
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
- Praetor
- 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
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
http://www.darkwindmedia.com
- xadhoom
- Minaton
- Posts: 973
- Joined: Fri Dec 28, 2007 4:35 pm
- Location: Germany
- x 1
Re: New Terrain Early Shots
@Oceax: Random errors might occure because of the buffer overflow error sinbad fixed today!
xad
xad
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: New Terrain Early Shots
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
Has anybody been able to write out to file? I have the following code from Sinbad's examples (thanks by the way!):
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:
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.
Code: Select all
Ogre::DataStreamPtr stream = Ogre::ResourceGroupManager::getSingleton().createResource("Terrain.terrain");
Ogre::StreamSerialiser ss(stream);
mTerrain->save(ss);
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);
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!
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
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:
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.
Code: Select all
Ogre::DataStreamPtr stream = Ogre::ResourceGroupManager::getSingleton().openResource("Terrain.terrain");
Ogre::StreamSerialiser ss(stream);
mTerrain->prepare(ss);
Getting close! If anybody has saved/loaded the new terrain from file, please post.
Creator of QuickGUI!
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
Thats how i export in ogitor:
but havent tried reloading actually
ismail,
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);
ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- sinbad
- 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
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...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
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.KungFooMasta wrote:Getting close! If anybody has saved/loaded the new terrain from file, please post.
-
- Gnoblar
- Posts: 20
- Joined: Thu Jun 07, 2007 12:44 pm
Re: New Terrain Early Shots
Nice!
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
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
- sinbad
- 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
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.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"?
- sinbad
- 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
Now with shadows:
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)
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)
- xadhoom
- Minaton
- Posts: 973
- Joined: Fri Dec 28, 2007 4:35 pm
- Location: Germany
- x 1
Re: New Terrain Early Shots
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
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
- sinbad
- 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
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.
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.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: New Terrain Early Shots
It looks beautifully lively.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
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.
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!
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
Lets say yout terrain should be between 300m and 900 m, below is the argumentsKungFooMasta 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.
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
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- sinbad
- 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
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.
- sinbad
- 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
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
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
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New Terrain Early Shots
Hehe, with all those shiny background tasks, what happens if you compile Ogre without thread support? Just curious
- sinbad
- 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
.. 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.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
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.CABAListic wrote:Hehe, with all those shiny background tasks, what happens if you compile Ogre without thread support? Just curious
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
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!