DarkRadiant 0.10.0 decal transparency issue

[jdude]

I just downloaded the latest version and this occurs in the 3d view:

This does not occur any of the previous versions I've worked with.

[greebo]

Well, you've been away a while, it seems. That behaviour is correct as far as the editor preview goes, OrbWeaver's recent renderer changes make decals appear that way.

[Mortem Desino]

I've just either used the decal filter or added my own "grime" filter in DR.

[jdude]

Is it possible to change it to how it was before? I actually prefer having the decals transparent so that I can view how they look on the ground. (ps: Yes I've been gone way to long )

[SneaksieDave]

I hadn't noticed that (haven't used decals much). If that is indeed the case, that the old way is on the left and the new is on the right, that definitely doesn't seem correct or useful. Any further info on this before considering it officially a problem?

[jdude]

I think it would be useful if you could toggle it on and off but having it stuck on makes it hard to imagine what it will look like.

[SneaksieDave]

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.

[greebo]

I can't answer your questions - we have to wait for OrbWeaver's input, he was the one who refactored that part of the code.

[jdude]

Well for now I can easily just use an older version of DR so no big worries

[SneaksieDave]

Before this is forgotten, I'll track an entry.

http://bugs.angua.at/view.php?id=1918

[OrbWeaver]

That's definitely a bug, there is no way decals are supposed to look like that. I thought that blend modes (including multiply) were now working, so this must be a regression of some sort.

[Springheel]

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.

[OrbWeaver]

I can maybe try to make time to have a look at this if it is causing people problems, obviously I've been out of the loop for a while but perhaps it is something reasonably simple to fix.

[jdude]

Personally it causes me issues I'd love to see it fixed.

[OrbWeaver]

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".

[greebo]

I just removed that assertion, it should be ok again.

[OrbWeaver]

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.

[OrbWeaver]

Actually there is a quick solution, with a catch.

 

 

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?

[Springheel]

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.

[Mortem Desino]

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?

[OrbWeaver]

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).

[Tels]

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.

[OrbWeaver]

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).

[Tels]

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)

[Mortem Desino]

(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)

There are people who don't want to map ??!!