[SOLVED] Terrain coarse normalmap stepping issue/artefacts

[Rob]

When the engine generates a coarse normalmap texture I get these strange stepping artefacts on my terrain,

I was wondering how I could prevent this from happening

 

I already tried inserting my own normalmap generated with WM2 but for some reason the terrain gets very bright, I tried copying the alpha channel from the coarse normalmap generated by Unigine but this did not help, I think it is hapening because WM2 outputs a regular blue/purple normalmap while the engine uses a greyscale normalmap when creating a coarse normalmap

 

Any suggestions?

 

Here is a screenshot of the stepping in the terrain and coarse normalmap texture:

[alexander.zubov]

I am sorry I might be missing something, but to my knowledge normal map is always RGB or RGBA. Only bump maps and height maps are grayscale .

[ulf.schroeter]

Most of the time normal maps are just 2 component RG textures for X/Y normal component to save texture memeory as Z component can be calculated in the shader due to normal length = 1 restriction.

[alexander.zubov]

All the normal maps I saw in any 3D game are in RGB or RGBA format (they put height map into normal maps alpha sometimes). That's what I observed for 3D models.

[ulf.schroeter]

Yep, you are right, but Unigine supports more-efficient 2 component RG format. See NormalCombiner tool for details

 

Save Save a combined normal map.

 

Two component - save a normal map in RG format. (The third

component will be restored by the engine at rendering time).

If unchecked, the normal map will be saved in RGB format.

[alexander.zubov]

How is it more efficient? Due to the smaller file size?

 

Anything that engine does at rendering time, which could be done otherwise, results in slower rendering. Perfect example is real-time radiosity. Yes, it's pretty and allows to create more sophisticated and dramatic atmosphere in games, but GF 4xx cards are still damn expensive :) So baked lightmaps coupled with few real-time lights is a better solution.

 

I would assume achviz industry doesn't care for performance and therefore quality realistic image is a priority ?

[ulf.schroeter]

Uses less texture memory.

[alexander.zubov]

True that.

[Guest shane.ploenges]

So if a Normalmap for Terrain is generated from World Machine, what format should it be converted to with ImageDDS? ati2? Should a terrain normal have MipMaps?

[Rob]

So if a Normalmap for Terrain is generated from World Machine, what format should it be converted to with ImageDDS? ati2? Should a terrain normal have MipMaps?

 

Just output a normalmap in WM, then load it up twice in the NormalCombiner tool, set the second one scale to 0 so it wont be overlayed on top of the first normalmap layer,

then save it like Ulf said with two components checked, now you will have a simular normalmap as the one generated by unigine

 

I tried loading it into Unigine and it seemed to work but the small 256x256 textures are still the ones with the stepping problem (00x00_n.dds etc)

So anyone know how I could update those? The engine needs an option to generate 256x256 tiles from the provided normalmap, atm it recreated the normalmap + 256x256 textures based on the heightmap data

while I would prefer that it would recreate the normalmaps based on the provided normalmap and not the heightmap

 

Could anyone from Unigine look into this?

 

Here you can see a comparison of the normalmaps, right one is the one generated based on the heightmap in Unigine, left one generated by WM2 and saved with the normalmap combiner

you cna clearly see the loss of detail in the one generated by the engine while both have the same size in resolution and MB

[ulf.schroeter]

Do you use dds compression for your normal ? If so don't do it as this would cause quantinization artifacts.

[Guest shane.ploenges]

This does not seem like a good way for us to do this, as we can possibly have many terrain tiles to process and doing one at a time is not practical. We need to use some sort of batch process and i though that this is what ImageDDS was designed to do? I am unsure however what settings we should be using with this to get our WM generated Normal Maps in to the correct format.

[Rob]

Do you use dds compression for your normal ? If so don't do it as this would cause quantinization artifacts.

 

I dont use any compression but the engine does when it generates a normalmap based on the heightmap, thats the problem here

so we either need an option to set our own normalmap the same way as the diffusemap is set up so it regenerates the 256x256 tiles or the compression needs to be removed or improved when the normalmap is generated by the engine

[alexei.garbuzenko]

ATI2N/3DC/BC5 normal compression algorythm is mostly loseless and could not have any compression artifacts. It is used in most recent 3d games and engines (CryEngine, UDK, GameBryo, etc.).

[Rob]

ATI2N/3DC/BC5 normal compression algorythm is loseless and could not have any compression artifacts. It is used in most recent 3d games and engines (CryEngine, UDK, GameBryo, etc.).

 

SO Unigine is using something different then?

[alexei.garbuzenko]

 

SO Unigine is using something different then?

No, Unigine is using exactly this format, so there is no compression artifacts. You have some other kind of problem that should be addressed to engine developers..

[alexander.zubov]

There are always compression artifacts, but probably to the lesser degree

[alexei.garbuzenko]

There are always compression artifacts, but probably to the lesser degree

Yes, I've mistaken with work 'losless', but 3dc have VERY few artifacts due to 2:1 compression.

http://www.gamasutra.com/view/feature/2496/texture_compression_techniques_and_.php

[alexander.zubov]

oh, interesting

[ulf.schroeter]

As always: post smallest possible test scene for problem reproduction. Otherwise its always more or less blind guessing

[manguste]

Maybe the reason of such moire patterns is that you use a 16-bit precision height map instead of the 32-bit one? This way instead of getting smooth gradient you'll get gradation steps.

[Rob]

Maybe the reason of such moire patterns is that you use a 16-bit precision height map instead of the 32-bit one? This way instead of getting smooth gradient you'll get gradation steps.

 

Wouldnt a 32 bit height map be much larger than a 16-bit map? I just find it strange that I can achieve a high detailed normal map without stepping with Worldmachine while the Unigine normal map has stepping issues

both are identical in size (MB and resolution) just the one generated from the height map seems to lack details and has stepping issues

 

An option for a custom normal map would definately help, this way users can even add custom details to the normal map

[ulf.schroeter]

Post small sample textures showing the problem....

[Rob]

Post small sample textures showing the problem....

 

Here are 4 samples

As you will see the 12x12 has much more detail

and the 12x11 is the normal generated from the heightmap in Unigine and is more blurry/low resolution while they use the same sizes

 

I also added 2 other files, 1 called stepping this is the 15x13_n.dds created from the heightmap in Unigine

I added a file called no_stepping.dds to show how it should look as it is just a flat area, this no_stepping.dds was rendered with WM2

 

So I think this clearly shows what the problems are atm

example_files.rar

[alexei.garbuzenko]

all terrain vertices in ObjectTerrain have their normal set to (0,0,1) - "up" direction, just the same as a plane with 0 height. That means that Unigine-generated normal vectors are in world-space rather than in object tangent space. It can happen that WM normals are in object space that could result in different lighting on seams, so importing normal map should at least be done with normal re-convertion.

 

Also there is a minor shader bug multiplying detail map normals that I've already sent to frustum by e-mail. I can post fixed shader here but it would be better just to wait for upcoming SDK update with this issue fixed.