Andrea!

Many thanks, that's great like this.

So we got to have a sharp look into what Celestia is doing here...

Bye Fridger

_________________

Hi all,
I've been visiting the forum for a while now and I thought I may be able to contribute and learn something here.

This seam problem looks similar to a problem I encountered when I tried to fix the seams on my 3dmars model. My seams problem to be related to normals somehow. Not the normals from a normalmap but the normals from the mesh. I mean vertex normals. I have some screen shots in the Addons forum at Shatters, 3dmars update/page 8.
cartrite

Welcome cartrite,

good to see you here and looking forward to your interesting contributions!

Bye Fridger

_________________

Thanks Fridger,
I was checking out this thread and my problem with the 3dmars model and this problem with seams look like they are related somehow. Something that Celestia is doing along certain texture borders.
This screen shot is from a 64k bmng vt I did last year.




Here is the same area in wiremode.



The texture seems to be shadowed differently when the border of a tile lands on a vertex border or an edge between two vertices.
cartrite

I think I may have discovered at least one possible explanation for the seams.
Summary: Color maps on their own do not appear to exhibit severe problems. However, seams appear when a normal map VT is used.
I think this is because the normals for two adjacent pixels but belonging to two different normal map tiles are usually slightly different.
This difference causes a visual discontinuity unless the normals are averaged beforehand.
This seems to exonerate F-TexTools or nmtools. However, it may still be possible to workaround the issue by modifying nmtiles.

Details:
1. I made two level 5 color tiles with a pattern painted on them, just to check for any tile registration problems:


2. Rendered in Celestia - seam free (polygon boundaries do exhibit a slight darkening, but it's nearly invisible):


3. Two level 5 normal map tiles, generated by nmtools, that are guaranteed to be adjacent when rendered.
As you can see there are no registration problems or seams:


4. Normal map rendered in Celestia - seam is clearly visible:



The normals of two adjacent pixels that belong to different normal map tiles are often slightly different (due to the curvature of the surface).
My theory is that this slight difference causes a visual discontinuity (seam) along normal map tile boundaries.
This is very much analogous to the situation in a 3d modeler, where seams may appear if the user forgets to weld vertices.



Adjacent normals arising from normal mapping should be averaged to prevent such a discontinuity.
I think however that Celestia itself is not doing this.

Instead of modifying Celestia however, it may be possible to work around the issue by averaging adjacent normals
when generating tiles, i.e., by including code in nmtiles.

While all that may be true dirkpitt, that still doesn't explain the seam found on textures w/o normal maps, or VTs at all, such as:



I'm not saying that you're wrong, I'm just saying that I believe it's more than just a normal map VT issue.

_________________
My PC: AMD Athlon X2 4400+; 2 GB of OCZ Platinum RAM; 320 GB SATA HDD; NVidia EVGA GeForce 7900GT KO, PCI-e, 512 MB, ForceWare ver. 163.71; Abit AN8 32X motherboard; 600 watt Kingwin Mach1 PSU; Windows XP Media Center SP2;

johaen ,
Since the texture you showed is 16k, and most cards can't render a 16k, I know mine can't and I got a series 8600, Celestia tiles the texture creating an internal "VT" which will then show seams.
You are correct though, I'm seeing seams with no normalmap. Here are 3 screen shots of the same area with different datasets.
Screenshot 1 shows BMNG October using a normalmap and it was done long ago so the F-tex tools were not used.



Screenshot 2 shows BMNG July. It has a normalmap enabled but was also done without F-textools and a completely different way.



Screenshot 3 shows BMNG April with No normalmap and was done with F-tex tools 1.0pre4. They all show the same seams.



Considering my post from 10/25 and this one, a couple of questions arise. First, texture pixels are rendered on a face, correct? The vertices are also colored by the texture too, correct? When the vertices are shared by 2 tiles, are the vertices adding the color from both tiles and then blending with the pixels being rendered on the face while vertices that are not shared have a lesser value because nothing was added or blended? Confusing question? Sorry.
cartrite

It does look like there might be more than one reason for the seams.
Anyway it's weird, don't know why my red/white striped tiles weren't showing a seam..

Are your examples using DDS tiles? Were they compressed with the latest version of the nvidia tools? (nvcompress)

No. They are all in the png format. I think there may be a bug in the code for the GPU. Adding values when 2 textures share a group of vertices or a vertex edge.

As for nvcompress, I can't get nvidia texture tools to work on this computer. I think it may be because it's a 64 bit processor? Anyhow the windows version installs but when I try to run the cmd console I get this missing shortcut window that says "Looking for system32cmd". The linux version won't build. Says It's the wrong cpu or something like that as soon as I run make. I'll wait for a beta version.

cartrite

I just tried modifying the Celestia code to render without lighting and vertex color blending
(disabled GL_LIGHTING, shade model GL_FLAT, tex env mode GL_DECAL)
I still get the seam

Some shading problems that might arise due to clipping (see here) are out too,
because forcing flat shading doesn't make a difference.

UPDATE:
I tried out something crazy - I duplicated a tile, mirrored it, and saved it so it would be an adjacent tile in Celestia.

Result: No seam!

Before experiment - no normal map. Note seam (click for larger image):


Wireframe:


I duplicated and mirrored one of the tiles using Photoshop. This makes the pixels along the tile boundary identical to each other:


Result in Celestia. Seam is gone.


Here're the mirrored tiles again, but with a non-mirrored normal map.
Seam appears again - due to the normal map (png format):


However, if I also replace one of the normal map tiles with a mirrored twin, the seam goes away.

DW,

I'm wondering if this might be the equivalent of a fencepost problem in the graphics hardware -- being off by one in its pixel count at the edges of surfaces.

One of the visual effects I've noticed on the interior of a model is in the opposite direction from what you're seeing on the outside. Instead of showing one too few pixel widths as you seem to be seeing, it shows one too many. With some models one can seem to see past the official edges of the texture being applied to a surface to adjoining areas of the surface texture. I've seen this effect when I've looked closely at the interior of a cube being used to display a panorama, at the edges where its surfaces adjoined: there were unexpected seams.

To me, the visual effect suggests that the graphics hardware isn't clipping the texture at the surface boundaries as well as it might, and one has to provide a compensatory offset in the texture coordinates which are specified in the mesh vertex list. In my case, for the interior of a cube, if one specifies in the mesh definition that the vertex locations of the corners of the cube correspond to locations in the surface texture image which are interior to the texture's edges then the cube's interior seams disappear. In other words, one needs to specify relative texture locations like 0.001 and 0.999 at the cube's vertices instead of 0.0 and 1.0. Since I was using 1K x 1K textures, this roughly corresponds to an offset of one column or row of pixels.

My interpretation of this effect on the interior of a cube is that it is caused by seeing inappropriate surface texture image pixels where they've apparently wrapped around beyond the 0.0 and 1.0 limits. (See http://www.lepp.cornell.edu/~seb/celest ... s.html#3.0 for a link to an Addon which demonstrates this.) An opposite effect, clipping too soon instead of too late, might explain the slight glitch at surface edges seen from the outside of a mesh.

_________________
Selden

I thought the whole trick of manually shrinking textures by 1 texel was supposed to have been made unnecessary with the GL_CLAMP_TO_EDGE wrap mode (which is used by Celestia's vt's)

Your description of eliminating the seam by placing two identical texture edges next to one another seems to indicate it doesn't fix this particular problem. Maybe it's not being applied to all edges?

How do the edges look if the single row of pixels along the adjacent edge of the flipped image is trimmed off?
if the columns of pixels adjacent to the edges of your two images (one flipped) are currently numbered
..3 2 1 0 | 0 1 2 3...

then what does this order look like?
...3 2 1 0 | 1 2 3 ...

if edge clamping is working, this should show no seam, either, since column 1 is supposed to be adjacent to column 0.

_________________
Selden

Good idea, I'll try this out.