Models and z-fighting

[Springheel]

I've noticed that some of our models have some serious problems with z-fighting. While they might look fine close up, it seems like when you go further away, the d3 engine moves faces slightly, which means they might start occupying the same space and create sparklies. The doors are a particularly bad example of this.

 

It was brought up before that the doors using the transparent hinges have z-fighting problems at a distance, and this is clear to see in test/propagation map. I've tried every material keyword I can think of on the hinges. Polygonoffset seems to be designed to address exactly this problem, but for some reason it doesn't work for me--it just turns the material black and the z-fighting is still there. I thought turning the texture into a decal might work, but it has the same result.

 

I have noticed this to a lesser degree on other models that use alpha textures...does anyone have any speculation about how to fix it? As it is, I don't think the door models are even useable in this state.

[SneaksieDave]

That was my feeling as well when I first noticed it (posted somewhere around here in an AI distance testing thread). We need some kind of solution for this, because at a distance it looks pretty durn bad.

[OrbWeaver]

While they might look fine close up, it seems like when you go further away, the d3 engine moves faces slightly, which means they might start occupying the same space and create sparklies.

 

This is most likely because of the way the depth is calculated, using a Z buffer of limited precision (normally 24-bit) in such a way that there is much more accuracy at small distances than large ones.

 

This means that even with a very small Z offset to avoid Z fighting, at a distance the numeric inaccuracy might become large enough to cause the rendered depth of the surfaces to start overlapping.

[Tels]

This is most likely because of the way the depth is calculated, using a Z buffer of limited precision (normally 24-bit) in such a way that there is much more accuracy at small distances than large ones.

 

This means that even with a very small Z offset to avoid Z fighting, at a distance the numeric inaccuracy might become large enough to cause the rendered depth of the surfaces to start overlapping.

 

Or in other words, you need to merge both textures into one to create a single texture to completely avoid the effect.

[SneaksieDave]

Hm, good point.

 

I can confirm from back when I was testing window texturing techniques, that using an overlay or decal looked far inferior (mostly due to alphatest chewing up the diffuses at increasing distance) to the method of adding up the surfaces in a single material definition. The latter method would require some changes to be made, but it would probably work fine and not have these problems. The hinge texture is added to the door texture definition, as a whole different skin for the door. Only adds the text size of a material definition.

[Tels]

Hm, good point.

 

I can confirm from back when I was testing window texturing techniques, that using an overlay or decal looked far inferior (mostly due to alphatest chewing up the diffuses at increasing distance) to the method of adding up the surfaces in a single material definition. The latter method would require some changes to be made, but it would probably work fine and not have these problems. The hinge texture is added to the door texture definition, as a whole different skin for the door. Only adds the text size of a material definition.

 

Yeah, but creating a complete texture from wood+hinge means you need a new texture for every combination - which can be a lot.

 

But would it possible for D3 to create that texture on the fly upon loading the map?

[Springheel]

The hinge texture is added to the door texture definition, as a whole different skin for the door. Only adds the text size of a material definition.

 

Not sure I understand what you're suggesting. At the moment, the door model is broken into 3 parts, the door, the hinges (which are just a couple polys floating in front of the door model) and the handle mount (which works the same as the hinges).

 

The benefit is that you can then mix and match door and hinge textures to create a wide variety of doors.

 

Sounds like you're saying we should get rid of the separate polys for the hinges. But how does that work? Can a single material shader have two diffusemaps?

 

This is most likely because of the way the depth is calculated, using a Z buffer of limited precision (normally 24-bit) in such a way that there is much more accuracy at small distances than large ones.

 

One thing I didn't try was maskDepth: "The maskDepth stage keyword stops the current stage from writing to the depth buffer." Not sure if that would help.

[SneaksieDave]

Yeah, but creating a complete texture from wood+hinge means you need a new texture for every combination - which can be a lot.

But it's only text. A few extra kb of text is quite worth the problems it solves.

 

Not sure I understand what you're suggesting....Can a single material shader have two diffusemaps?

Yep. Basically, use blend/adding in the material to add the hinges to the door material. One material entry per door/hinge combo. More text definitions, of course, but no z-fighting/alphatest issues. I assume the door models might need updating to support this (the UV mapping).

 

 

Edit: Here's an example window (reminds me I still have to upload this, so at least the method isn't lost):

 

textures/darkmod/window/sd/window1
{
 qer_editorimage	textures/darkmod/window/pebbly_glass_noframe01_lit
 noshadows
 twosided
 translucent
 glass
 forceoverlays
 sort decal

 bumpmap textures/darkmod/sd/window1_local
 {
	  blend diffusemap
	  map textures/darkmod/sd/window1
 }
 {
	  maskColor
	  map invertAlpha( textures/darkmod/sd/window1 )
 }
 {
	  blend gl_dst_alpha, gl_one
	  map textures/darkmod/window/pebbly_glass_noframe01_lit
	  red 1
	  green 1
	  blue 1
	  alphaTest 0.7
 }
}

 

I don't know for sure if the inverted alpha would be necessary for door hinges; might just be able to paint it right over(?). Regardless of distance, this window does not have problems with the wood frame. By contrast, the same window using decals looks jaggy and eventually fails completely (the frame degrades and vanishes), with distance.

[Tels]

But it's only text. A few extra kb of text is quite worth the problems it solves.

 

yes, sorry, I was assuming we were talking about fusing the diffusemaps in Gimp7photoshop

[SneaksieDave]

Oh goodness no! I'm already getting very concerned about the overall mod size, and we haven't even done voices yet.

[Springheel]

Yep. Basically, use blend/adding in the material to add the hinges to the door material.

 

So you can have one diffusemap and then use another blend diffusemap? Are you sure? I was pretty sure I tried to do this with some AI skins and it didn't work.

[SneaksieDave]

See my edits to the post above, where a sample material for a window is laid out. It wasn't my knowledge; someone else figured out how to do it (maybe rebb? I can't recall, it was a few months ago). But it should work for this the same. For the window there is the glass texture, and the frame. The frame is used twice; once to produce an inverted alpha, and once to draw itself. Both diffuses contribute to the final material, which is frame and glass, or in the case of this need, door and hinges, locks, etc. Should work, and looks good, no probs.

 

All that above comes with a big disclaimer of "at least, that's how I think it works." The proof is in the screenshot.

 

Edit: For contrast, here is the same window, but using the frame as a decal. Looks jaggy upclose, and completely degrades at a distance (due to alphatest; I don't know if that's related to z-fighting at all, but it gives similar bad behavior).

[Tels]

See my edits to the post above, where a sample material for a window is laid out. It wasn't my knowledge; someone else figured out how to do it (maybe rebb? I can't recall, it was a few months ago). But it should work for this the same. For the window there is the glass texture, and the frame. The frame is used twice; once to produce an inverted alpha, and once to draw itself. Both diffuses contribute to the final material, which is frame and glass, or in the case of this need, door and hinges, locks, etc. Should work, and looks good, no probs.

 

Agreed, my "milky glass" uses similiar techniques. I am not sure if the inverted alpha is really nec. if the "frame" (or hinge) is an texture with an alphachannel, it should be blended properly atop without that.

 

But we can simple try it.

[Springheel]

I'll test this, though it looks to me like the window bars have no colour data, and are just using a modular blend. Also, with this method it seems to be that the hinges would be unable to have either bumpmap or specular data.

[SneaksieDave]

Closeup below; it's wood grain, just a crappy test texture (the reason I never uploaded it). It also demonstrates normalmap, but I believe only on the base texture (the frame). The glass is thus bump/specular-less, if I remember correctly, so yes that represents some problem. There might still be a way to add them (addnormals? greebo and angua know about that) but we stopped before discovering it.

[Springheel]

I can't find the textures in question...is there really a textures/darkmod/sd folder?

 

My own experiments aren't really going anywhere, so I need to see what the originals look like.

[SneaksieDave]

As mentioned, they haven't been uploaded at this time. I'll put them up, even if just in a /test type of capacity though.

[SneaksieDave]

Uploaded to SVN. See test_window.mtr, and folder textures/test_window for the files and the editor location of the material itself.

[Baddcog]

Obviously decals aren't the way to go.

 

If we could just blend the hinge onto the door that wouldn't be bad, but they do need normals and spec. Just being flat won't cut it, up close they will look like crap. The normal maps are the only reason I did the hinge poly thing in the first place, because they can be believable with normals.

 

I never got around to looking at them at a distance, from the map I was using them in the distances were fair and I never noticed it. (bc_manor.map) Basically a large courtyard.

I am also a bit hesitant to move the hinge polys further from the door. Right now they are very close, they probably can be spaced out a bit more and be fine. I'll try and get on that. But there will be a point where close up they will have a 'floating effect' if they get too far away from the door. (when a player can see pixels behind them)

[Springheel]

Yeah, I don't think this method would work well for doors. However, it WOULD work very well for something I was trying to do before--AI skins. Imagine AIs with bare tunics, and then several different designs that could be overlayed on top for the cost of a skin entry.

 

Having said that, I'm still not having any luck getting it to work. The original diffusemap just winds up being transparent, which is the same problem I had the last time I tried it.

[Springheel]

Ok, here's the material I'm using:

 

bc_doorface03_test  // testing double diffusemaps
{
	noshadows
 twosided
 translucent
 forceoverlays
 sort decal
wood

bumpmap	 textures/darkmod/wood/boards/worn_01_local

{blend diffusemap
map  models/darkmod/props/textures/bc_hinge01
}


{	maskColor
	  map invertAlpha( models/darkmod/props/textures/bc_hinge01 )
 }

{	blend gl_dst_alpha, gl_one
map   textures/darkmod/wood/boards/worn_01_ed
red 1
	  green 1
	  blue 1
	  alphaTest 0.7

}

}

 

To me it looks exactly the same as the window example, but the hinge part just shows up as black in game:

[SneaksieDave]

Hm. It might just be the wrong combination of gl_ settings. I had trouble wrapping my head around that before, despite people trying to explain it. Maybe we can find something in the window thread:

http://forums.thedarkmod.com/index.php?s=&am...st&p=148796

[Tels]

Ok, here's the material I'm using:

 

That looks in the wrong order to me. First you draw the hinge, then you make an alphachannel to mask the hinge, then draw the boards on it.

 

Why not start with the wood board and simple blend the hinge onto it?

[Springheel]

Why not start with the wood board and simple blend the hinge onto it?

 

That's not the way the example window does it.

 

It starts with the transparent image (the frame), then creates a mask that is the opposite of that image, then blends in the nontransparent image (the glass).

 

I'm doing the same thing, but for some reason the transparent image is showing up black.

 

I've looked through the window thread, and as far as I can see I'm doing everything the same way. The only bit I didn't understand was this:

An interesting thing is that the color of the clear areas on the frame affects the glass result. At first, the alpha sections were white, and as such the glass was very bright when a local light source struck it. I then tried black, and local light sources then had no effect on the glass! I settled for somewhere in between, so there is some effect but not too much.

 

But that doesn't sound like it would cause the result I'm having.

 

I have no real idea of what "gl_dst_alpha, gl_one" means. I know the first bit says to use the alpha mask, but what does gl_one mean? And I've seen the order flipped in some shaders; does that matter?

[greebo]

I have no real idea of what "gl_dst_alpha, gl_one" means. I know the first bit says to use the alpha mask, but what does gl_one mean? And I've seen the order flipped in some shaders; does that matter?

The order does indeed matter. The first word refers to the source image pixel, the second one to the destination pixel:

blend srcBlend, dstBlend

refers to

result = [sourcePixel * (srcBlend)] + [destinationPixel * (dstBlend)]

 

The blend expression you have is gl_dst_alpha, gl_one, which means:

"Multiply the image pixel with the alpha channel of the screen pixel and add the screen pixel (multiplied by 1)."

 

The result modifies the screen image by adding the texture pixel (the one defined in the map of that stage) multiplied with the screen's alpha channel.

 

In other words:

resulting pixel = existing pixel + existing alpha channel*texture pixel

 

So, the resulting image should be brighter than it was before the blend operation, if I get this right.