Models and z-fighting

[Springheel]

That's where I start getting lost, because I don't have any real sense of what "resulting pixel = existing pixel + existing alpha channel*texture pixel" means. It's like talking about numbers in the billions.

 

All I really want to do is create a mask out of a transparent image, and then have a different image display only in the shape of the mask.

 

I'm pretty sure this part:

 

{blend diffusemap

map models/darkmod/props/textures/bc_hinge01

}

 

 

{ maskColor

map invertAlpha( models/darkmod/props/textures/bc_hinge01 )

}

 

Takes the transparent hinge image and makes an inverted alpha out of it, so that there is a transparent hole the shape of the hinge. Then, the next image (the boards) is supposed to use that alpha and display with that hinge-shaped transparency, which allows us to see the hinge through the boards.

 

Everything seems to work, except either:

 

1. The hinge shape is not transparent, it is black

 

2. The hinge shape IS transparent, but the texture behind it is black.

[Baddcog]

I'm not at home so I can't test but i wonder if another approach might be better.

 

Obviously it's not using the alpha and the pixels from one image very well.

 

Spring, could you take the alpha layer from the hinge and just use it as a black and white image as the alpha image.

 

Then use the metal hinge tex as the blend map.

------------------------

 

another thought, I'm wondering why you are using 'inverted alpha'. The alpha map from the hinge shouldn't need inverted (ie: black and white swap places?) Can you just use

map Alpha( models/darkmod/props/textures/bc_hinge01 )

 

--------This is on modwiki---sort order--i wonder if using close or almost nearest would help the hinges stay in front of door. Maybe even medium as the only issue with them is at distance.

 

Sort (Material global keyword)

From modwiki

Jump to: navigation, search

Description

Changes the "screen layer" a material is drawn in. This global keyword is mainly used to correct issues with transparent materials.

 

Such issues become clear when one material furthest away from the viewer is still drawn on top of a transparent material which is closer in distance. Modifying the sorting order resolves this by changing the order in which materials are drawn on the screen.

 

Usage

In the global section of your material shader type...

 

sort <order>

Parameters

<order> - Defines in which "layer" the material should be when sorted.

Order types

subview

Always drawn first with any other material drawn on top.

opaque

Default sort order for opaque textures.

decal

Obviously used for decals. (Default for transparant textures?)

far

medium

close

almostNearest

The above 4 orders still leave room to shuffle materials around when materials draw on top of each other. (Some of these could be used in common model materials)

nearest

Used for gun flares and other stuff very close to the player.

postProcess

Highest layer, normally only used for postProcess materials and programs.

[SneaksieDave]

If what BC's saying doesn't work out, could it be about the source image? Perhaps it needs and lacks an alpha stage?

 

*doesn't understand this shit... grabbing at straws*

[Domarius]

You know how other games avoid this? LODing. Pity Doom 3 doesn't support it.

[Crispy]

You know how other games avoid this? LODing. Pity Doom 3 doesn't support it.

Weren't we talking about implementing a level-of-detail algorithm? Did that ever get done?

[Tels]

Weren't we talking about implementing a level-of-detail algorithm? Did that ever get done?

 

I don't think LOD would help here. The texture for the door and the hinge are currently overlayed on top of each other and this is what causes the z-fight. No LOD on the model (not done) or the single textures (done with mipmaps anyway) is going to change that.

[Crispy]

Ah, but it could if you used it cleverly enough.

 

Consider the current situation. When you're near the door, everything is fine. There's no visible gap between the hinge and the door, so it doesn't look weird. But when you're far from the door, there isn't enough gap between the hinge and the door compared to the distance between the door and the camera, and you get Z-fighting. (Remember that the Z buffer is floating point, which is why the relative distances matter. The Z-fighting only occurs in this case when the distance between the door and the hinge gets rounded to 0 due to floating point error.)

 

This can easily be fixed simply by moving the hinge further away from the door. But then you'll notice the gap when you're near the door, which is baaad!

 

Solution: Two door models. One, the "near model", is the current door model that we have now. The other, the "far model" is almost exactly the same; the only difference is that the hinge has been moved further away from the door. Now use LOD to switch between the near and far models depending on the player's distance from the door. When you're near the door, the "near model" will be used and everything will look peachy (as is the case now). When you're far from the door, the "far model" takes over. You don't notice the gap between the hinge and the door because you're so far away; and, even better, because there is a gap, you don't see any Z-fighting. Problem solved.

 

That's my interpretation of Domarius's remark anyway.

[SneaksieDave]

I was looking at this again a short while ago. Notice that when the problem starts, the hinges show big white swaths. Why is that? Is that the background color of the hinge diffuse? Can it be transparent, and maybe this wouldn't be (so much) a problem?

 

That is, unless there's an update (BC's suggestion or alpha problem or whatever)?

[Tels]

Ah, but it could if you used it cleverly enough.

 

Yeah,when all you have is LOD, every problem looks like it can be solved with LOD

 

Just kidding, yes, that could work, but is probably not what he had in mind

[Crispy]

I was looking at this again a short while ago. Notice that when the problem starts, the hinges show big white swaths. Why is that?

That is a really good question. Weird.

 

Yeah,when all you have is LOD, every problem looks like it can be solved with LOD

 

Just kidding, yes, that could work, but is probably not what he had in mind

Without Domarius elaborating, you can't possibly know exactly what he meant.

 

Seriously - it's a viable method, it would be really easy to do with LOD (which people already want for other reasons anyway), it would solve the problem, so what exactly is the issue here?

[Springheel]

I was looking at this again a short while ago. Notice that when the problem starts, the hinges show big white swaths. Why is that?

 

That area is transparent on the diffusemap. Maybe not the normalmap though...can't see why that would make a difference, but it would be an easy thing to try.

 

It doesn't seem to matter if the diffuse is transparent or not for z-fighting, however. I've had transparent textures cause z-fighting even without a normalmap.

[SneaksieDave]

Well, the weird thing to me is: I'm backing way up so it starts, then using FOV to change the zoom so I can look from a distance... and to my eyes, the hinge itself (the black scrawling) doesn't seem to be z-fighting at all. The part that I'm seeing flicker and dither is the big white band. So if that, whatever it is, were gone, it might not be an issue. I'll make a movie, those usually help.

 

http://72.8.59.188/TheDarkMod/temp/zfight.wmv

 

Notice that even when the white bands are flitting in and out, the hinges and lockplate stay consistent. Maybe the solution lies in that.

 

baddcog, would you understand why it's white perhaps?

[Springheel]

The white band is part of the same texture as the hinge. It's just one big rectangle, with everything but the hinge being transparent.

[SneaksieDave]

Okay, I checked it out in PS and yep that's the case. I'm not really very knowledgeable about this stuff, but can't an image exist with no color information on those spots? So, in an editor, only the hinge would look as it does, and the rest would be that pink/white checkerboard pattern indicating no color info? I couldn't get that to work because it insists on at least the background layer having something there. But this raises a question:

 

If a model existed of just the hinge and 'hinge area', minus the door, how would it look? My bet is, like the hinge, floating in space, no white. Why the hell does this white barge through then, and at what point? Does it appear all at once, or fade in (no evidence of this), or dither in, or...? This makes no sense.

 

Edit: hm, so is it the alpha channel failing at certain distances, allowing the background to show through (?) Is it true precedent exists in Doom3 assets (suggesting this cannot be fixed easily).

[Springheel]

can't an image exist with no color information on those spots? So, in an editor, only the hinge would look as it does, and the rest would be that pink/white checkerboard pattern indicating no color info?

 

That is how it looks when I open it in PS.

 

If a model existed of just the hinge and 'hinge area', minus the door, how would it look? My bet is, like the hinge, floating in space, no white. Why the hell does this white barge through then, and at what point?

 

It's not only the transparent areas that have z-fighting, is it? I didn't look very closely, but I didn't think that was the case. If so, it's...interesting, though possibly coincidental. One easy way to test would be to point the shader in the .ase file at a different texture (like a flat colour) and see what happens.

[Crispy]

can't an image exist with no color information on those spots?

No. For image formats with a full alpha channel (such as the texture format which Doom 3 uses), every pixel has an R, G, B and A value. Even if the A value is 0, which means you won't normally be able to see the RGB values, those RGB values do exist.

 

Many image programs (Photoshop!) will hide this information from you, but there is always some colour lurking in there if you ignore the alpha channel.

 

Just looked at bc_hinge01.tga, and yes, it does indeed have "invisible" white colour in most of the transparent bits. There are some non-white pixels which are entirely transparent, but they are in the minority.

 

As a minor alleviation, we could replace all of that white colour with something less blindingly obvious (wooden brown, grey, black...) but that wouldn't solve the problem of course.

[SneaksieDave]

So then it sounds like (pardon if I'm repeating stuff already known, just trying to keep it straight):

 

1. at distance, alpha transparency fails. Thus, the white 'invisible' part of the image starts to show/z-fight

2. one possible solution is to actually change the models, moving the hinge and lockplate strips out a bit

3. another possible solution (hasn't worked yet, but should, according to working window materials) is to add the diffuses together in the material

[Springheel]

1 is not correct. It's not that the transparency fails, it's just that at a distance the hinge texture tries to occupy the same space as the door texture, causing z-fighting.

 

2&3 are true as far as I can tell.

[rebb]

I just tested how it behaves with a black background instead of white in the .tga file, and it does help the more obvious white flickering - the black doesn't show up instead. Not sure what is going on there but it helps a bit.

 

It doesn't fix the actualy problem tho, as the actual hinge-parts still flicker with distance, just makes it less apparent.

[Tels]

I just tested how it behaves with a black background instead of white in the .tga file, and it does help the more obvious white flickering - the black doesn't show up instead. Not sure what is going on there but it helps a bit.

 

It doesn't fix the actualy problem tho, as the actual hinge-parts still flicker with distance, just makes it less apparent.

 

That should be done as a first stop-gap measure, tho

[SneaksieDave]

it's just that at a distance the hinge texture tries to occupy the same space as the door texture, causing z-fighting.

Why doesn't that happen with the hinge itself, close up? The hinge (metal) and the alpha space (white) is the same image. So why, close up, do we see hinge only, but at a distance, hinge + alpha? That's why I'm thinking alpha transparency is what's failing at a distance. Close up, the "cutout" works, but far away, it fails.

 

Edit: I'm not wording that well. What I mean is: if close up, we see hinge and not alpha (it's invisible), and they're at the same space, then why far away, does alpha suddenly become visible? It's the same conditions.

 

Edit: Wait, maybe I get it... at a distance, z is starting to get rounding errors or lose precision or whatever a mathematician would say. So the surfaces are merging. Okay. BUT, that still doesn't explain why the white suddenly appears. Without a z-offset close up, you wouldn't see the white either. Why? Because it's invisible. At distance, it becomes visible for some reason.

 

the actual hinge-parts still flicker with distance

Now I'm even more confused. My video above shows the hinge (metal) not flickering. The hinge and lockplate stay consistent; only the white alpha crap flickers in and out.

[rebb]

Yeah the depth-buffer is less precise with increasing distance, that's why Z-Fighting occurs on distant objects in a lot of Games, especially older ones.

 

Why it's showing the white of the diffusemap is a mystery to me too, and if you look really closely, it seems to do some weird blending with the door, revealing more of the door's wood where the diffuse-texture has darker color values. Just odd.

[Tels]

Yeah the depth-buffer is less precise with increasing distance, that's why Z-Fighting occurs on distant objects in a lot of Games, especially older ones.

 

Why it's showing the white of the diffusemap is a mystery to me too, and if you look really closely, it seems to do some weird blending with the door, revealing more of the door's wood where the diffuse-texture has darker color values. Just odd.

 

My guess would be that the alpha test fails, so the hinge is (partly, decided on a per-pixel basis, thats why you get the flickering) blended on top of the door.

 

Where there are hinge-colored pixels, you get a mix of "door+hinge", which you don't really see, as the hinge is dark.

 

Where there are white-colored pixels, you get a mix of "door+white", which you do see quite good.

 

However, I am quite unsure why the alphatest would fail. The alphatest should not play a role at all. The z-buffer stores _distances_ so that pixels that are behind other pixels are not rendered at all. If the z-buffer test fails,you wouldn't see white parts, you still would see transparent parts of the hinge (but no door part).

 

The transparent part of hinge could always be rendered on top of the door, because it is transparent, anyway. This is a mystery to me...

 

Can somebody please point me to a shader that combines a door and a hinge?

[SneaksieDave]

My guess would be that the alpha test fails

This is my guess too, though the only backing I have is that when I was doing the window + frame stuff, using alphatest, the frame degrades very badly with distance (shown here in this thread). It does not show the white/alpha areas through, which is troubling/different, but it (alphatest) became unusable with distance; no decal window frames.

 

@Tels, I don't know of anything on SVN which is door+hinge (maybe SH does) but here's the window+frame:

/textures/test_window/window1 , in

test_window.mtr

[Crispy]

Yeah, I don't understand what the deal is with the white parts of the diffuse channel showing through. As far as I know that's not normal Z-fighting behaviour. Really odd.

 

Still, perhaps we could at least try fixing the Z-fighting and seeing what happens.