[SOLVED] modular geometry seams

[Rob]

Hello,

 

My name is Rob and currently im working in Unigine to create a environment for a flight/hoover simulator

 

At the moment I ran into a little problem with seams on modular pieces of geometry

We are using modular pieces of 512x512 and when placing them to eachother the edges flicker and there is a seam

 

When assigning a texture it gets a lot worse and the seam is very noticable, so I was wondering if there is a sollution for this?

the problem is very simular to this one:

http://forums.cgsociety.org/showthread.php?t=859337

 

I know in the UDK it can be a problem with the tc_normalmap compression when importing normalmaps or it can be a problem with the lightmaps when the edges that repeat are not placed exactly on the border ov the UV space, but im not using any lightmaps in Unigine so I dont know what is wrong

 

Is there a fix to get rid of these seams?

[manguste]

Could you send us a mesh with textures (set its position to 0 and export into a node reference) so we can tell you what the problem is? There's something up with a normal map, but we need to have your asset on hands; otherwise, we can't be of much help.

[Rob]

Could you send us a mesh with textures (set its position to 0 and export into a node reference) so we can tell you what the problem is? There's something up with a normal map, but we need to have your asset on hands; otherwise, we can't be of much help.

 

We already abandoned this idea as it wasnt the feel we were looking for so we went for a large terrain without tubes etc, so I dont got those assets anymore

but what I created was some sort of slide mesh, half of a tube basically and then another with a bend for example, both pieces were 512x512 but when we tried to put them together there was a very noticable seam,

even when moving them exactly +512 to connect on the edges

 

It reminded me of this issue explained here for the UDK:

http://udkc.info/index.php?title=Tutorials:3Ds_Max_-_Fixing_z-fighting_%28vertex_welding_tutorial%29

 

But still the edges werent flickering, they were just too present while all the normals were facing in the correct directions,

It is like the lighting of the normal is being recalculated on every seam of every seperate mesh while the lighting should continue

 

The issue happens with and without any textures applied to the mesh so recreating this problem is very easy, just try to make modular pieces of geometry which need to connect on the edges

[manguste]

It means that normals at the edge of meshes do not point in the same direction. If they were, the lighting would be smooth. For example, in Max you try to merge these normals into one before exporting the meshes.

[Rob]

I just noticed it is happening because I dont believe we had 2 UV maps, 1 for texture and 1 for ligthing

this brings me to another question, when will the exporter for Maya 2012 be ready? Now it only works with maya 2011

As .obj does not support 2 UV sets so exporting 2 UV sets isnt possible from Maya 2012 without an updated exporter

 

*Edit*

I just exported it so it had 2 UV sets, and the seam problem is still there

It seems it has something to do with the normal maps, as soon as I assign one of my normal maps I get seams

Any clue why this is happening?

[Rob]

Even when I add a normal map with just 1 color and no details I get the seams, I am clueless how to fix this as normally you can fix stuff in photoshop by adding a neutral normalmap color to get rid of the seams but I get the seams even when using just a normalmap with 1 color so I must be doing something very wrong, I get these horrible seams on all of my meshes which use a normalmap

 

I added a file so you can try it for yourself

saguaro.rar

[Rob]

So any solutions for this? I looked for a way to merge normals on the seam but havent found anything usefull so far

Were using Maya by the way, when I look at the vertex normals in maya everything seems to be fine but as soon as I export my object the UV seam gets split into 2 vertex normals

 

Even when setting the vertex normals to a value like 1 for example does work for all vertex normals but as soon as its imported into the Unigine Meshviewer the seam is still being split up into 2 different vertex normals, it looks like its trying to get an average on the edge, so there is always a hard edge on my model which shouldnt be there

[manguste]

There's a problem with compressing you normal map indeed. Why it is in the DXT5 format? In Unigine, a normal map should be compressed into ATI2 format, when only two channels are stored (Red and Green channels). Not three. Incorrect compressed format was causing this artifact.

Check the attachment, a simple non-compressed TGA image is used there and looks fine. ATI2 - the same, no "caps". BTW, store your texture under textures/uncompressed folder - and it will be automatically compressed into a proper ATI2 format.

 

Here's also a feedback from our tech artist: why do you make these cactus folds (i hope you do understand what I'm talking about) with geometry? Why not use a normal map only? These polygons are actually not seen, meaning a model can be optimized and rendered faster. Or if you need it this way, why not stick to geometry only (no normal map) - it would look better. There will be already enough geometry details for convincing lighting of the model.

[Rob]

There's a problem with compressing you normal map indeed. Why it is in the DXT5 format? In Unigine, a normal map should be compressed into ATI2 format, when only two channels are stored (Red and Green channels). Not three. Incorrect compressed format was causing this artifact.

Check the attachment, a simple non-compressed TGA image is used there and looks fine. ATI2 - the same, no "caps". BTW, store your texture under textures/uncompressed folder - and it will be automatically compressed into a proper ATI2 format.

 

Here's also a feedback from our tech artist: why do you make these cactus folds (i hope you do understand what I'm talking about) with geometry? Why not use a normal map only? These polygons are actually not seen, meaning a model can be optimized and rendered faster. Or if you need it this way, why not stick to geometry only (no normal map) - it would look better. There will be already enough geometry details for convincing lighting of the model.

 

The model was just a test model, I made the folds to make a normal map, but later I decided I wanted to have the folds on the geometry

Oh my textures nee dto be in textures/uncompressed...Ive been using just a uncompressed folder and it would still show the seams, will test with the TGA and ATI2 formats

 

Well saving it with the right compression fixed it!

 

But the only question I have is do i need textures/uncompressed or just uncompressed?

[manguste]

It can simply be /uncompressed folder.

(BTW, if you are interested in details why DXT5 compression did not work for a normal map, it's because in Unigine signed values are used for normals, while alpha in DXT5 is always unsigned).