DarkRadiant 0.10.0 decal transparency issue

[Springheel]

We wouldn't have to convert all the editor images, just the decal ones, correct?

[OrbWeaver]

We wouldn't have to convert all the editor images, just the decal ones, correct?

 

Yes, only ones that needed an alpha channel would need to be converted.

[Springheel]

Hmm, I hadn't really thought carefully about this, but it just occurred to me that most decals do NOT use transparencies. Dirt decals are not transparent. They use a blend filter so that the white areas of the texture essentially reads as transparent, but that's not the same thing. Trying to add an alpha channel to images like that would be a lot of manual work, and could easily distort the edges of the 'dirt area' if done poorly.

 

the only question is how should DR know that the qer_editorimage should be blended? I suspect that the old code was doing some kind of hack with detecting DECAL_MACRO

 

Couldn't that still work? It's a lot easier to add decal_macro to materials that need it rather than adjusting editor images by hand.

[OrbWeaver]

Hmm, I hadn't really thought carefully about this, but it just occurred to me that most decals do NOT use transparencies. Dirt decals are not transparent. They use a blend filter so that the white areas of the texture essentially reads as transparent, but that's not the same thing. Trying to add an alpha channel to images like that would be a lot of manual work, and could easily distort the edges of the 'dirt area' if done poorly.

 

There would certainly be some work involved, but the alpha blend used for preview wouldn't necessarily have to exactly match the rendered decal, provided it gave the mapper a general idea of where to position the patch. For a blend filter decal this could be as simple as inverting a grayscale copy of the image and placing it into the alpha channel.

 

Couldn't that still work? It's a lot easier to add decal_macro to materials that need it rather than adjusting editor images by hand.

 

It's a really nasty hack though, because DECAL_MACRO and transparency are not related, and DECAL_MACRO would not indicate which blend mode to use. A mapper might want to create a decal that is fully opaque, such as a rectangular roadsign that is placed on a wall, and would not want this to be rendered at 50% alpha just because they had added DECAL_MACRO to prevent Z fighting.

 

I can think of some other options though:

 

1. If the material contains only a SINGLE BLEND STAGE, it could be handled differently by applying the single stage's blend mode to the editor image. I suspect this would catch the vast majority of decals.

2. It would be worth testing if we can add our own qer_whatever declarations to a material def, if Doom 3 ignores these then we could add anything we wanted (e.g. "qer_editor_blend").

3. Some decals might use the translucent global keyword, this could be handled as in Doom 3 by automatically selecting a 50% alpha blend, this would also make windows render properly.

[Springheel]

For a blend filter decal this could be as simple as inverting a grayscale copy of the image and placing it into the alpha channel.

 

Oh, partial transparency is possible? I was thinking of D3 all or nothing alpha channels. That would certainly make it less of an issue.

[OrbWeaver]

Oh, partial transparency is possible?

 

Yes, it's exactly the same as using a "blend blend" material.

[greebo]

@OrbWeaver: do you have any ideas about how to fix the depth-sorting bug? It seems that models with alpha-testing stages on them are transparent in the sense that it cancels out everything behind the models too, leaving gaps in the scene.

[OrbWeaver]

Is this in the preview or the full render?

 

From the description that sounds like inappropriate writes to the Z buffer.

[greebo]

It's the preview render, iirc. I'll double-check.

[greebo]

Hm, I can't see the problem anymore. I think it was Fidcal who reported this, but I could swear I saw it once in the past few weeks. Maybe it's already fixed?

 

Anyway, while trying to reproduce it with one of the grave models, I found this:

 

 

The left one is the preview render, which is correctly drawing the alpha-tested plants. But when switching to lighting mode, the alpha test is not executed, it seems?

[OrbWeaver]

The left one is the preview render, which is correctly drawing the alpha-tested plants. But when switching to lighting mode, the alpha test is not executed, it seems?

 

Yes, I am aware of that problem. I think it is because it isn't actually using alpha testing, just alpha blending (which makes alpha-test materials look OK provided they use 0% and 100% alpha); alpha testing would (presumably) stop the pixel shader from running in the transparent areas, while alpha blending has no effect.

 

I did try to get alpha test working at one point, but unsuccessfully. Maybe I will revisit it at some point.

[greebo]

So I assume we leave that for the next version, it's not a big deal for now. I'm planning to release DarkRadiant 1.1.0 this weekend, is this ok for you? Maybe we can provide a .deb package again with this release, people keep asking for that.

[SneaksieDave]

It's this one: http://bugs.angua.at/view.php?id=1918

Demonstrated here: http://forums.thedarkmod.com/topic/9649-darkradiant-0-10-0-decal-transparency-issue/page__view__findpost__p__191695

 

which still occurs at least as of build on 10/6/1:

 

If it worked in the past ( http://forums.thedarkmod.com/topic/9649-darkradiant-0-10-0-decal-transparency-issue/page__view__findpost__p__191695 ) doesn't SVN support showing what the diff was that caused the breakage?

[OrbWeaver]

So I assume we leave that for the next version, it's not a big deal for now. I'm planning to release DarkRadiant 1.1.0 this weekend, is this ok for you? Maybe we can provide a .deb package again with this release, people keep asking for that.

 

Yes, I'm sure I can manage that.

[OrbWeaver]

It's this one: http://bugs.angua.at/view.php?id=1918

Demonstrated here: http://forums.thedarkmod.com/topic/9649-darkradiant-0-10-0-decal-transparency-issue/page__view__findpost__p__191695

 

which still occurs at least as of build on 10/6/1:

 

Weird, that doesn't look like anything to do with alpha test. It appears that the colour of the decal is being inverted for some reason, before the multiplicative blend is applied.

 

If it worked in the past ( http://forums.thedarkmod.com/topic/9649-darkradiant-0-10-0-decal-transparency-issue/page__view__findpost__p__191695 ) doesn't SVN support showing what the diff was that caused the breakage?

 

SVN supports diffs of course, but there have been a lot of changes to the renderer including refactoring and architectural modifications. Finding a single diff the captures the particular bug would be more work than just debugging it in the normal way.

[Fidcal]

Decal transparency revisited

Just to clarify the problems with the new decal transparency. First, the one where all entities behind the decal are made invisible. In this decal patch over a blank banner you can see the banner itself is made invisible behind the patch plus all doors, windows, gargoyles, etc. seen through it. That is a minor inconvenience perhaps but for me worse than no transparency.

 

 

Next, where blend decals that are flush with brush surfaces show at all (intermittent as you can see in the image where virtually all surfaces have the decal but only 2 or 3 show here) they are not transparent anyway (I appreciate this is a different method of transparency and does not include an alpha channel.)

 

Next is the most serious for me because now I have to scroll and scale textures blind (and no way to tell which is vertical and which horizontal except by trial and error) In this first shot all grime decals in place except the surface pointed to by the arrow.

 

I create the decal (brushes filtered out here so it can be seen) but I need to scale it to push the right edge off because in this case I just want grime right in the corner.

 

But when I select it then I can see nothing so have to guess at scaling and keep deselecting. Plus I can't see the brushes which is not necessary here but sometimes helpful.

 

So eventually I get this. This was never easy even before the last change but is more difficult now. Any ideas for making this easier would be welcome.

[OrbWeaver]

Fidcal, are you able to create a test map that illustrates all of these issues and add it into the existing testmaps/dr (maybe maps/test/dr, something like that) directory?

[Fidcal]

Yes, I can cut a piece out of my main map when I can find time.

[greebo]

@OrbWeaver: the windows part of DarkRadiant 1.1.0 is released now, and I've created a tag in SVN: https://darkradiant.svn.sourceforge.net/svnroot/darkradiant/tags/1.1.0

[OrbWeaver]

OK, I will set up my build environment and produce some packages.

[OrbWeaver]

Greebo, I am seeing a rather severe problem in that no brushes are visible in any of the views after loading a map. It looks like the brushes are actually being loaded (from the logfile) but they are no visible.

 

Do you know of any changes that might have caused this issue? Has any of the brush or filter-related code been modified? This must be quite a recent issue since there was no problem the last time I looked at the decal issues.

[OrbWeaver]

Hmm, strange, the problem seems to have disappeared.

[Tels]

Hmm, strange, the problem seems to have disappeared.

 

I had the exactly same problem yesterday, will rebuild today and see if it "vanishes" here too Hopefully, because maps without brushes are kinda boring

[OrbWeaver]

Update: it seems to be a problem only in release builds, not in debug builds. Tels, can you confirm this (configure with and without --enable-debug)?

 

Greebo -- I think I will have to start performing reversions to past revisions to isolate when the bug came in. My initial suspicion is that this might have something to do with the Octree. Are there any significant differences you know about between debug and release builds with respect to octree culling of brushes etc? Do you experience any issues between release and debug on Windows?

[Tels]

Update: it seems to be a problem only in release builds, not in debug builds. Tels, can you confirm this (configure with and without --enable-debug)?

 

I am still building the debug version, but the release build I just pushed on bloodgate.com (unlucky me) contains the bug - invisible brushes.