Jump to content
The Dark Mod Forums

DarkRadiant 0.10.0 decal transparency issue


Recommended Posts

  • Replies 74
  • Created
  • Last Reply

Top Posters In This Topic

So, any further perspective from development on whether this can be remedied? It seems (from the outside) that it was just something that got busted with the display changes that happened. Was it intentional to remove transparency on textures which are transparent, and if so why; maybe there's some use to it? If a mapper is for instance trying to precisely lay goop on a ledge or textured stone or drain pipe, they can't if they can't see it.

Link to comment
Share on other sites

  • 2 months later...

Any chance of finding a fix for this Orb? It makes it quite difficult to position decals properly now when you can't see the surface behind them.

Link to comment
Share on other sites

I started to try and reproduce this issue, but I get a crash on loading the dr/renderer_test.map. Here is the stacktrace:

 

#0  0x00007ffff1bc94b5 in *__GI_raise (sig=<value optimized out>)
   at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fffe61bb2c0 in scene::SceneGraph::setRoot (this=0xe828b0,
   newRoot=...) at SceneGraph.cpp:43
#2  0x00000000008fabb5 in map::Map::onResourceUnrealise (this=0xcd0460)
   at map/Map.cpp:181
#3  0x00000000008f58b5 in map::MapResource::removeObserver (this=0x550ef80,
   observer=...) at map/MapResource.cpp:176
#4  0x00000000008fb24e in map::Map::freeMap (this=0xcd0460) at map/Map.cpp:276
#5  0x0000000000740667 in ui::MRU::loadMap (this=0xcafe40, fileName=...)
   at ui/mru/MRU.cpp:83
#6  0x000000000073e67b in ui::MRUMenuItem::activate (this=0x4e74530, args=...)
   at ui/mru/MRUMenuItem.cpp:42
#7  0x00000000007458ba in boost::_mfi::mf1<void, ui::MRUMenuItem, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::operator() (
   this=0x4e93ff0, p=0x4e74530, a1=...)
   at /usr/include/boost/bind/mem_fn_template.hpp:162
#8  0x000000000074520f in boost::_bi::list2<boost::_bi::value<ui::MRUMenuItem*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, ui::MRUMenuItem, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list1<std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&> > (
   this=0x4e94000, f=..., a=...) at /usr/include/boost/bind.hpp:292
#9  0x0000000000744e08 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, ui::MRUMenuItem, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list2<boost::_bi::value<ui::MRUMenuItem*>, boost::arg<1> > >::operator()<std::vector<cmd::Argument, std::allocator<cmd::Argument> > > (
   this=0x4e93ff0, a1=...) at /usr/include/boost/bind/bind_template.hpp:47
#10 0x000000000074498c in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, ui::MRUMenuItem, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list2<boost::_bi::value<ui::MRUMenuItem*>, boost::arg<1> > >, void, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::invoke (function_obj_ptr=..., a0=...)
   at /usr/include/boost/function/function_template.hpp:152
#11 0x00007fffe82fd14d in boost::function1<void, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::operator() (this=0x4e93fe8, a0=...)
   at /usr/include/boost/function/function_template.hpp:989
#12 0x00007fffe82fbaa0 in cmd::Command::execute (this=0x4e93fe0, args=...)
   at Command.h:69
#13 0x00007fffe82f8500 in cmd::CommandSystem::executeCommand (this=0xe6dfc0,
   name=..., args=...) at CommandSystem.cpp:339
#14 0x00007fffe82f7e7e in cmd::CommandSystem::execute (this=0xe6dfc0,
   input=...) at CommandSystem.cpp:293
#15 0x00007fffe981318b in Statement::execute (this=0x4f23e60) at Statement.h:28
#16 0x00007fffe980b577 in Command::onMenuItemClicked (menuitem=0x4d7dcd0,
   data=0x4f23e60) at Command.cpp:90
...

 

Greebo, does this make any sense to you? The assertion message is "Scenegraph root already exists".

Link to comment
Share on other sites

My initial analysis is that this will be possible to fix, but not a trivial one-line change. I didn't originally realise but this is relating to the editor preview render mode, not the lighting mode, and my assumption with the editor preview has always been that it is a simple opaque texture render using the qer_editorimage map, with no blending or other effects applied. It should be no problem to enable blending in the preview mode, the only complication is how to detect when the particular qer_editorimage should be blended rather than rendered in the normal fashion.

Link to comment
Share on other sites

Actually there is a quick solution, with a catch.

 

post-254-125961591751_thumb.jpg

 

By enabling GL_BLEND in the editor preview, it is trivial to make the rendered image take account of the alpha channel in the _ed image (which was previously ignored). This is potentially very powerful, since it allows the texture designer full control over exactly which parts of the editor image must be translucent, but it will required that a suitable alpha channel is added to all decal images which should appear translucent in the editor.

 

In my view this is sensible behaviour from DR's perspective (using rather than ignoring the alpha channel in the _ed) image, so I will enable it anyway if there are no objections, the outstanding question is -- is this enough, or is a further analysis of the blend modes required to enabling translucency for existing material defs?

Link to comment
Share on other sites

Hmm, I can't remember if the old renderer did any more than that. Did it actually blend with the texture behind it?

 

In any event, this would be a massive improvement over what is happening currently, and would eliminate the problem with positioning.

Link to comment
Share on other sites

It'd always be good to have a perfect WYSIWYG view, but decals need to be transparent mostly for the sake of seeing the texture behind it, and convenience positioning them.

 

But aren't our _ed images all jpegs without alpha channels?

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

Hmm, I can't remember if the old renderer did any more than that. Did it actually blend with the texture behind it?

 

That's what Dave's screenshot would suggest, 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 or something similar, which I don't like because DECAL_MACRO does not of itself indicate transparency.

 

But aren't our _ed images all jpegs without alpha channels?

 

Yes. It would be necessary to convert any required _ed images to TGA (or possibly DDS, I haven't checked if this works for editor images).

Link to comment
Share on other sites

Yes. It would be necessary to convert any required _ed images to TGA (or possibly DDS, I haven't checked if this works for editor images).

 

Ugh. Lets please use something compressed, like PNG or DDS.

"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

Ugh. Lets please use something compressed, like PNG or DDS.

 

I was going to reply that we don't have the option of PNG because Doom 3 doesn't support it, but then I realised that at this point it is largely irrelevant what Doom 3 supports since it doesn't use the _ed images directly and it would be almost impossible to build a Dark Mod level manually with DoomEdit with all of the advanced stuff we have. If PNG isn't an option at the moment I don't see any real reason why it couldn't be made so (GTK should support it natively).

Link to comment
Share on other sites

I was going to reply that we don't have the option of PNG because Doom 3 doesn't support it, but then I realised that at this point it is largely irrelevant what Doom 3 supports since it doesn't use the _ed images directly and it would be almost impossible to build a Dark Mod level manually with DoomEdit with all of the advanced stuff we have. If PNG isn't an option at the moment I don't see any real reason why it couldn't be made so (GTK should support it natively).

 

I just wanted to avoid that we convert a couple of megabytes (55 if my calculation is correct) to even more megabytes :)

 

(It might also make sense to split up the editor images into their own PK4 so people who don't want to map don't need to download them? probably too late, tho)

"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

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!
      · 1 reply
    • 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...