New Terrain Early Shots

[haibo19981985]

I use new terrain in my project.
Today I meet a problem:After I set direction light which diffuse(1,1,1) and specular(0.5,0.5,0.5),the terrain is too bright;
After I set direction light which diffuse(1,1,1) and specular(0.1,0.1,0.1),the model's specular is too dark.
So I think whether can the new terrain support setting of the specular or not.
But I don't find some useful info in ogre forums and ogre source.
Anybody can solve the problem?

[jacmoe]

Experiment.
That's what 'the rest of us' do.
If 0.5 is too bright, and 0.1 is too dark..
And, yes: I noticed that the specular is a bit.. shall we call it: aggressive?

[Praetor]

Adjust the brightness of your specular texture in photoshop until it is exactly what you want.

[haibo19981985]

What I say above is not that the model's specular has problem(I set model material specular(1,1,1,1)).
Just when the terrain show normal ,the model show too dark.
Because only a direction light,if you set the light suited the terrain,then the light will not suited the model.
Moreover,I don't want to add specular texture,because it is aptotic and don't change if the light's direction changes.
So I want to set the terrain's specular as same as the model's specular can be set in the material.
But apparently the new terrain doesn't support to set the terrain's specular now.
I expect this function can come true at an early date.

[jacmoe]

Adjust the brightness of your specular texture in photoshop until it is exactly what you want.

That's what I did, using Pixplant.

I posted how I did the textures using the free ShaderMap CL here:
http://www.ogre3d.org/forums/viewtopic. ... 50#p374183

Sinbad said he used Pixplant (some posts down), and so I switched to using that.

A proper set of textures is absolutely *crucial* to achieve the right look.

[haibo19981985]

hi,jacmoe.
What you say is ogitor,right?
yes,I see.
But it seems that the most important use of pixplent should be creating normal texture.
I don't find use of the specular texture when ogre can support dynamic light on model.
Just Torchlight, it uses apparent dynamic specular on its model.
If what I say has some error,please point out.

[Bostich]

Hi guys,

iam currently running into a small problem, mb someone is able to help me.

For a simple water plane iam currently develope, i need the depth of the scene within a texture.

On my depthRenderTarget viewport, the Terrain LOD looks diffrent, then in my main viewport. Do i have to inform the terrain about a new viewport?


thanks,

//bostich

Solved it by updating the viewport/rendertarget by myself, instead of automaticly by ogre.

//bostich

[jacmoe]

I don't find use of the specular texture when ogre can support dynamic light on model.
Just Torchlight, it uses apparent dynamic specular on its model.

No. It doesn't.
The terrain does not support true dynamic lighting because it bakes for performance.
So if you need some real-time day-night cycle stuff, you need to fake it using fog and periodic updates of the terrain textures in the background.
At least that's how I understand how it works.

If you leave any of those 4 texture channels out of your textures, you are going to see visual artefacts.

You are, of course, free to create your own material generator/handler.

[haibo19981985]

I'm sorry for my English.
what I say above about "dynamic light" is just the ogre light effect on model.
Though the direction of light is fixed,the model can rotate and the light effect on model show dynamic.
The terrain light bases on shader.
I see the ogre source and find the setting of specular,as follows:

Code: Select all

void TerrainMaterialGeneratorA::SM2Profile::ShaderHelper::updateFpParams(
		const SM2Profile* prof, const Terrain* terrain, TechniqueType tt, const GpuProgramParametersSharedPtr& params)
	{
		params->setIgnoreMissingParams(true);
		// TODO - parameterise this?
		Vector4 scaleBiasSpecular(0.03, -0.04, 32, 1);
		params->setNamedConstant("scaleBiasSpecular", scaleBiasSpecular);

	}

Only set value of "scaleBiasSpecular",it must change the specular of the terrain.
I'm trying to come true it today.

[Captain_Deathbeard]

The terrain does not support true dynamic lighting because it bakes for performance.
So if you need some real-time day-night cycle stuff, you need to fake it using fog and periodic updates of the terrain textures in the background.
At least that's how I understand how it works.

Is this true? Doesn't that sort of defeat the object of having an outdoor setting if there is no day/night cycle? (well not for every game but for a major % of people needing terrain)

EDIT: just read post 1 again and it says the lighting is dynamic. Is it just the shadow maps then that are baked?

[sinbad]

EDIT: just read post 1 again and it says the lighting is dynamic. Is it just the shadow maps then that are baked?

Yes - you can update the lightmap in the background thread (the default) if you want to reflect changing time of day scenarios but the lightmap is presumed to be static so very fast day/night changes are not possible, but realistic ones are.

[sinbad]

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.

[stealth977]

Thats great news Sinbad, can be very handy for other stuff too. Do you plan to use it for mesh files too?

[sinbad]

Thats great news Sinbad, can be very handy for other stuff too. Do you plan to use it for mesh files too?

It's definitely an option, I haven't decided yet. The trouble is it would break tools built against previous versions in less obvious ways than the version bump does - unless I only compressed the data after the header or something like that. I might do it.

[Zonder]

Thats great news Sinbad, can be very handy for other stuff too. Do you plan to use it for mesh files too?

It's definitely an option, I haven't decided yet. The trouble is it would break tools built against previous versions in less obvious ways than the version bump does - unless I only compressed the data after the header or something like that. I might do it.

I would sugest a little tool be wrote to revert a mesh into it's uncompressed state for older tools that won't support the compressed format.

[stealth977]

Sinbad:

Today i switched to BYATIS for Ogitor and i have 2 major problems one of them is related to Ogre::Terrain:
- The decal cursor wont show up!!

Now i know that its because vertex compression, but i dont know what vertex program to use for the decal pass...

Any ideas?

[sinbad]

As ever the answers are in TerrainMaterialGeneratorA: you just need to expand the vertices in the same way I do:

Code: Select all

pos = mul(posIndexToObjectSpace, float4(posIndex, height, 1));
uv = float2(posIndex.x * baseUVScale, 1.0 - (posIndex.y * baseUVScale));

You can get 'posIndexToObjectSpace' from terrain->getPointTransform and 'baseUVScale' from the calculation '1.0f / (terrain->getSize() - 1)';

If you like just run the demo in debug mode and the generated shaders will be dumped into Ogre.log in their entirety anyway, look for "*** Terrain Vertex Program" and "*** Terrain Fragment Program"

[moadib]

Anyone have ideas how solve problem with artefact on decal, which cross line beetween batches(with skirt).
I can see this, for example, in Ogitor

scr.jpg

Another screenshot, from our application.

scr2.jpg

Any magic stuff with deptbias?(make it depend from camera distance? or somewhat else?)

[stealth977]

@Sinbad:

Code: Select all

Ogre Memory: Detected memory leaks !!! 
Ogre Memory: (10) Allocation(s) with total 5243080 bytes.
Ogre Memory: Dumping allocations -> 
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3259) : {40 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3257) : {1048576 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3259) : {40 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3257) : {1048576 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3257) : {1048576 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3259) : {40 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3259) : {40 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3259) : {40 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3257) : {1048576 bytes} function: Ogre::Terrain::calculateLightmap
..\..\..\OGRE17\Components\Terrain\src\OgreTerrain.cpp(3257) : {1048576 bytes} function: Ogre::Terrain::calculateLightmap

this is v1-7 branch but i guess development has the same issue...

[stealth977]

IMPORTANT BUG:

Code: Select all

bool Terrain::prepare(const ImportData& importData)
..................
..................
mPos = importData.pos;
mRootNode->setPosition(mPos); <<< THIS NEEDS TO BE ADDED!!!!

during manual prepare, mPos is initialized, but rootnode's position is never set...

[boyamer]

Agree,terrain position doesn't change to me too..

[sinbad]

Anyone have ideas how solve problem with artefact on decal, which cross line beetween batches(with skirt).

Presumably you're either using non-standard depth write/check settings, or using a depth bias which is 'pulling' the skirt above the terrain surface.

The best option is to render your decals differently. Really, using the primary terrain geometry to decal is highly inefficient since the majority of the area you're rendering is not within the circle you want to decal on. You can construct separate decal geometry by sampling the terrain at a known frequency of your choice, over the area of the decal, and render that instead (with a depth bias, or just manually shift the geometry up a little). Not only will it avoid the skirts issue, it will be considerably more efficient as a static decal - especially if you render many of them.

If these are dynamic decals (as in painting tools Ogitor) then it won't be quite as efficient, although it's still likely to be very doable even updating the decal mesh every frame, assuming there's only one of them.

@stealth977: will investigate

[sinbad]

Both the position and memory leak issues should now be fixed in both branches.

[stealth977]

Thank you We are going to make a new release of Ogitor tonight, so the fixes are very much appreciated

[stealth977]

BTW, a minor problem:

if i add a new layer and getPointer to the layer and modify it, and then getMaterial() and modify the passes (add a decal pass since its lost when layer is added) and then call terrainGroup->update()

following problem occurs:

:retPair.second && "Error inserting new pass entry into PassGroupRenderableMap".

sorry for not clarifying it enough, but its the only way for me to reproduce the bug

NOTE: it was being caused in my terrain splatting code, so i just removed terrainGroup->update() since it was not needed for splatting and the problem disappeared, but still, its a sign that something is wrong...