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!
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: New Terrain Early Shots

Post by 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! :wink: .

@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.
User avatar
Beauty
OGRE Community Helper
OGRE Community Helper
Posts: 767
Joined: Wed Oct 10, 2007 2:36 pm
Location: Germany
x 39
Contact:

Re: New Terrain Early Shots

Post by Beauty »

jacmoe wrote: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. :wink:
Help to add information to the wiki. Also tiny edits will let it grow ... :idea:
Add your country to your profile ... it's interesting to know from where of the world you are.
Speculi
Gnoblar
Posts: 7
Joined: Thu Dec 20, 2007 12:16 pm

Re: New Terrain Early Shots

Post by 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
Gnoblar
Posts: 12
Joined: Tue Mar 08, 2011 11:36 am

Re: New Terrain Early Shots

Post by 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.
User avatar
nevarim
Gnoll
Posts: 675
Joined: Mon Jul 05, 2010 6:16 pm
Location: Pavia Italy
x 4
Contact:

Re: New Terrain Early Shots

Post by 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
i'm a noob until proven otherwise :D
used in my project ;) and thanks to everyone :D
Ogre 3d
Mygui
Skyx
Hydrax
MOC
CCS
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: New Terrain Early Shots

Post by 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! ;)
Image
User avatar
nevarim
Gnoll
Posts: 675
Joined: Mon Jul 05, 2010 6:16 pm
Location: Pavia Italy
x 4
Contact:

Re: New Terrain Early Shots

Post by nevarim »

it's true :D

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

Nevarim
i'm a noob until proven otherwise :D
used in my project ;) and thanks to everyone :D
Ogre 3d
Mygui
Skyx
Hydrax
MOC
CCS
amlee
Gnoblar
Posts: 12
Joined: Tue Mar 08, 2011 11:36 am

Re: New Terrain Early Shots

Post by amlee »

Thanks nevarim, and much much more to sinbad :)
blackmonster
Halfling
Posts: 55
Joined: Tue May 17, 2011 11:20 am
x 1

Re: New Terrain Early Shots

Post by blackmonster »

What technique of rendering polygons are you using? Is it a ManualObject or submesh or something else?
User avatar
sleo
Gremlin
Posts: 171
Joined: Sun Jun 05, 2011 6:49 am
Location: Vodka Federation
x 18

Re: New Terrain Early Shots

Post by sleo »

sinbad wrote: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.
sinbad wrote: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
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New Terrain Early Shots

Post by LBDude »

I think Google Summer Code teams have their own clone of the 1.8 repo.
My blog here.
Game twitter here
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 »

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
sleo
Gremlin
Posts: 171
Joined: Sun Jun 05, 2011 6:49 am
Location: Vodka Federation
x 18

Re: New Terrain Early Shots

Post by 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
Gremlin
Posts: 193
Joined: Fri Jan 25, 2008 6:55 pm
Location: Nantes / France
x 17

Re: New Terrain Early Shots

Post by 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
Gremlin
Posts: 153
Joined: Tue Jun 09, 2009 9:31 am
Location: Russia
x 12
Contact:

Re: New Terrain Early Shots

Post by 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
Gremlin
Posts: 153
Joined: Tue Jun 09, 2009 9:31 am
Location: Russia
x 12
Contact:

Re: New Terrain Early Shots

Post by 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
Gremlin
Posts: 153
Joined: Tue Jun 09, 2009 9:31 am
Location: Russia
x 12
Contact:

Re: New Terrain Early Shots

Post by Kenshido »

Kenshido wrote: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.
User avatar
aronze
Gnoblar
Posts: 15
Joined: Sun Nov 30, 2008 6:04 pm

Re: New Terrain Early Shots

Post by aronze »

bug?

Code: Select all

    uint8 Terrain::getBlendTextureCount(uint8 numLayers) const
    {
        return ((numLayers - 1) / 4) + 1;
    }
5 numLayers just need a one rgba texture.
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 »

Lightmap?
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
aronze
Gnoblar
Posts: 15
Joined: Sun Nov 30, 2008 6:04 pm

Re: New Terrain Early Shots

Post by aronze »

jacmoe wrote: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.
Last edited by aronze on Mon Apr 09, 2012 2:30 pm, edited 1 time in total.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: New Terrain Early Shots

Post by 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.
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 »

Where is that code?

Don't forget colour map and 3xPSSM.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
aronze
Gnoblar
Posts: 15
Joined: Sun Nov 30, 2008 6:04 pm

Re: New Terrain Early Shots

Post by aronze »

jacmoe wrote: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.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: New Terrain Early Shots

Post by 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.
Developer @ MakeHuman.org
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: New Terrain Early Shots

Post by bstone »

I thought everybody does that :D 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.
Post Reply