Jump to content
The Dark Mod Forums

Recommended Posts

Posted (edited)

Tested "5757 Feature: Ability to center 3D camera on selected entity". Worked well and as expected. A peripheral problem seen; see testing notes under https://bugs.thedarkmod.com/view.php?id=5757

Also, "5905: Improvement: Safeguard warning against Loss of Layering" was fine; note at https://bugs.thedarkmod.com/view.php?id=5905

Similarly good: "Improvement: Entity Inspector: classname field should always be read-only, to force use of the "Choose entity class" button";  https://bugs.thedarkmod.com/view.php?id=5910

Finally, "Improvement: UI tweaks for worldspawn-to-entity conversion" was nice in 2 cases, but needs work in a 3rd case. See note under  https://bugs.thedarkmod.com/view.php?id=5822

Edited by Geep
Added 5822 mention
  • Thanks 1
Posted

Shadow Mapping!   interaction shader code?!

Things just keep gettin' better  😎

Yer the nicest func_mover I've ever met.

Posted

Initial source merged on Linux. Renderer changes look great. Shadows are working, and it's nice to see what look like more game-correct colours (I wonder what we were doing wrong in the previous shaders which made the colours and brightness different, although I suspect the answer lies in some mathematical detail that I would struggle to understand).

The new shadow toggle button confused me though, because it looks like another option in the existing set of "radio buttons" which control the render mode, but this is a separate toggle which is independent of the other buttons. I would suggest making it mutually exclusive for consistency with the others — we could save space by getting rid of the untextured all-white solid mode, which I'm pretty sure is completely useless for most mapping tasks (I suspect that the wireframe one is occasionally useful for some people, although only in specific situations).

There are some post merge segfaults in unit tests which I need to investigate to determine if they are Linux specific or caused by some merge conflict.

  • Like 1
Posted
10 hours ago, OrbWeaver said:

The new shadow toggle button confused me though, because it looks like another option in the existing set of "radio buttons" which control the render mode, but this is a separate toggle which is independent of the other buttons. I would suggest making it mutually exclusive for consistency with the others — we could save space by getting rid of the untextured all-white solid mode, which I'm pretty sure is completely useless for most mapping tasks (I suspect that the wireframe one is occasionally useful for some people, although only in specific situations).

Agreed, sounds reasonable.

  • Like 1
Posted

The Linux segfault is definitely not merge related, since I can reproduce it in your branch prior to the merge commit. It looks like a problem with OpenGL being called during shutdown (maybe after the context has been destroyed or invalidated?). Here is the stacktrace:

Spoiler
    frame #0: 0x0000000000000000
  * frame #1: 0x00007ffff4d65c6a libradiantcore.so`render::BufferObjectProvider::BufferObject::~BufferObject(this=0x0000555555df91f0) at BufferObjectProvider.h:31:28
    frame #2: 0x00007ffff4d86910 libradiantcore.so`void __gnu_cxx::new_allocator<render::BufferObjectProvider::BufferObject>::destroy<render::BufferObjectProvider::BufferObject>(this=0x0000555555df91f0, __p=0x0000555555df91f0) at new_allocator.h:152:4
    frame #3: 0x00007ffff4d866c7 libradiantcore.so`void std::allocator_traits<std::allocator<render::BufferObjectProvider::BufferObject> >::destroy<render::BufferObjectProvider::BufferObject>(__a=0x0000555555df91f0, __p=0x0000555555df91f0) at alloc_traits.h:496:4
    frame #4: 0x00007ffff4d8621f libradiantcore.so`std::_Sp_counted_ptr_inplace<render::BufferObjectProvider::BufferObject, std::allocator<render::BufferObjectProvider::BufferObject>, (__gnu_cxx::_Lock_policy)2>::_M_dispose(this=0x0000555555df91e0) at shared_ptr_base.h:557:35
    frame #5: 0x00005555556ca814 drtest`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release(this=0x0000555555df91e0) at shared_ptr_base.h:155:6
    frame #6: 0x00005555556c6197 drtest`std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count(this=0x0000555555df8108) at shared_ptr_base.h:730:4
    frame #7: 0x00007ffff4d2f518 libradiantcore.so`std::__shared_ptr<render::IBufferObject, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr(this=0x0000555555df8100) at shared_ptr_base.h:1169:7
    frame #8: 0x00007ffff4d2f538 libradiantcore.so`std::shared_ptr<render::IBufferObject>::~shared_ptr(this=0x0000555555df8100) at shared_ptr.h:103:11
    frame #9: 0x00007ffff4d7b654 libradiantcore.so`render::GeometryStore::FrameBuffer::~FrameBuffer(this=0x0000555555df7f90) at GeometryStore.h:28:12
    frame #10: 0x00007ffff4d7b6b5 libradiantcore.so`void std::_Destroy<render::GeometryStore::FrameBuffer>(__pointer=0x0000555555df7f90) at stl_construct.h:98:7
    frame #11: 0x00007ffff4d76fca libradiantcore.so`void std::_Destroy_aux<false>::__destroy<render::GeometryStore::FrameBuffer*>(__first=0x0000555555df7f90, __last=0x0000555555df8458) at stl_construct.h:108:19
    frame #12: 0x00007ffff4d71136 libradiantcore.so`void std::_Destroy<render::GeometryStore::FrameBuffer*>(__first=0x0000555555df7f90, __last=0x0000555555df8458) at stl_construct.h:137:11
    frame #13: 0x00007ffff4d6c581 libradiantcore.so`void std::_Destroy<render::GeometryStore::FrameBuffer*, render::GeometryStore::FrameBuffer>(__first=0x0000555555df7f90, __last=0x0000555555df8458, (null)=0x0000555555dd5680) at stl_construct.h:206:15
    frame #14: 0x00007ffff4d6892d libradiantcore.so`std::vector<render::GeometryStore::FrameBuffer, std::allocator<render::GeometryStore::FrameBuffer> >::~vector(this=0x0000555555dd5680) at stl_vector.h:677:15
    frame #15: 0x00007ffff4d67594 libradiantcore.so`render::GeometryStore::~GeometryStore(this=0x0000555555dd5678) at GeometryStore.h:11:7
    frame #16: 0x00007ffff4d615ea libradiantcore.so`render::OpenGLRenderSystem::~OpenGLRenderSystem(this=0x0000555555dd5500) at OpenGLRenderSystem.cpp:70:41
    frame #17: 0x00007ffff4d86744 libradiantcore.so`void __gnu_cxx::new_allocator<render::OpenGLRenderSystem>::destroy<render::OpenGLRenderSystem>(this=0x0000555555dd5500, __p=0x0000555555dd5500) at new_allocator.h:152:4
    frame #18: 0x00007ffff4d86517 libradiantcore.so`void std::allocator_traits<std::allocator<render::OpenGLRenderSystem> >::destroy<render::OpenGLRenderSystem>(__a=0x0000555555dd5500, __p=0x0000555555dd5500) at alloc_traits.h:496:4
    frame #19: 0x00007ffff4d857ff libradiantcore.so`std::_Sp_counted_ptr_inplace<render::OpenGLRenderSystem, std::allocator<render::OpenGLRenderSystem>, (__gnu_cxx::_Lock_policy)2>::_M_dispose(this=0x0000555555dd54f0) at shared_ptr_base.h:557:35
    frame #20: 0x00005555556ca814 drtest`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release(this=0x0000555555dd54f0) at shared_ptr_base.h:155:6
    frame #21: 0x00005555556c6197 drtest`std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count(this=0x00005555560498a8) at shared_ptr_base.h:730:4
    frame #22: 0x00005555556c1ece drtest`std::__shared_ptr<RegisterableModule, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr(this=0x00005555560498a0) at shared_ptr_base.h:1169:7
    frame #23: 0x00005555556c1eee drtest`std::shared_ptr<RegisterableModule>::~shared_ptr(this=0x00005555560498a0) at shared_ptr.h:103:11
    frame #24: 0x00007ffff4ca4230 libradiantcore.so`std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >::~pair(this=0x0000555556049880) at stl_pair.h:208:12
    frame #25: 0x00007ffff4ca7486 libradiantcore.so`void __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::destroy<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >(this=0x00007fffffffdbc0, __p=0x0000555556049880) at new_allocator.h:152:4
    frame #26: 0x00007ffff4ca71ef libradiantcore.so`void std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > > >::destroy<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >(__a=0x00007fffffffdbc0, __p=0x0000555556049880) at alloc_traits.h:496:4
    frame #27: 0x00007ffff4ca6b17 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_destroy_node(this=0x00007fffffffdbc0, __p=0x0000555556049860) at stl_tree.h:642:24
    frame #28: 0x00007ffff4ca59c7 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_drop_node(this=0x00007fffffffdbc0, __p=0x0000555556049860) at stl_tree.h:650:2
    frame #29: 0x00007ffff4ca4b7c libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_erase(this=0x00007fffffffdbc0, __x=0x0000555556049860) at stl_tree.h:1920:4
    frame #30: 0x00007ffff4ca4b59 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_erase(this=0x00007fffffffdbc0, __x=0x0000555555df1510) at stl_tree.h:1918:4
    frame #31: 0x00007ffff4ca4b59 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_erase(this=0x00007fffffffdbc0, __x=0x0000555556085750) at stl_tree.h:1918:4
    frame #32: 0x00007ffff4ca4b59 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::_M_erase(this=0x00007fffffffdbc0, __x=0x0000555555e27a50) at stl_tree.h:1918:4
    frame #33: 0x00007ffff4ca4cd4 libradiantcore.so`std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::clear(this=0x00007fffffffdbc0) at stl_tree.h:1271:2
    frame #34: 0x00007ffff4ca4518 libradiantcore.so`std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::shared_ptr<RegisterableModule>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<RegisterableModule> > > >::clear(this=0x00007fffffffdbc0) at stl_map.h:1133:9
    frame #35: 0x00007ffff4ca23ef libradiantcore.so`module::ModuleRegistry::unloadModules(this=0x0000555555df1360) at ModuleRegistry.cpp:47:15
    frame #36: 0x00007ffff4ca3792 libradiantcore.so`module::ModuleRegistry::shutdownModules(this=0x0000555555df1360) at ModuleRegistry.cpp:216:15
    frame #37: 0x00005555556c1b89 drtest`test::RadiantTest::TearDown(this=0x0000555555ddad50) at RadiantTest.h:129:49
    frame #38: 0x0000555555b32f21 drtest`void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) [inlined] void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(location=<unavailable>, method=<unavailable>, object=<unavailable>)(), char const*) at gtest.cc:2433:27
    frame #39: 0x0000555555b32f1a drtest`void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(object=<unavailable>, method=<unavailable>, location="TearDown()")(), char const*) at gtest.cc:2469
    frame #40: 0x0000555555b27f55 drtest`testing::TestInfo::Run() at gtest.cc:2684:14
    frame #41: 0x0000555555b27f40 drtest`testing::TestInfo::Run(this=0x0000555555d85d70) at gtest.cc:2657
    frame #42: 0x0000555555b2803d drtest`testing::TestSuite::Run() at gtest.cc:2816:31
    frame #43: 0x0000555555b27fa2 drtest`testing::TestSuite::Run(this=0x0000555555d85ed0) at gtest.cc:2795
    frame #44: 0x0000555555b2855c drtest`testing::internal::UnitTestImpl::RunAllTests(this=0x0000555555d85120) at gtest.cc:5338:47
    frame #45: 0x0000555555d71d40 drtest
    frame #46: 0x0000555555b16630 drtest at gtest.cc:5036:1

 

The actual line which crashes is:

-> 31  	            glDeleteBuffers(1, &_buffer);

which then jumps to address 0x0000, which I think can only mean that the glDeleteBuffers function pointer itself has been set to null.

My first thought was that headless OpenGL simply won't work on Linux, but this doesn't really make sense as an explanation because the crash happens in an OpenGL call during shutdown, which must have been preceded by several other calls (which did not crash) during initialisation and running the tests. Also there is a HeadlessOpenGLContextModule which has been used by tests for 18 months without crashing, so it can't be the case that no OpenGL commands work in tests.

I'm guessing this must be something related to the order of destruction of some of the new rendering-related objects (as commented within the OpenGLRenderSystem destructor), but I'm not sufficiently up to speed on how the new objects fit together to identify an obvious root cause.

Posted

Yes, it's the GL buffers being destroyed too late during shutdown. They are held by the GeometryStore and this one has to be destroyed in shutdownModule(), I assume. Can you file a bug entry, please? I'm going to fix it over the weekend.

Posted

Sure, I'll create a bug for it.

I did try turning the _geometryStore member into a unique_ptr and explicitly resetting it in shutdownModule(), but this did not solve the problem. However it's possible I did not do it in the correct order with respect to other members which need to be cleaned up.

I also noticed that there is a potential race condition during the shutdownModule calls themselves, because we don't actually take dependencies or initialisation order into account during shutdown — we just shut down modules in the order they appear in the _initialisedModules map (which I guess is alphabetical). This was causing my HeadlessOpenGLModule to be shutdown before the OpenGLShaderSystem which I was convinced was the cause of the problem... but even fixing this did not help.

  • Like 1
  • Thanks 1
Posted

This is really exciting.

I gave it a decent whirl and noticed that only some lights seem to work, or lights aren't as big as in-game.  I tested this on Doom3 marscity1 and it's not as bright as it should be.  I also noticed that any material with a filter stage or additive stage will z-fight with itself, although filters and adds seem to render well on their own.  Cubemap reflections seem completely absent.  Alphatest works fine but alphablend seems always broken.  I did try it with latest TDM to be sure, and while I'm not as familiar,. it did seem to display the same behaviour.

This was on a GTX660.

Posted

The brightness and the z-fighting problems seem to be something to look into. It's entirely possible that projected lights aren't working at all, I spent time on point lights only.

Cubemap reflections have never worked in DR so far, the GLSL code in the cubemap shader code is lacking the reflection part. But I saw it in the TDM shaders, I think this is not too hard to get it working in DR.

What are alphablend materials?

Generally, I'd appreciate test maps or test PK4s and/or bug tracker entries, this increases the chances of these things getting fixed.

Posted
1 hour ago, greebo said:

What are alphablend materials?

Is like the translucent materials, those that blend with background using a alpha value, not a black&white alpha mask. 

"perforated" materials = alpha test.

translucent materials = alpha blend.

Posted

I confirmed my new loot counter script still works and dropped it into Github so it'll ship with the final release.  I'll be spending some decent mapping time this weekend on Linux, so I'll keep up with the master branch and be able to test any additional fixes.

  • Thanks 1
Posted

Projected lights seem to work fine and cast shadows.
I also noticed that the 'common/shadow' materials don't cast shadows.  This doesn't explain why maps loaded wholesale seem darker, as if every second light is missing.  If anything they should be brighter with more light.
I also noticed that alphatested materials cast shadows of their alphas.  This is really cool, despite not being engine-accurate?  At least, I don't remember vanilla Doom3 being able to do this.  Again, it would explain brighter results, not darker.
'No_diffuse' flag on lights doesn't seem to work, nor does 'no_specular' or 'parallel', but I don't recall ever using those anyway.
It's possible that parallel lights were used a lot and they are now just rendering as projected lights and not "filling-out" as much as they otherwise would?  Just a guess.

I think someone who is very intimate with TDM is going to need to do A-B comparison tests with this.  I used Doom3 and by now I'm even a bit fuzzy on how that's supposed to look, given that it came out nearly 20 years ago now.

 

Posted

@OrbWeaver  unit tests should be working again in Linux, at least they're not immediately crashing anymore.

21 minutes ago, LDAsh said:

I also noticed that the 'common/shadow' materials don't cast shadows.  This doesn't explain why maps loaded wholesale seem darker, as if every second light is missing.  If anything they should be brighter with more light.
I also noticed that alphatested materials cast shadows of their alphas.  This is really cool, despite not being engine-accurate?  At least, I don't remember vanilla Doom3 being able to do this.  Again, it would explain brighter results, not darker.
'No_diffuse' flag on lights doesn't seem to work, nor does 'no_specular' or 'parallel', but I don't recall ever using those anyway.
It's possible that parallel lights were used a lot and they are now just rendering as projected lights and not "filling-out" as much as they otherwise would?  Just a guess.

There's a lot of features that DR doesn't support yet. I added shadows, but that's not the same as supporting all the possible material keywords, there's a lot of ground to cover here.

Shadow mapping != stencil shadows. Vanilla Doom 3 is using stencil shadows, which is operating on object silhouettes only, if I'm not mistaken, therefore no alpha-tested shadows. I didn't want to port two shadow rendering modes, so I settled for shadow mapping, which do support alpha-tested materials. Doesn't mean it's impossible to implement stencil shadows at some point, since TDM can do both simultaneously.

At least it's nice to hear that projected lights are even working, I haven't tested them and would have assumed that they were entirely broken.

I have no clue yet about the lights being too dim or even missing, maybe there's also a difference in light handling between TDM and vanilla Doom 3? I really modeled the render code after the current TDM implementation, maybe that's the reason.

  • Thanks 1
Posted
1 hour ago, jonri said:

I've noticed that light and sound markers are now opaque, is this a bug or a feature?

Depends on whether it's useful or not :) It's just the first thing I got working when migrating the renderable objects.

Posted

It does make the inner sound radius invisible, which is not ideal.

My missions:           Stand-alone                                                      Duncan Lynch series                              

                                      Down and Out on Newford Road              the Factory Heist

                                The Wizard's Treasure                             A House Call

                                                                                                  The House of deLisle                                                                                                  

                              

Posted

The lights are a LOT easier to find now compared to the wireframes, but being fully opaque also blocks your view of smaller model lights.

Making them solid but translucent might be a nice compromise, although you wouldn't see the true color of the light any more. Same with the sound sphere, but without the downside. Would this be hard for me to try myself?

Posted
3 hours ago, jonri said:

Making them solid but translucent might be a nice compromise, although you wouldn't see the true color of the light any more. Same with the sound sphere, but without the downside. Would this be hard for me to try myself?

It's surely possible to make them translucent, of course. You won't know until you try, so feel free to have a go at it. :)

Posted

I found light/Renderables.cpp and was able to hard-code in an alpha value, I mostly like it:

Spoiler

light-translucent.thumb.jpg.747693535e644bce1de7e60db81d332f.jpg

The intersection with another translucent material got a bit wonky, but that's not totally unexpected.

I tried to set the alpha on the colour variable in RenderableSpeakerRadiiFill::generateSphereVertices but it didn't seem to have any effect.  @greeboany idea why that one would be different?  At a first glance, the rendering code looked very similar for the light and speaker gizmos.

  • Like 1
Posted
1 hour ago, jonri said:

I tried to set the alpha on the colour variable in RenderableSpeakerRadiiFill::generateSphereVertices but it didn't seem to have any effect.  @greeboany idea why that one would be different?  At a first glance, the rendering code looked very similar for the light and speaker gizmos.

It's sometimes not enough to set the alpha value on the vertices, the shader used to render them needs to support it. The SpeakerNode is using the default EntityNode::_fillShader to render its geometry, but the fill shader is not supporting alpha. The fill shader is requested in EntityNode.cpp:448:

_fillShader = renderSystem->capture(ColourShaderType::CameraSolid, colour);

The CameraSolid type is not supporting alpha. You can try to use the EntityNode::getColourShader() in SpeakerNode::onPreRender instead of getFillShader(), maybe the alpha values will be respected then.

  • Thanks 1

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

    • nbohr1more

      TDM is now in the Top 100 for Mod of the Year! Please vote again: https://www.moddb.com/mods/the-dark-mod
      · 1 reply
    • snatcher

      Author of the Visible Player Hands mod: please come forth and collect a round of applause!
      · 2 replies
    • nbohr1more

      Holiday TDM Moddb article is now up: https://www.moddb.com/mods/the-dark-mod/news/happy-holidays-from-the-dark-mod
      · 0 replies
    • nbohr1more

      Cool thing: Thanksgiving break means I don't have to get my son up before dawn

      Not cool thing: My son stays up all night on my PC so I don't get much TDM time...
      · 3 replies
    • datiswous

      Does anyone know if the mission/map in this video posted by @Springheel can still be found somewhere and played? Looks like fun.
       
      · 2 replies
×
×
  • Create New...