New Terrain Early Shots

[al2950]

Good work Beauty. However it is definitely not a scene manager, the old one was, but a major point of the new one is that is can be used with any scene manager, because its not a scene manager its self.

I have not changed the wiki yet as I dont think it should be under "the scene manager FAQ " group. I believe there should be a separate "Ogre components" which should have things like the new terrain system and RTSS. However i am too scared to change the wiki and getting told off! .

@Jacmoe
I think i spoke to you about this before, and you convinced me it was not the best way to do it, however I again think there should be a "components" part in the wiki.

[Beauty]

It's not a scene manager.

Ok, now I know for sure that it isn't a scene manager, but that's all.
Now I don't know how to describe it better, because I don't know the details.
Also by reading the Basic Tutorial 3 doesn't help me for an improved description.

It would be great when a wise user does it.

Related to the node of the wiki structure:
Right, a "component" section/node can be useful. I wasn't shure where to add. So I added it at the same node as the TSM.

Don't be afraid of wiki work. If a change is not optimal, it can be changed again.

[Speculi]

To the Wiki Part:

If there is/will be a section about components, and this "terrain component" does not fit into the scene manager section, still a link to the components section would be helpfull to find it. (At least, it is somehow related to scene managers, isn't it?)

[amlee]

How to scale Terrain Size in X, Z and Height? Changing the terrain world size in demo 1.7.2 does not seem to have any effect.

[nevarim]

have you delete .dat in media folder?

when terrain is created first time it create a dat file where is put "ghost" of terrain

and for modify height of terrain (Y axys and not Z axys) you must have to use scale option

[Jabberwocky]

Please, if you have specific problems with the terrain, open a new thread in the help section, because:
1- this is a showcase thread
2- this thread is already 27 pages long, and if everyone posts their problems (and answers) here, it will soon be 270 pages long.

Thanks!

[nevarim]

it's true

but at the end of this thread i want to thank sinbad for new terrain component, it's a grat things

Nevarim

[amlee]

Thanks nevarim, and much much more to sinbad

[blackmonster]

What technique of rendering polygons are you using? Is it a ManualObject or submesh or something else?

[sleo]

As I say, the trouble with that multi-method approach is that it doesn't work with packed, streamed data which evolves over time. By defining a specific set of data steps, and the order in which they happen, you lock the packed data format into a specific read order which is just too restrictive - either that or you force support of random-access data which is also unacceptable. I've dealt with packed data like .mesh for years and one thing you never want to do is close off the option to change the format later.

Yes, you could implement the current sequence this way but it would lock in the order & granularity forever.

I say again, you want a single unified load / save. Or, more to the point, I won't accept this unless it does it that way. The format & sequence is then up to the serialiser itself which is vastly more flexible.

I don't understand. The serializer can hold data in memory or file projected in memory and just have flag of data being compressed or not. Then stream is ordered to be flushed or closed the data is packed and the flag is set to true.

I just added a new feature to 1.8, 'DeflateStream' which as the name suggests wraps another stream and compresses / uncompresses the contents using the standard 'deflate' algorithm (via zlib which we already use). The advantages of this over using a .zip archive are:

• You can write to them - ZipArchive is read-only and it's inefficient to try to update whole zips anyway
• It can literally compress / decompress any other stream; so not only a file stream but also a network stream, database stream or anything else you choose to implement
• It preserves the underlying stream state so you can embed compressed data in a chunk inside a stream which has other data in it too (uncompressed, compressed otherwise, stream from shared data packs etc)
• When reading, it detects if the underlying stream is compressed or not, and if it isn't it silently does a pass-through read on the original stream. This means you can pass a stream to it that's actually uncompressed and it will continue to work without requiring any work on the part of the caller.

I've made the Terrain component's save() and prepare() function that take a filename use this new stream. The result is that if you save a terrain page via the standard methods the terrain data files are now compressed - for example the 513x513 pages in the demo are now 3.4MB instead of about 12MB. If you pass a StreamSerializer of your own instead then it's up to you to wrap your stream in DeflateStream if you want to comrpess / uncompress.

Because of the safe fallbacks in DeflateStream, uncompressed terrain data will continue to load as before. However as soon as you re-save it it will suddenly shrink

Enjoy. Hopefully this should appease those that found the terrain data files to be a bit weighty We may change the underlying format to be even smaller later on too, but this has the benefit of being lossless and almost completely free, except for a few CPU cycles which are no doubt regained from faster disk access on read anyway.

So it has been realized in 1.8... But I'm scared to move to it since there Google Summer of Code about Terrain and I can get into unstable version. Never have tried mercurial

[LBDude]

I think Google Summer Code teams have their own clone of the 1.8 repo.

[jacmoe]

Here we go:
https://bitbucket.org/kuxv/ogre_soc_tpi/overview

[sleo]

Compiled 1.8.0unstable rev 2907. Terrain now trying to create some pure pages in C:\ and deflated pages in Resource Group of Terrain Group, but C:\ is read-only in Windows 7 for default user. And these temporary files not removed after application exit. How to configure to store temporary files not in C:\ and how to remove these temporary files with which function?

Also have tested OpenGL ES 2 renderer using Imagination Technologies implementation. SGIX OpenGL ES 2 is completely not working with terrain, complains Downloading texture buffers is not supported by OpenGL ES in GLES2TextureBuffer::download. Generic OpenGL ES 2 is only showing blank screen with edit sphere mesh.

[Nodrev]

Hi,
First, It's a showcase thread. I know that everybody took the habit to respond to those issues in this part of the forum, but please, use a new topic in Help (or at least Dev), cause I feel (and I'm sure I'm not the only one) it becomes more and more difficult to find informations in this forum, as some "help" topics are blended in the showcase.
And that especially true for THIS 27 pages long post, which have lots of useful informations mixed with some "please, help me!" messages.
Else, for your problem, indeed, Ogre generate some miscellaneous files at the root of the active partition in some case when using terrain, I got the same issue (for me it's on D: as i run on this disk, didn't notice thoses files on Ubuntu), but I do not search where that comes from.

[Kenshido]

Is it impossible to obtain textured terrain with a graphics card that supports only pixel shader 2.0 and doesn't support any vertex program?

[SOLVED] the problem in old card that in 1.7 version don't support vertex shader.

[Kenshido]

One more question about performance. I've been comparing performance of old and new terrain yesterday. Conditions were Ogre 1.6.5 and default project with own framework (generated by 1.6 appwizard). Terrain was textured by custom material using splatting shader with 4 splatting textures and defuse/specular calculations. Second case Ogre 1.7.2 with same framework (generated by 1.7 appwizard). Same terrain, but default 1.7 layers. I switched off normal, parallax and lightmap calculations to have pretty same conditions and got about 1.5-2 times lesser fps. Why? Shouldn't by it faster because of composite map for example?

[Kenshido]

One more question about performance. I've been comparing performance of old and new terrain yesterday. Conditions were Ogre 1.6.5 and default project with own framework (generated by 1.6 appwizard). Terrain was textured by custom material using splatting shader with 4 splatting textures and defuse/specular calculations. Second case Ogre 1.7.2 with same framework (generated by 1.7 appwizard). Same terrain, but default 1.7 layers. I switched off normal, parallax and lightmap calculations to have pretty same conditions and got about 1.5-2 times lesser fps. Why? Shouldn't by it faster because of composite map for example?

Take my words back. It very depends on conditions. New terrain is much more accurate with the same maxPixelErrors parameter and uses more vertices and less batches.

It would be very nice to have a possibility to enable simple specular effects for composite map, because sometimes it looks very different, when fair material shines.

[aronze]

bug?

Code: Select all

    uint8 Terrain::getBlendTextureCount(uint8 numLayers) const
    {
        return ((numLayers - 1) / 4) + 1;
    }

5 numLayers just need a one rgba texture.

[jacmoe]

Lightmap?

[aronze]

Lightmap?

No, blend mask textures. Bottom layer does not need a blend mask. So, one RGBA texture is covered 5 layers. Currently, if OgreTerrain use 5 layers, it is used to 2 blend textures. Therefore, in this case, second texture will be not used.

[bstone]

Yeah, the bottom layer doesn't need it, hence (numLayers - 1), I think. The final increment is probably to ensure that at least one blend texture is allocated. I kind off see the logic but it really doesn't work well for 5 layers. Looks like a bug to me too.

[jacmoe]

Where is that code?

Don't forget colour map and 3xPSSM.

[aronze]

Where is that code?

Don't forget colour map and 3xPSSM.

See OgreTerrain.cpp

Code: Select all

	uint8 Terrain::getBlendTextureCount(uint8 numLayers) const
	{
		return ((numLayers - 1) / 4) + 1;// if numLayers is 5, blend texture count is 2!!! but 5 layers just need a one rgba texture. Bottom layer is not need mask.
	}

max texture count: 16
----------------------------------------
global normal texture: 1
global colour texture: 1
light texture: 1
diffuse/specular/normal/height: 2 * 5 = 10
blend mask texture: 1

In this case, exist slot is 2? No, it's not true. Existing slot is one. Actually, blend mask texture count is two. Of course, second mask is not used.

--edit
I was want to use 5 layers and 3xPSSM. So, I was remove normal/height texture from bottom layer, but then, bug has occurred. If you don't more want to 4 textures or use less PSSM textures,this bug will not be occur.

[duststorm]

I'd like to announce my new method of compiling terrain textures compatible with the Ogre::Terrain shaders.
I found out about the cross-platform crunch library that allows to create DDS textures from a commandline. Together with ImageMagick I created a compile script that will create .DDS textures from 4 separate PNG input files.

The rationale is that an artist creates a terrain texture as 4 separate PNGs (diffuse RGB image, normal RGB image, specular greyscale image, and heightmap greyscale image). All those are stored in a source folder. To get the textures in the Ogre application one has to run the bash script that will compile the correct DDS textures.

I've documented it on the wiki:
http://www.ogre3d.org/tikiwiki/tiki-ind ... mageMagick
Hope this is useful for someone else too. The script is bash (linux and mac), but with a few minor syntax changes one could create a windows .bat, or even better: create a multi-platform python version .

For me, it makes the textures more understandable. It's easier to work with PNG files than those DDS things, especially because of the alpha channels that contain information not related to actual transparency.

In fact, a similar approach could be used for your entire material setup. This has the advantages of working with a familiar and manageable png format (that is lossless!) while retaining the GPU memory reduction advantage that DDS offers.

[bstone]

I thought everybody does that I used ImageMagick and NVidia's DDS command line tools all bundled in a makefile that kept all DDS resources up to date. Was natural to me but now that you mentioned it I think you did a good thing sharing it here. Maybe somebody else haven't thought about it and was struggling with DDS files all the way.