Something wrong with "fit" on decals?

[Springheel]

I'm not sure if this is an error or if I just have something set up wrong. I was placing some dirt decals, and noticed that if I used the "fit" texture command, the texture looks like it is offset by a few pixels. The image below shows an example--there is a black line at the top edge of the decal (which should be completely transparent) . It's as if the whole texture has been shifted down one pixel.

 

Any idea what might be causing that? Are other people seeing the same?

[grayman]

There are several decals that paint this way, and it's been that way for as long as I can remember.

 

I always thought it had something to do with antialiasing on the original image that somehow gets translated into edge artifacts.

[Springheel]

Hmm, I've looked at the original image up close and I can't see anything dark along the top edge.

[grayman]

If you extract the original from the DDS file, can you see it?

[Springheel]

I can't see it when I open the dds file in Photoshop, no.

 

[Bikerdude]

I wonder if this is the same thing Ive been complaining about for ages now, and that is the way decals draw over the top of something thats in front of the decal when the player gets far enough away.

[Springheel]

No, this is from DR. It has nothing to do with sorting.

[rich_is_bored]

I think it's a combination of texture filtering and tiling. The bottom of the texture is bleeding over to the top. Assuming DR respects the material as defined in it's declaration, this problem would be present in TDM too.

[Springheel]

The bottom of the texture is bleeding over to the top

 

That's what it looks like, but when you "fit" a texture, it's not supposed to do that.

[rich_is_bored]

I'm not talking about how the texture is mapped. I'm talking about how the texture is filtered. To clarify...

 

 

Here we have Quake 2 running in software mode. No texture filtering takes place. The pixels in each texture are easily identifiable. Now jump ahead to 3m59s. Here it's running in hardware mode. The textures are blurry. The color values are not simply sampled from the nearest pixel within the texture. They are interpolated.

[grayman]

DR's exchanging the top and bottom rows of the image?

 

Here's one of the slime5 decals:

 

 

And here's the bottom of the decal:

 

 

And here's the top of the decal:

 

 

We wouldn't see this result with row shifting, only from exchanging.

[grayman]

Here's what DR writes to the map file for the decal (after cleaning up the floating point screwiness):

 

patchDef3

{

"textures/darkmod/decals/dirt/dripping_slime05"

( 3 3 1 1 0 0 0 )

(

( ( 128 128 -40 0 0 ) ( 128 128 12 0 -0.5 ) ( 128 128 64 0 -1 ) )

( ( 128 32 -40 -0.5 0 ) ( 128 32 12 -0.5 -0.5 ) ( 128 32 64 -0.5 -1 ) )

( ( 128 -64 -40 -1 0 ) ( 128 -64 12 -1 -0.5 ) ( 128 -64 64 -1 -1 ) )

)

}

 

 

I can't find the patchDef3 format on the web. Who knows how to interpret this? The 0.5s and 1s look dodgy.)

[AluminumHaste]

* a patchdef is

 

 

Code:

{

patchDef2

{

"texturepath"

patchparams2

(

list of patchcoldefs

)

}

}

 

or alternately

Code:

{

patchDef3

{

"texturepath"

patchparams3

(

list of patchcoldefs

)

}

}

 

 

 

* a patchparams2 is

Code:

( #cols #rows junk junk junk )

 

where "junk" is an integer that is ignored.

 

 

* a patchparams3 is

Code:

( #cols #rows #horiz-subdivisions #vert-subdivisions junk junk junk )

 

where "junk" is an integer that is ignored

[grayman]

( #cols #rows #horiz-subdivisions #vert-subdivisions junk junk junk )

 

Okay, that explains the (3 3 1 1 0 0 0) bit, but what about the rest?

[AluminumHaste]

Oh sorry forgot the rest of the post.

 

a patchcoldef is

Code:

( list of controlpoints )

 

* a controlpoint is

Code:

( x y z s t )

 

where x y z are the spatial coordinates of the point, and s t control the texturemapping in ye olde biquadratic Bezier fashion.

[AluminumHaste]

Got it from here: http://www.quake3world.com/forum/viewtopic.php?f=10&t=42879&view=previous

[grayman]

When using the plaster texture instead of the dirt decal, the map file has this:

 

patchDef3

{

"textures/darkmod/plaster/framed_01"

( 3 3 1 1 0 0 0 )

(

( ( 128 128 -40 0 0 ) ( 128 128 12 0 -0.5 ) ( 128 128 64 0 -1 ) )

( ( 128 32 -40 -0.5 0 ) ( 128 32 12 -0.5 -0.5 ) ( 128 32 64 -0.5 -1 ) )

( ( 128 -64 -40 -1 0 ) ( 128 -64 12 -1 -0.5 ) ( 128 -64 64 -1 -1 ) )

)

}

 

which has the same numbers in the description.

 

So at first blush it doesn't appear that DR is writing something wrong to the map file.

[AluminumHaste]

Is it possible that during saves and opening that decimal drift (1 -> 1.00000000000001 or 1 -> 0.99999999991 etc) cause the game to round to nearest and turning it into -1 instead of 0?

[grayman]

What we're seeing is a blending of the top pixel row with the bottom pixel row, which makes sense for tiled textures (because that's what you'd want to happen at the transition edge).

 

So in my pics above, the top and bottom rows appear to be exchanged because the dark top row has blended with the transparent bottom row, making it lighter, and the transparent bottom row has blended with the dark top row, making it darker.

 

I made a texture with a single pixel red line across the top and a single pixel green line across the bottom.

 

Here's what it looks like in DR when they meet:

 

 

You might be able to see the sort of yellow blended line between the red and green bands.

 

Here's what it looks like at the top (notice the presence of the blended yellow line):

 

 

and the bottom (notice the presence of the blended yellow line):

 

[AluminumHaste]

Yeah I see the blending of green and red.

[grayman]

So when any texture is painted on a face and 1x1 fitted, all four edges are exhibiting the effect.

 

For non-decal textures, we prolly aren't going to notice the effect.

 

But for decal textures with alpha channels, we might see it, depending on what the image is doing at the edges.

[grayman]

The only solution I can see is to turn off blending in the horizontal direction if the texture is 1xN fit on the face from left to right.

 

And turn off blending in the vertical direction if the texture is Nx1 fit on the face from top to bottom.

 

If that's possible, then the OP 1x1 dirt decal would not show blending at any of the four edges.

[SteveL]

Would alphazeroclamp help for the decals? It makes the edges (1 pixel width) perfectly transparent.

[grayman]

Only if it's used for Nx1, 1XN, and 1x1 fittings, and only on the edges corresponding the to "1" setting.

 

We'd want to see tiling (and blending) on the edges corresponding to the "N" setting.

[Springheel]

Why is blending even necessary? Tiling textures should already be designed to blend seamlessly.