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!
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: New Terrain Early Shots

Post by sinbad » Thu Oct 08, 2009 5:21 pm

Tsk, you and your flags. ;)

Another fair request, I'll see about adding them. I've been completely buried catching up with other projects but once I get back from Qt DevDays next week I'll have more time for the terrain again. I want to use it to make a new OgreSpeedTree demo after all :)
0 x

Tiser
Gnoblar
Posts: 7
Joined: Thu Sep 10, 2009 4:08 am

Re: New Terrain Early Shots

Post by Tiser » Sun Oct 11, 2009 4:25 pm

If I add, say, 20 texture layers to a terrain with this new terrain engine, is the engine always computing the 20 texture layers? Or is it divided into chunks and only the textures used in every chunk are rendered?
0 x

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

Re: New Terrain Early Shots

Post by sinbad » Sun Oct 11, 2009 4:44 pm

You can't add 20 layers to a single Terrain instance, the maximum is currently 5 with the default normal/parallax/specular/colourmap mapping enabled. Different material generators (they're pluggable) might have different limits. There is no auto-splitting if you try to exceed this, you're simply limited to it within that Terrain instance and must create separate Terrain instances manually if you want more variation (although 5 layers is plenty for most modern commercial games when combined with other detailing - people who think they need more should play some terrain-heavy games and look for themselves; nothing uses anywhere near 20 layers). It's up to the content creator to split appropriately, break things up using colour maps, detail objects etc. Any automatic approach would just result in inefficient terrain anyway.
0 x

Tiser
Gnoblar
Posts: 7
Joined: Thu Sep 10, 2009 4:08 am

Re: New Terrain Early Shots

Post by Tiser » Sun Oct 11, 2009 6:10 pm

Ok, I guess I can get the same effect here using small terrains as chunks, so problem solved.

Random question: is it possible to have one of the layers be a multipurpose layer where different textures are used for blending at different parts of the terrain?

Secondly, I have this problem with decals, I thought I'd report it. Disregard the fact that the terrain is black, I just don't have textures atm, but the problem happens with textures loaded.

img444.imageshack.us/img444/2079/decalproblem.png

The problem is those fragments that appear over the decal. I'm using the decal technique explained in the wiki, but if that isn't enough I can post the code.

Also, what's the recommended approach for multiple decals? Since with what I got now, every decal adds a new pass and that seems too costly.
0 x

db123
Halfling
Posts: 78
Joined: Wed May 21, 2008 5:55 am

Re: New Terrain Early Shots

Post by db123 » Tue Oct 13, 2009 2:56 pm

nice.I like it.. :D :D
0 x

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta » Mon Oct 19, 2009 5:04 am

Sorry to keep requesting stuff; I figure now is the best time to ask since its still under active development. :)

I'd like to request a get/setVisible API for the Terrain.
0 x
Creator of QuickGUI!

User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy

Re: New Terrain Early Shots

Post by boyamer » Mon Oct 19, 2009 8:06 am

I want to know if its possible to access terrain material directly from external,and if not,i would like to request this! Need this for integration with Hydrax and its depth technique!

Thanks
0 x

User avatar
Xplodwild
Goblin
Posts: 231
Joined: Thu Feb 12, 2009 3:49 pm
Location: France
Contact:

Re: New Terrain Early Shots

Post by Xplodwild » Mon Oct 19, 2009 5:48 pm

boyamer wrote:I want to know if its possible to access terrain material directly from external,and if not,i would like to request this! Need this for integration with Hydrax and its depth technique!

Thanks

Code: Select all

Ogre::Technique *t = m_Handle->getMaterial()->getBestTechnique();
		Ogre::Pass* p = t->createPass();
I personnally do it this way. One limitation is that material is internally recreated when you modify texture list, so any changes are "cancelled" when you change splatting textures.
0 x

User avatar
Xplodwild
Goblin
Posts: 231
Joined: Thu Feb 12, 2009 3:49 pm
Location: France
Contact:

Re: New Terrain Early Shots

Post by Xplodwild » Sun Nov 08, 2009 6:59 pm

Any news about it?
0 x

User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy

Re: New Terrain Early Shots

Post by boyamer » Sun Nov 08, 2009 9:38 pm

Would like to see the finished version of the terrain system :)
0 x

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

Re: New Terrain Early Shots

Post by sinbad » Tue Nov 10, 2009 7:08 pm

I'm only just getting back to it this week. I'm working on neighbour linking & updates right now.
0 x

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta » Fri Nov 13, 2009 12:09 am

I'm currently looking at integrating a pathing system into my RTS based game, and using the open source Recast library. The way this library works, it's a collection of functions that manipulate and create data resulting in a NavMesh.

I want to use the Ogre Terrain to create a NavMesh, but I don't see any APIs giving access to the vertex/triangle data. Is there an easy way to derive this, or is it too much to request an API to give access to this data? I know that visually the vertices and triangles change due to LOD, but I want data at the highest level of detail.

Also, is there any sort of paging that occurs by default? When I click my minimap to see another part of the terrain, there is a brief lag, I can only guess parts of the terrain are moving in and out of memory. If this is the case, how can I disable it, or should I disable it? My terrain is currently 500 x 500 ogre units, with 1 unit = 1 meter. (not too massive I believe)
0 x
Creator of QuickGUI!

Zero
Halfling
Posts: 50
Joined: Mon Mar 10, 2008 12:08 am
Location: Stuttgart|Germany
Contact:

Re: New Terrain Early Shots

Post by Zero » Fri Nov 13, 2009 12:37 am

Code: Select all

// With this you get the heights, only y values
pOgreTerrain->getHeightData();
// The size of the HeightData
pOgreTerrain->getSize() * pOgreTerrain->getSize();
I hope that help you ;)
0 x
Image

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta » Fri Nov 13, 2009 6:42 am

That only helps me if I have to manually generate the vertex/triangle data, which I'm hoping I don't have to do, since the Ogre Terrain must have this data already. :)

On a different topic, I'm trying to apply a very simple material to the terrain, so that my team's outdated laptops can run the game a little smoother while we develop other features. I've attempted to create my own material generator, however I'm getting a crash when trying to load the terrain. Due to my setup I haven't been able to break into the Ogre Terrain Source code, so I need some guidance.

Here is the material I want to apply to the terrain:

Code: Select all

material Terrain
{
	technique
	{
		pass
		{
			texture_unit
			{
				texture Terrain.png
			}
		}
	}
}
The goal is to write a very basic material generator that just returns this material when its "generate" API is called. Here is my material generator:

Code: Select all

	class GaiaTerrainMaterialGenerator :
		public Ogre::TerrainMaterialGenerator
	{
	public:

		GaiaTerrainMaterialGenerator() :
			Ogre::TerrainMaterialGenerator()
		{
			mProfiles.push_back(OGRE_NEW BasicProfile(this, "BasicProfile", "Dummy Profile used to texture entire terrain"));
			setActiveProfile("BasicProfile");
		}

		class BasicProfile : public Ogre::TerrainMaterialGenerator::Profile
		{
		public:
			BasicProfile(Ogre::TerrainMaterialGenerator* parent, const Ogre::String& name, const Ogre::String& desc) :
				Ogre::TerrainMaterialGenerator::Profile(parent,name,desc)
			{
			}

			virtual ~BasicProfile() {}
			Ogre::MaterialPtr generate(const Ogre::Terrain* terrain)
			{
				Ogre::MaterialManager& matMgr = Ogre::MaterialManager::getSingleton();

				return matMgr.getByName("Terrain");
			}

			Ogre::MaterialPtr generateForCompositeMap(const Ogre::Terrain* terrain)
			{
				return terrain->_getCompositeMapMaterial();
			}

			Ogre::uint8 getMaxLayers(const Ogre::Terrain* terrain) const
			{
				return 1;
			}

			void updateParams(const Ogre::MaterialPtr& mat, const Ogre::Terrain* terrain) {}

			void updateParamsForCompositeMap(const Ogre::MaterialPtr& mat, const Ogre::Terrain* terrain) {}

			void requestOptions(Ogre::Terrain* terrain) {}

			bool isLayerNormalMappingEnabled() const  { return false; }
			void setLayerNormalMappingEnabled(bool enabled) {}
			bool isLayerParallaxMappingEnabled() const  { return false; }
			void setLayerParallaxMappingEnabled(bool enabled) {}
			bool isLayerSpecularMappingEnabled() const  { return false; }
			void setLayerSpecularMappingEnabled(bool enabled) {}
			bool isGlobalColourMapEnabled() const  { return false; }
			void setGlobalColourMapEnabled(bool enabled) {}
			bool isLightmapEnabled() const  { return false; }
			void setLightmapEnabled(bool enabled) {}
			bool isCompositeMapEnabled() const  { return false; }
			void setCompositeMapEnabled(bool enabled) {}
		};
	};
I started writing this by first copying the TerrainMaterialGeneratorA class and trying to simplify everything. The last part was using this new TerrainMaterialGenerator. I'm not sure when/where/how I should be setting the material generator, this is what I have:

Code: Select all

		Ogre::SceneManager* mSceneMgr = mScene->_getOgreSceneManager();

		Ogre::TerrainGlobalOptions::setDefaultMaterialGenerator(Ogre::SharedPtr<Ogre::TerrainMaterialGenerator>( OGRE_NEW GaiaTerrainMaterialGenerator()));

		mTerrain = OGRE_NEW Terrain(mSceneMgr);

		Image img;
		img.load("terrain.png", ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);

		Terrain::ImportData imp;
		imp.inputImage = &img;
		imp.terrainSize = img.getWidth();
		imp.worldSize = mTerrainDesc->width;
		imp.inputScale = 6;
		imp.minBatchSize = 33;
		imp.maxBatchSize = 65;
		imp.pos = Vector3::ZERO;
		mTerrain->prepare(imp);
		mTerrain->load();
The very last line is where the crash occurs. I was hoping the log might be more useful, but nothing stood out to me:

Code: Select all

21:00:55: Terrain created; size=257 minBatch=33 maxBatch=65 treeDepth=3 lodLevels=4 leafLods=2
21:00:55: Terrain::distributeVertexData processing source terrain size of 257
21:00:55:   Assigning vertex data, resolution=257 startDepth=1 endDepth=3 splits=2
21:00:55:   Assigning vertex data, resolution: 65 startDepth=0 endDepth=1 splits=1
21:00:55: Terrain::distributeVertexData finished
Any help would be greatly appreciated. As I said, right now I want a super simple Terrain, no shaders, no lighting, just a heightfield with a texture applied to it.

(btw searching the forums revealed nothing about the TerrainMaterialGenerator, which means either I'm one of the first few people to work with it 8) , or everybody else didn't have any problems with it :cry: )
0 x
Creator of QuickGUI!

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

Re: New Terrain Early Shots

Post by sinbad » Fri Nov 13, 2009 3:28 pm

KungFooMasta wrote:I want to use the Ogre Terrain to create a NavMesh, but I don't see any APIs giving access to the vertex/triangle data. Is there an easy way to derive this, or is it too much to request an API to give access to this data? I know that visually the vertices and triangles change due to LOD, but I want data at the highest level of detail.
Actually, the Terrain object doesn't hold this information. The terrain is what I call "hierarchically batched" which means there is no set of vertex data at the highest LOD which covers the entire terrain - instead there are a series of hierarchical nodes which each store a specific range of LODs, each of which has a different coverage of the terrain. The only batch which has the whole terrain stored in one are the lowest LOD levels - used when the terrain is very far away. This allows us to efficiently render the entire terrain in one batch when far away, but closer up smaller (physically) batches are used for higher LODs but overall the vertex data for each batch is of the same size (or within a small range). This also allows us to deal with terrains that would be impossible to address with 16-bit indexes - any patch with more than 256 vertices on each side is actually impossible to address as one batch anyway without 32-bit indexes, which I avoid for compatibility. My hierarchical batch system allows very large terrain patches while still respecting 16-bit indexes and generally giving better performance. Unfortunately, it can never be as simple as a single top-level set of vertex data.

So, if I gave you access to what we use internally, I think you'd just be very confused ;) You really do just need to extract the raw heights or just walk across the terrain using getPoint() if you want something 'raw'. I suppose I could provide an API which dumps unindexed full-LOD triangles into a buffer (or maybe with 32-bit indexing), but this will be really inefficient if you then have to re-process the buffer yourself anyway. It's much better just to hook out the points and plug those into your system directly.
KungFooMasta wrote:Also, is there any sort of paging that occurs by default? When I click my minimap to see another part of the terrain, there is a brief lag, I can only guess parts of the terrain are moving in and out of memory. If this is the case, how can I disable it, or should I disable it? My terrain is currently 500 x 500 ogre units, with 1 unit = 1 meter. (not too massive I believe)
No, there is no paging with a single Terrain instance. I get no noticeable lagging here.

I don't really have time to test your material generator for you right now - if you're going to get into this kind of thing you really should build Ogre from source so you can get a full trace.
0 x

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

Re: New Terrain Early Shots

Post by sinbad » Fri Nov 13, 2009 3:39 pm

I posted a little video of the updates I've been making recently to make multiple terrain instances work together with lighting etc:
Image
0 x

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

Re: New Terrain Early Shots

Post by jacmoe » Fri Nov 13, 2009 4:04 pm

Well, that's really awesome stuff! :D
Looking forward to having some fun with this in Ogitor.. :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

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

Re: New Terrain Early Shots

Post by sinbad » Fri Nov 13, 2009 5:07 pm

I'm not done yet, the intention is to create a 'helper' class inside the Terrain component to make it easier to use multiple terrain instances with neighbour links (without paging), and then the paging component will tie into that to add / remove pages according to camera motion etc. But, you can play with it right now so long as you're happy to slot the terrain instances together manually which is what the demo does for now.
0 x

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

Re: New Terrain Early Shots

Post by jacmoe » Fri Nov 13, 2009 5:10 pm

Close enough, for now. :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
Nauk
Gnoll
Posts: 647
Joined: Thu May 11, 2006 9:12 pm
Location: Bavaria
Contact:

Re: New Terrain Early Shots

Post by Nauk » Fri Nov 13, 2009 6:53 pm

Impressive :) - Must have been quite the amount of hours going into this to get it right...I can only imagine, seeing how many people before burned out on the paging subject. The video is a real appetizer, looking forward to use it :)
0 x

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta » Fri Nov 13, 2009 8:05 pm

I don't really have time to test your material generator for you right now - if you're going to get into this kind of thing you really should build Ogre from source so you can get a full trace.
Alright, I will work on altering my projects to link to the source instead of against my team's SDK. But I was actually hoping you could simply paste up a MaterialGenerator that doesn't do anything except returns a hardcoded material definition from file. You have a decently complex TerrainMaterialGeneratorA, couldn't you supplement the use of the MaterialGenerator with a super basic one? (TerrainMaterialGeneratorB?) I'm also saying that I do not know if I'm setting the MaterialGenerator correctly, in your example the TerrainMaterialGeneratorA is set as the material generator by default, not using any of the public APIs you created. (TerrainGlobalOptions::setDefaultMaterialGenerator) How does one use their own material generator? At which point should they set the material generator, before preperation of the terrain, or after loading the terrain? I think my problem is very fundamental because my MaterialGenerator's generate API is never even called, thus there is some problem occuring with building the terrain, before a material is even required.

Nice movie!
0 x
Creator of QuickGUI!

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

Re: New Terrain Early Shots

Post by sinbad » Sat Nov 14, 2009 11:31 am

KungFooMasta wrote:You have a decently complex TerrainMaterialGeneratorA, couldn't you supplement the use of the MaterialGenerator with a super basic one? (TerrainMaterialGeneratorB?)
A fixed function material generator is on my TODO. So are a lot of things. ;) But that's still not what you want - I have no use for a single-texture terrain because it doesn't implement the layer model; my fixed-function version will have to, which is not a 5-minute job. Frankly I have more critical issues to address in the terrain first, such as a lingering corruption issue I'm fighting with right now, then fleshing out the paging is next. I don't think it's unreasonable to ask you to investigate your own problem a little deeper in the mean time. If I get sidetracked all the time I'll never finish.

And there's nothing 'special' about TerrainMaterialGeneratorA except that it gets used if you haven't specified one in TerrainGlobalOptions::setDefaultMaterialGenerator. It's a subclass like anything else, there's no reason other subclasses wouldn't work.
(TerrainGlobalOptions::setDefaultMaterialGenerator) How does one use their own material generator? At which point should they set the material generator, before preperation of the terrain, or after loading the terrain?
Set it as the default via TerrainGlobalOptions before creating the terrain. Strictly it's before prepare() but there's no need to delay.
0 x

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta » Sat Nov 14, 2009 9:36 pm

Thanks Sinbad, I didn't realize it wasn't a quick fix. As I said I'm just trying to find a way to make my game run a little smoother in debug mode on my laptop and my bro's laptop, for when we meet; I'll probably just use the default material generator and set one layer, and have the splat texture tile across the entire terrain 1 time, hopefully that helps performance some.
0 x
Creator of QuickGUI!

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

Re: New Terrain Early Shots

Post by sinbad » Wed Nov 18, 2009 12:13 pm

By the way, I believe I have now fixed all the cases of geometry corruptions and 'unable to blit' errors that would occasionally occur under certain editing conditions. Please let me know if you find any more because I'm fairly convinced that this is solid now :)
0 x

User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK
Contact:

Re: New Terrain Early Shots

Post by SpannerMan » Thu Nov 19, 2009 3:03 pm

Wow, just watched the terrain video for the first time. This is amazing stuff - lighting and shadows continuing across independant tiles like that? Just fantastic.
Had my sound switched off and wondered why there was no movement until I realised Steve was giving a commentary. Is that a first Steve? Shame I was expecting some sort of mad accent tinged with a bit of Yorkshire, but you sound fairly normal in a neutral Southern sort of way ;)
0 x

Post Reply