Jump to content
The Dark Mod Forums

DarkRadiant 0.10.0 decal transparency issue


Recommended Posts

I've now committed test\darkrad_transparency.map

 

All 6 brush surfaces covered in the blend grime decal. Difficult to see or select without filtering out brushes. And their texture is invisible when the patch is selected so cannot see to scroll/size.

 

The decal on the banner has an alpha channel and renders the banner behind it invisible. Strangely, the door and cart behind are not invisible but the gargoyle is. So clearly it affects some models and not others.

Link to comment
Share on other sites

  • Replies 74
  • Created
  • Last Reply

Top Posters In This Topic

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?

I don't see anything like that in Windows, I've been using both debug and release builds for weeks now. Why would the linux build behave differently, I wonder?

 

Sounds like a severe issue, I can only offer to switch to Linux, but I don't have any good IDE there, only text files, so I don't exactly know how to start debugging that. Eclipse didn't work at all for me last time I tried months ago.

Link to comment
Share on other sites

I don't even bother with Eclipse anymore, just using GVim + Ctags works much better. I suspect this will be more of an "add print statements" type of debug, since nothing is actually crashing, but I'm not sure where to start because the scenegraph has changed so much.

 

I have been trying to revert to previous revisions to find one that works, but a lot of them have other problems, probably because in the past when I have updated the Linux build I have failed to test in release mode as well as debug. Potentially this bug could have been in place for some time.

Link to comment
Share on other sites

I compiled a release build in Linux now and while I can create brushes just fine, they seem to be missing when I load an existing map, so I can reproduce that. Let's see whether I can figure out how to set a breakpoint here.

Link to comment
Share on other sites

It seems the brush nodes are corrupted right after loading the map. There are some ridiculously high values in RenderableWireFrame::m_size, which smells like uninitialised variables, but I need to look further.

Link to comment
Share on other sites

Ok, I could narrow it down to an error caused by compiler optimisations in Plane3_applyTranslation() - that's also the reason why it doesn't occur in debug builds. I'm not fully sure why this is, but I'll figure it out eventually. Fact is that the Plane3 members can severly messed up during assignment, and maybe the evil reinterpret_cast in Plane3::normal() is causing that.

Link to comment
Share on other sites

Yup, a workaround fix is in SVN now, the brushes are showing up again.

 

The reason can be found somewhere along the lines of the Plane3::normal() method, which is brute-force casting the Plane3 class (whose members are four doubles) onto a BasicVector3 class (with a double[3] member array). Gcc emits a warning here, but in principle it works, just not in this specific case (Plane3_applyTranslation).

 

After changing:

return Plane3(tmp.normal(), -tmp.dist());

to this:

return Plane3(tmp.a, tmp.b, tmp.c, -tmp.d);

and therefore using a different Plane3 constructor, the assignment in FacePlane::updateTranslated() is working again. I assume the problem is happening somewhere in the Plane3 constructor, which is "dereferencing the type-punned pointer" and "breaking strict anti-aliasing rules".

 

The whole reinterpret_cast in Plane3::normal() should be replaced with a proper implementation of equal speed, which probably resolves that issue. Right now it cannot be guaranteed that this problem won't happen again in the future in similar situations.

Link to comment
Share on other sites

Excellent, glad you figured it out. I've always been very disapproving of those reinterpret_cast based mechanisms, but this is the first piece of solid evidence I've seen that it is actually harmful.

 

I'll check the latest build on Linux and produce the packages if everything is OK.

Link to comment
Share on other sites

Excellent, glad you figured it out. I've always been very disapproving of those reinterpret_cast based mechanisms, but this is the first piece of solid evidence I've seen that it is actually harmful.

 

I'll check the latest build on Linux and produce the packages if everything is OK.

 

Already done, both work on my PC and laptop and are already on bloodgate.com since several hours, sorry couldn't post earlier, we had to rush out to meet friends.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Just to make sure I'm not more confused than I think I am: this wasn't about a fix for decal transparency?

 

No, this was about the latest release build not working on linux - it lost all brushes when loading a map due to a compiler optimization going wrong.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I've noticed with the recently released 1.1 that the Ivy bits are invisible in the model viewer. This may or may not be related to this thread.

 

My apology for this post. The newest version of DR, 1.1, filters things actively rather than passively as the previous versions had so it's my mistake. (so if you add a model with models filtered it goes invisible)

Link to comment
Share on other sites

Already done, both work on my PC and laptop and are already on bloodgate.com since several hours, sorry couldn't post earlier, we had to rush out to meet friends.

 

I noticed the Karmic ones were already there so I didn't upload. I will have to investigate the previous builds since when I tried yesterday there were some problems with build dependencies.

Link to comment
Share on other sites

  • 3 months later...

Any chance for a revisit on this one? http://bugs.angua.at/view.php?id=1918

 

(The decal problems indicated in the first two pages, not the later linux compile issue or whatever it was.)

 

Since it worked at one point, one could hope at least that change history would reveal what got busted. It's true there's render mode for decal placement, but it's not always ideal for editing (and as I understand it, some don't have it... plus it has its own issues needing TLC).

Link to comment
Share on other sites

Well I have achieved at least partial success.

 

alphatest.png

 

This works by applying the "alphatest" value of the first diffuse layer to the editor image, although in this case the editor image IS the diffusemap; this probably not work if there was a separate qer_editorimage without an alpha channel.

 

Those dirt overlays are still wrong of course, and I'll bet there are many decals that this change doesn't solve, but it's a start.

Link to comment
Share on other sites

I have enabled blend modes for editor preview images (if there is no diffuse layer, it will use the blend information from the first blend layer), but there is some weirdness in Fidcal's test map:

 

dff3bd.jpg

 

The blend mode specified is:

 

blend gl_zero,gl_one_minus_src_color

 

which as far as I can see is exactly what DarkRadiant is rendering here, but surely the dirt decals are supposed to be the other way round (darker in the corners, lighter in the center)?

 

Is this just a problem with the particular material, or am I handling it wrong in some way?

Link to comment
Share on other sites

  • 4 weeks later...

This should behave a bit better now in SVN. This is how DarkRadiant currently draw in lighting mode (editor mode is almost the same):

 

default_blends.png

 

- The grime decals are drawn correctly (I couldn't reproduce the problem you had, OrbWeaver, maybe it got fixed along the way?)

- The blend stages are now writing to the depth buffer again, they are not transparent anymore (both lighting and editor mode)

- The default blend stages (à la map textures/blah/rock without explicit blend keyword - defaulting to gl_one, gl_zero) are recognised correctly

- The blood splat decals have their polygon offset applied in lighting mode (were invisible before)

Link to comment
Share on other sites

- The grime decals are drawn correctly (I couldn't reproduce the problem you had, OrbWeaver, maybe it got fixed along the way?)

 

Perhaps my SVN was out of date or something. In any case, your image shows this working correctly, so I am pretty confident that the fix was right.

 

- The blend stages are now writing to the depth buffer again, they are not transparent anymore (both lighting and editor mode)

 

I don't know if you saw my post in the public thread about this yet, but surely blend materials are not supposed to write to the depth buffer because they might be transparent? Or does this not matter because they are sorted after all of the non-blended geometry anyway?

 

- The default blend stages (à la map textures/blah/rock without explicit blend keyword - defaulting to gl_one, gl_zero) are recognised correctly

- The blood splat decals have their polygon offset applied in lighting mode (were invisible before)

 

Those both sound like good fixes to me. I never got as far as testing polygon offset in lighting mode, because I couldn't get alphaTest to work for the decal I was testing. I was assuming that alphaTest should "just work" by turning off the shader for the non-rendered pixels, but maybe the alpha needs to be specifically handled in the shader instead or something.

Link to comment
Share on other sites

I don't know if you saw my post in the public thread about this yet, but surely blend materials are not supposed to write to the depth buffer because they might be transparent? Or does this not matter because they are sorted after all of the non-blended geometry anyway?

I didn't read your post - though I was thinking along the same lines: should blend layers write to the depth buffer or not. I figured it's not a problem if they do, because they are supposed to write on top of "solid" diffusemap materials anyway. I could make out these cases:

 

- Diffusemap stage behind Blend material: the blend material can write to the depthbuffer because there is nothing to block the view anyway - it's in front and the fragments blend.

- Diffusemap stage in front of Blend material: the blend material is hidden behind the diffusemap - the blend layer can write to the depthbuffer, the viewer cannot see it.

- Blend material in front of blend material: I seem to recall that Doom 3 has issues with that too (draw order?), so I figured this is not a problem for DarkRadiant at the moment.

 

Finally, the simple map stage without explicit blend keywords defaults to gl_one, gl_zero in Doom 3 (I made a small testmap). It's not the same as a diffusemap stage, as it doesn't react to lighting, but it's still respecting the depth of the geometry, so I figured it should in fact write to the depth buffer.

 

This is how I came to that conclusion, but maybe I am thinking too naively?

Link to comment
Share on other sites

- Diffusemap stage behind Blend material: the blend material can write to the depthbuffer because there is nothing to block the view anyway - it's in front and the fragments blend.

 

Provided that the blend materials are drawn after the diffusemap materials (which they should be), I think this should work fine. If the blend material was drawn first, the part of the diffusemap material that was behind the blend material would not be drawn.

 

- Diffusemap stage in front of Blend material: the blend material is hidden behind the diffusemap - the blend layer can write to the depthbuffer, the viewer cannot see it.

 

Yes, this should be no problem at all, the diffusemap material will pass the depth test and obscure the blend material behind.

 

- Blend material in front of blend material: I seem to recall that Doom 3 has issues with that too (draw order?), so I figured this is not a problem for DarkRadiant at the moment.

 

Yes, this would be the only time problems would occur I think. But if Doom 3 also has the same problems, it should indeed be fine (preferable in fact).

 

Finally, the simple map stage without explicit blend keywords defaults to gl_one, gl_zero in Doom 3 (I made a small testmap). It's not the same as a diffusemap stage, as it doesn't react to lighting, but it's still respecting the depth of the geometry, so I figured it should in fact write to the depth buffer.

 

This sound absolutely right to me, the "no blend map-only" stage is a simple decal/replace operation.

 

Am I thinking too naively?

 

No, I think your solution is probably correct. At any rate you have probably tested with more maps than I did, so you would probably have seen any problems if there were any.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...