It is currently Mon, 28-05-18, 5:16 GMT

All times are UTC




Post new topic Reply to topic  [ 196 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14  Next
Author Message
 Post subject:
PostPosted: Thu, 25-10-07, 13:21 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4562
Location: Hamburg, Germany
Andrea!

Many thanks, that's great like this.

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

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 25-10-07, 15:27 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
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


Last edited by cartrite on Thu, 25-10-07, 15:51 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu, 25-10-07, 15:49 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4562
Location: Hamburg, Germany
cartrite wrote:
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 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

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 25-10-07, 15:57 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
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.

Image


Here is the same area in wiremode.

Image

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-11-07, 16:14 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
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:
Image

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

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:
Image

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


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.

Image

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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-11-07, 16:30 GMT 
Offline

Joined: Thu, 18-10-07, 23:53 GMT
Posts: 16
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:

johaen wrote:
Here is the same view with Don Edward's "Don's Pale Blue Dot" 16k DDS, no normal map at all.

Image


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;


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-11-07, 18:11 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
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.

Image

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

Image

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

Image

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? :shock: Confusing question? Sorry.
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-11-07, 23:42 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
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)


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 02-11-07, 0:34 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
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


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 6:01 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 6:50 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
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):
Image

Wireframe:
Image

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

Result in Celestia. Seam is gone.
Image

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

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


Last edited by dirkpitt on Sat, 03-11-07, 16:06 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 13:47 GMT 
Offline
User avatar

Joined: Sun, 02-09-07, 23:16 GMT
Posts: 126
Location: Upstate NY, USA
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


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 15:32 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
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)


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 15:47 GMT 
Offline
User avatar

Joined: Sun, 02-09-07, 23:16 GMT
Posts: 126
Location: Upstate NY, USA
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


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 03-11-07, 16:08 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 430
Location: South Korea
Good idea, I'll try this out.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 196 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group