Decals and blending problems

[SneaksieDave]

I've just discovered that the materials for the ivy pieces mikebart made were set up wrong (by me). I tried to use one, and noticed that it had z-fighting with the wall upon which it was placed. Okay, no prob, I am quite sure there is a one line fix for this, as I've seen all of greebo and angua's decals. I look it up, and sure enough: decal_macro. I add that line, and the ivy pops out of the wall, no longer z-fighting. Yay! However, now the ivy is black (yes, just like yesterday with windows (still not completely resolved, and part of the reason I took this up; wanted to try decal frames) a long line of trying things is beginning). I try a bunch of stuff and then it occurs to me: aren't all of the grime decals black? Shit, I think, maybe decal_macro only allows for black/filter type of decals. Then I remember blood, and look it up in D3, and they have it working; blood decals on top, and with color. So I'm back to being confused. I change the ivy from diffusemap to filter to add (add works, but it becomes unlit/fullbright -- no good). Other than these things I've tried, the material definition is identical to the ones working for id blood. It isn't the specular. It isn't the normalmap. It isn't the frob stages. I don't know what the hell it is.

 

Any idea what I'm missing? I'm now plowing back into the unfriendly world of gl_ones and gl_one_minus_src_colors. I don't know if I'm just not understanding their use correctly or what, but that wasn't worked out yesterday either, so the very same wheels are spinning. If it requires the same fix rebb demonstrated with the window frame yesterday, why don't the id blood textures need the same?

 

To throw even more confusion into the mix, I looked at one other type of decal we have, spiderwebs. The webs, to my extreme confusion, work without either a translucent keyword or an alpha channel, at all! (?) Despite that success though, they still have a problem in that they are fullbright, even in total darkness, so they'll need fixing as well.

 

So basically, we have implementation and consistency issues, some decals work while others don't under the same rules, some have problems needing fixing, and everything's set up differently. I guess the question is, what is the correct way to do this, because it appears we don't yet know.

 

Works without z-fighting:

textures/darkmod/decals/dirt/dripping_slime03
{
  qer_editorimage textures/darkmod/decals/dirt/dripping_slime03
  DECAL_MACRO
  noShadows
  noimpact
  nonsolid

  {
  blend filter
  map textures/darkmod/decals/dirt/dripping_slime03
  }
}

 

Works without z-fighting, but uses a different blend; should it have color?:

textures/darkmod/decals/dirt/dripping_slime05
{
  qer_editorimage textures/darkmod/decals/dirt/dripping_slime05
  DECAL_MACRO
  noShadows
  noimpact
  nonsolid

  {
  blend 	gl_zero,gl_one_minus_src_color
  map textures/darkmod/decals/dirt/dripping_slime05
  colored
  }
}

 

Works, no z-fighting, and in color (id software):

textures/decals/blood_drip1
{
qer_editorimage		textures/decals/blood_drip1
translucent
decal_macro
{
	blend			filter
	map				textures/decals/blood_drip1
	translate		1,time*-0.1
}
{
	blend			filter
	map				textures/decals/blood_drip1a
	translate		1,time*-0.02
}
}

 

Works without z-fighting, but is fullbright:

textures/darkmod/decals/webs/spiderweb_corner1
{
DECAL_MACRO
twosided
noshadows
nonsolid
noimpact

qer_editorimage textures/darkmod/decals/webs/spiderweb_corner1

  {
  blend add
  map textures/darkmod/decals/webs/spiderweb_corner1
  }
}

 

Does not work (choose between black, or z-fighting):

textures/darkmod/decals/vegetation/ivy_mixed_pieces
{
DECAL_MACRO

qer_editorimage textures/darkmod/decals/vegetation/ivy_mixed_pieces_ed

{	   
 blend	[filter, or (gl_zero, gl_one_minus_src_color), or (still trying things)...]
 map	textures/darkmod/decals/vegetation/ivy_mixed_pieces
 alphaTest 0.1
}
}

 

Edit: image added for the heck of it

[Tels]

Works without z-fighting, but uses a different blend; should it have color?:

textures/darkmod/decals/dirt/dripping_slime05
{
  qer_editorimage textures/darkmod/decals/dirt/dripping_slime05
  DECAL_MACRO
  noShadows
  noimpact
  nonsolid

  {
  blend 	gl_zero,gl_one_minus_src_color
  map textures/darkmod/decals/dirt/dripping_slime05
  colored
  }
}

 

"colored" means basically:

 

red parm0

green parm1

blue parm2

 

However, these parameters are set by the _color spawnarg of an entity and default to zero, which means, it defaults to black. So you need to turn whatever uses that material into an entity and give it that spawnarg to colorize it.

 

With the rest, sorry, not yet enough coffee to help you.

[Springheel]

I made the spider webs, and used the blend filter because the spider webs are on a black background. The webs lighten everything behind them, but yes, it means they aren't affected by lighting.

 

As for the rest, I'm not sure why you're getting that result. I don't know what the ivy image looks like, but if it's actually transparent, can't you just use a blend diffusemap?

[SneaksieDave]

The ivy (as on SVN) is set up with a blend diffusemap. This has the problem of z-fighting when it is flush with the wall. This sucks, because DR creates decals very conveniently for the user, in that fashion -- the dirt decals, black in nature, work fine. The ivy, though, is turned black by using decal_macro.

 

I've tried diffusemap, filter, add, and even a handful of blind fumbling with gl_* values. To summarize the problems for the sake of encouraging and facilitating ease of assistance (I realize the first post is rambling):

 

1. some decals are made with decal_macro (this fixes z-fighting issues), and work fine, as they are black (our dirt, smut, etc)

 

2. some decals are color though; using decal_macro is so far turning them black. Not sure if this is a result of the macro, or simply a poor blend definition (our ivy)

 

3. some decals work both with color and decal_macro (id blood). It is not yet clear why.

 

4. some decals have detailed alpha channels (pagan lettering, ivy)

 

5. some decals have single color (white) alpha channels (our dirts, the id blood -- a clue maybe?)

 

6. some decals have no alpha channels, and still work (our webs)

 

 

Questions resulting:

 

1. should a decal but used flush with a surface, ever? DR supports this with a helpful decal command, so it would suck if not. However, it seems this is supported, and decal_macro takes care of the sorting. But then, why is it having trouble on the ivy? why is decal_macro screwing up the color for some, but not others?

 

2. should decals have a detailed (ivy), or flat alpha channel (blood)? should they have an alpha channel at all (webs)?

 

3. if it's necessary, what is the correct method for getting lighting to work on these, regardless of macro or alpha channels? hopefully this is not the invert alpha command, as that is adding extra stages to every such material.

 

The id blood encompasses the whole thing, and is neat and tidy. It works flush with the wall. It has color, it has no z-fighting. Maybe it's the alpha channel. Hm...

[rebb]

Why not just offset the patch/brush that has the ivy Texture by a small amount in the editor ?

As it was already said in another thread, polygonOffset ( which is also part of DECAL_MACRO ) breaks materials that are supposed to be shaded by lighting.

Check some of the Doom3 maps, all the decals which are not based on a special blendmode are offset by a small amount.

 

Edit :

Maybe DR could include an extra function that lets you offset a decal by a certain amount ?

[Springheel]

. some decals are made with decal_macro (this fixes z-fighting issues), and work fine, as they are black (our dirt, smut, etc)

 

Can't you just use decal_macro and leave it as blend_diffuse? You shouldn't have to change the blend mode to add that keyword.

[SneaksieDave]

I just went in and created a new version of the ivy with a flat white alpha channel. It changes nothing. It goes right back to the original case where we can use blend diffusemap and get z-fighting, or use decal_macro and turn everything black. In fact, another thing figured out: the translucent stage is not key to the id blood working, because when I use it with my new ivy, it still suffers z-fighting, but simply becomes transparent.

 

So the question remains: what is different about the id blood, in that it has both color, and no z-fighting.

 

Why not just offset the patch/brush that has the ivy Texture by a small amount in the editor ?

This can certainly be done as workaround (that's what I thought was necessary back when I originally set up the materials). Manually of course, and maybe in the editor (would need greebo's input on that). But the question remains as above. Is it necessary? Or are we simply doing something wrong? I wish we could figure out what, and fix it, rather than rely on unnecessary workarounds.

 

Check some of the Doom3 maps, all the decals which are not based on a special blendmode are offset by a small amount.

Sigh, that is troubling then. But why does the blood look fine? (image below)

 

Can't you just use decal_macro and leave it as blend_diffuse? You shouldn't have to change the blend mode to add that keyword.

No, that gives the black result. See image below for each of these items.

[rebb]

The id blood is looking fine because it is using a special blendmode, it "multiplies" with the background. Afaik, such Material Stages don't write to the depth-buffer and thus can't cause z-fighting.

 

Ivy on the other hand can't just be multiplied to the background or use a "blend blend", because it has to react to lighting to look convincing ( imo ).

 

Edit : Actually, regarding my first statement, i think the main problem is just DECAL_MACRO. The blood is probably also using the depth buffer - if one would remove DECAL_MACRO from it, it would probably z-fight as well.

 

I guess we will only know why polygonOffset breaks the lighting on something once the full Doom3 SourceCode is released.

 

There was a thread somewhere about the Door-Models and their Hinges showing some visual artifact when viewed from a distance, and there polygonOffset also broke the lighting when used.

[SneaksieDave]

Multiply (filter) definitely still z-fights. Well, at least this is narrowing it down. Looks like two possibilities/choices at this point:

 

1. We're doing it wrong, or,

2. Users will need to offset decals (manually or programmatically), for some decals (adding confusion and user error to the mix).

 

 

@greebo: any thoughts on the placement of decal patches?

[greebo]

@greebo: any thoughts on the placement of decal patches?

I haven't followed this thread very closely. Are you referring to rebb's suggestion about a decal offset? That's moderately easy to accomplish, I reckon.

[SneaksieDave]

Cool, it appears it might be necessary. If id are using offsets in their maps, there truly might be no other way, for some decals. The reasons for which and why will haunt my sleep, but that's beside the point.

[greebo]

You can add that feature to the tracker, maybe I get around to do it soon. Gosh, I guess I will need a second life or something to do all that coding I'd like to do with DarkRadiant and the mod.

[Crispy]

I investigated this exact issue some time ago (for vine arrows) and concluded that it wasn't possible with current Doom 3 functionality. Either you use blend modes or polygon offsets, in which case the decal doesn't properly react to lighting, or you get Z-fighting.

 

I may be wrong, but I don't believe that the placement of decals is 100% controllable via SDK code. At least, if you place them dynamically, then their initial position is determined inside renderer functions which aren't in the SDK. It may be possible to move them after the fact, but I didn't find any such functionality at that time.

[SneaksieDave]

Tried out windowframes as decals. It works, but also with a pro/con result. Pro: it allows for the glass to retain its own normals and specs (still ongoing though: if anyone (Gil?) knows of a way to have that in the combined setup but only where the glass is drawn, please say so). Con: it suffers from jaggies, I guess because the "edges" are drawn at the alphatested spots, where as in a combined material, the ugliness is hidden within the texture. Anyway, it works pretty good, with the tradeoff. And it doesn't hurt for us to include both, as it's only a material entry.

 

---

 

On a related note, I've worked out a system to fix the spiderwebs problem. That system is, "copy what id software did." For reasons I don't quite understand, you can have the diffuse be a grey/white web on a black background, and have the alpha channel be completely white, and for whatever reason, with the right material definition, it works to give transparency and proper lighting.

 

Images below: unlit (showing old fullbright version), lit (with normals and specular, yay!), and close up detail.

[SneaksieDave]

*trumpets*

 

Now presenting: the upgraded TDM family of webs (not yet on SVN), all fully supporting lighting, and with normalmapping and specularity (three stages from same file):

[Springheel]

Definitely a good thing that light affects them. The bumpmap might be a bit strong on a few of them, making the strands look rather thick. But an improvement overall.

[Fidcal]

*trumpets*

 

Now presenting: the upgraded TDM family of webs (not yet on SVN), all fully supporting lighting, and with normalmapping and specularity (three stages from same file):

Looking forward to seeing this Sneaksie. Any time this morning. No pressure.

[greebo]

Yes, the cobwebs look really cool, these should be used to spice up our gathers map. Well done, can I see the material?

[SneaksieDave]

Sure here's a sample one (it's from id)

 

textures/darkmod/sd/testweb_spiderweb_round2
{
translucent
noshadows
twosided
nonsolid
sort	5
bumpmap			heightmap (textures/darkmod/sd/webs/spiderweb_round2_fixed.tga, 2)
diffusemap		textures/darkmod/sd/webs/spiderweb_round2_fixed.tga
{
	blend		specularmap	
	map			textures/darkmod/sd/webs/spiderweb_round2_fixed.tga
	red			.25
	green		.25
	blue		.2
}
}

 

They've got an entire (big) file devoted to shader demos we could probably benefit a lot from by dissecting. Too bad they trimmed out many of the supporting images.

 

I should have these up today. I'm also going to include reference/copies to the few id ones, so they're all in one convenient spot for the user. We could still use more of course, but it'll be a decent number at that point (around 10 I think).

 

This just got me thinking... controlling transparency level with shaderParms? Hm...

[Tels]

This just got me thinking... controlling transparency level with shaderParms? Hm...

 

Should be easy done with "alpha parm11" or something. Especially useful if used with sine or random tables.

 

For instance, my "pulsating crystals" slowly change the color in a small range so they apear to "pulse".

 

blue parm2 * (0.2 + 0.1 * sintable[ time * .1 ])

...

 

I think it must work with transparency, too.

[Springheel]

Sure here's a sample one (it's from id)

 

Which are the ones from id? When I made the ones in the decal folder I thought there weren't any useable ones in the D3 default files.

[SneaksieDave]

Which are the ones from id?

There were some in the decals mtr, some test ones lying around buried, and one with monsters.

 

I think it must work with transparency, too.

Interesting, might have to look into that. I guess another cool mod would be to use them either on jointed sheets, so they could gently wave when brushed against. And maybe even a very subtle heat haze effect to simulate them waving..........

 

 

The new versions are now up on SVN. Gave the announce its own thread, since this one wasn't originally about webs. http://forums.thedarkmod.com/index.php?showtopic=7593

[Fidcal]

The webs are much improved now but a bit thick. I'm trying to produce another spider web a lot finer. I've handdrawn this one (seen here from different angles.) I've done this dusty cobweb version or a plain spiderweb version. Still not certain it's exactly right yet though. It is really difficult to capture that real gossamer, cobwebby feel in all lighting. If you make the dust to bright then it shines unnaturally in the dark. I've added lengthy outer spokes to make it easier to place without clipping the main web into a wall. My original is 2048 x 2048 with single pixel web softened to 3 pixels wide. It can easily be thickened more. I'm keeping that for maybe a very large solid patch for a big spider to sit on. This one here is reduced to 1024 x 1024. Well, there are a couple in the corner but they are the same texture.

[SneaksieDave]

Just to clarify: the webs are the same diffuse images they were before. You can r_skipbump 0 to compare with and without bumpmapping. They're no thicker, in fact the bumpmapping gives them roundness (darkening the edges), so they're actually narrower. It gives them a "3D appearance" in essence. And, there's nothing preventing use from having "_nobump" versions, since it's just another few lines of text.

 

Anyway, by all means, we can always use more, and the one you've got going there looks great.

[Domarius]

It is really difficult to capture that real gossamer, cobwebby feel in all lighting.

I guess you could always resort to making two different versions - for light and dark areas.