[Vertex blending not working with bump maps]

I identified the issue in DarkRadiant, which may or may not be similar to the main engine renderer. However, the cause is a couple of different aspects of the code whose function I don't fully understand, so I'm cautious about making a fix.

First, although we parse shader layers in order, we then sort them so that bump maps appear before diffusemaps. I don't know the reason for this sorting, but it is obviously intentional:

    // Sort interaction stages: bumps go first, then diffuses, speculars last
    std::sort(
        interactionLayers.begin(), interactionLayers.end(),
        [](const IShaderLayer::Ptr& a, const IShaderLayer::Ptr& b) {
            // Use the enum value to sort stages
            return static_cast<int>(a->getType()) < static_cast<int>(b->getType());
        }
    );

For my red/blue test example, this results in a sequence of material stages like this:

OpenGLShader: sorted list:
+ textures/test/spheres_local
+ textures/test/square_pyramids_local
+ textures/test/flatred
+ textures/test/flatblue

Notice at this point, we have completely lost all information about which bump maps go with which diffusemaps.

At render time (which is done by the light class, since like the engine we now render light-by-light so that shadows etc will work), we iterate over the sorted list of stages and try to assemble them into D/B/S triplets.

switch (interactionStage.stage->getType())
{
case IShaderLayer::BUMP:
    if (draw.hasBump())
    {
        draw.submit(objects); // submit pending draws when changing bump maps
    }
    draw.setBump(&interactionStage);
    break;
case IShaderLayer::DIFFUSE:
    if (draw.hasDiffuse())
    {
        draw.submit(objects); // submit pending draws when changing diffuse maps
    }
    draw.setDiffuse(&interactionStage);
    break;
case IShaderLayer::SPECULAR:
    if (draw.hasSpecular())
    {
        draw.submit(objects); // submit pending draws when changing specular maps
    }
    draw.setSpecular(&interactionStage);
    break;
default:
    throw std::logic_error("Non-interaction stage encountered in interaction pass");
}

This logic seems largely correct: look for a stage of each type to build up a triplet, but submit an incomplete triplet if we see the same stage type again. The problem here is that the draw.submit() method does not clear out the material stages, so we see them again on the next iteration, and this includes the default stages which are used for an incomplete triplet (black for diffuse/specular, "flat" for bumpmap).

So the triplets we build and submit/render go as follows:

1. See the first bumpmap spheres_local and add it to the empty triplet.
2. See the next bumpmap square_pyramids_local, which triggers a render because we already have a bumpmap in the triplet.
3. RENDER the first bumpmap spheres_local with black diffuse and specular (pointless, it's just a black render).
4. Add the second bumpmap square_pyramids_local to our triplet.
5. See the first diffusemap flatred and try to add it to the triplet, which triggers a render because we already have a diffusemap: the default black diffusemap from step 3!
6. RENDER the second bumpmap square_pyramids_local with black diffuse and specular (another pointless draw call).
7. Add the first diffusemap flatred to our triplet.
8. See the second diffusemap flatblue, which triggers a render because we already have the flatred diffusemap from step 7.
9. RENDER the flatred diffusemap with the existing square_pyramids_local bumpmap (which is the wrong bumpmap for this diffusemap according to the material, because we lost this info with the sorting).
10. Add the second diffusemap flatblue to our triplet.
11. No more layers, so submit the final triplet: flatblue with the square_pyramids_local bumpmap.

Aside from being 4 draw calls when we should have only two, this also gives rise to the observed problem: only square_pyamids_local is ever actually seen as a bumpmap. The spheres_local bumpmap is rendered, but we never see it because it was rendered with a black diffusemap.

So in order to fix this and get the correct result, I need to change two things:

1. Remove the sorting, and preserve the order of material stages defined in the material file.
2. Make sure each submit() call in the rendering code clears out the triplet and leaves it empty for the next loop iteration.

But I don't know if either of these are going to be correct in all situations. The outstanding questions are:

• What is the motivation for sorting material stages by stage type, bumpmaps before diffusemaps? Can this goal be achieved without discarding information about which bumpmaps are associated with which diffusemaps (and specularmaps)?
• Is it correct to clear out a D/B/S triplet after submitting it for rendering, or are there situations where we actually want the images from the previous render? For example, are there material situations where we might want to render diffusemap A with bumpmap B, then another render with bumpmap C which re-uses diffusemap A without it being listed again in the material file?

[DarkRadiant - Media Menu Not Showing]

Yes, wiping your preferences should revert to the default view with everything docked and no floating windows. However I don't know the location of preferences on Windows off the top of my head (probably somewhere under C:\Users\YourName).

[DarkRadiant - Media Menu Not Showing]

9 hours ago, AtimZarr said:

or rather, DarkRadiant seems to go "out of focus" and I need to click it to get back in, as if it opened a menu somewhere but I still can't see it.

That suggests that a window is being created but for some reason you can't see it.

Do you have (or have you ever had) more than one monitor connected to this laptop? Is it possible the window is appearing on a different "screen" (perhaps one that is no longer connected or working)?

[Vertex blending not working with bump maps]

1 hour ago, nbohr1more said:

@OrbWeaver @grodenglaive @stgatilov

Biker was able to get it working by removing the vertexColor args from the bump stages. Perhaps we implicitly pair all diffuse stages with the previous bump stage now?

I tried that. Unfortunately, removing [inverse]vertexColor from one or both of the bump stages makes no difference.

1 hour ago, stgatilov said:

Unlike "ambient stages" which are processed as they are written, interaction stages don't work as stages. The backend C++ code heavily reworks them.

Right, we do the same in DR — read them one by one, then assemble them into "triplets" of diffuse/bump/specular maps so the shader can process all three at once. My guess is that the vertex colours are not being passed through to the part of the shader which deals with the normal mapping, so the last normal map is being treated as the one and only normal map.

Quote

I see there is test map in the ticket, I'll try to have a look.

If there are no objections, I can commit my red/blue example into the maps/test/dr directory. The 256x256 normal maps are only 87K and being RGTC/BC5 they also exercise another part of the shader which can easily get broken (at least in DR).

[Vertex blending not working with bump maps]

I can confirm this, but it's a game issue not a DarkRadiant issue. Actually it's both a game issue and a DarkRadiant issue — DR renders the same thing (presumably because it's using shaders ported from the game code).

Vertex blending simply doesn't work with bump maps. One of the bump maps gets applied across the whole model, ignoring the vertex blend. This used to work fine in vanilla D3 but I assume it got broken by one of the many shader changes in TDM.

Example material:

textures/test/red_blue_vcol
{
   {
      blend diffusemap
      map textures/test/flatred
      vertexColor
   }
   {
      blend bumpmap
      map textures/test/spheres_local
      vertexColor
   }
   {
      blend diffusemap
      map textures/test/flatblue
      inverseVertexColor
   }
   {
      blend bumpmap
      map textures/test/square_pyramids_local
      inverseVertexColor
   }
}

Result:

Notice how only the "square pyramids" normal map is appearing. The "spheres" normal map is not visible at all, although the diffuse maps (which are solid red and blue) are being blended correctly. It seems that the last normal map completely replaces everything else.

[TDM logo video has 1:1 aspect ratio]

Is there such thing as a square monitor? I've never seen one. The closest to square was 4:3 and I haven't seen a screen like that in years.

[TheDarkMod: 32-bit binaries]

Oops, I guess I should have read this poll/thread before posting comments about the relevance of 32-bit in the technical discussion about 32-bit Linux builds.

My argument against catering to the people who have installed 32-bit OS on 64-bit machines is that this is a group of people who are:

• Tech-savvy enough to install their own operating system, but...
• Not tech-savvy enough to realise that they have installed the wrong architecture for their machine, and...
• Entirely uninterested in upgrading to a current OS version (which probably no longer offers a 32-bit option), or re-installing their OS to make proper use of their own hardware, and...
• Perfectly happy with applications being limited to 4 GB RAM, which is far too small for decent performance these days, but...
• Still expecting modern games to work.

I assume this is a group of people who are vanishingly small in 2024, and if they do exist, their expectations are so unreasonable that we shouldn't care about them. If they really want to try TDM on their weird setup, they can always compile the source themselves.

[Frob Helper discussion]

17 hours ago, snatcher said:

From this point we can expand with more options, of course:

• Always on (not recommended based on the nature of the game)
• On for all items - Hover
• On for all items - Fade In
• On for all items - Fade In Fast [Default]
• On for small items - Hover
• On for small items - Fade In
• On for all items - Fade In Fast
• Always off

I don't recommend this sort of UI layout.

If there are two independent settings (item size and fade duration), they should be two separate controls, not a single list containing a separate item for every possible combination of options. Otherwise you end up with a confusing and unwieldy list which explodes in size whenever a new option is added.

[Overriding tdm_weapon_arrow.script]

18 hours ago, chakkman said:

As a player, one thing I'm also not too fond of is the lack of uniformity. I think mission authors should take into account that especially players new to the mod want to figure out how the weapons work, and, they will have a hard time doing so, if many missions tweak the weapons.

I agree entirely.

Unless a mission is aiming to present a completely different gameplay experience (like making a rapid-fire archery-based combat mission instead of a stealth mission), I see no reason why things like bow aiming should vary on a mission-by-mission basis.

If the defaults are widely disliked, they should be changed. If they are a matter of taste and there is no agreement on what the value should be, they should be configurable by the player and take effect in all missions.

Imagine if every desktop application made its own tweaks to your keyboard layout or mouse acceleration because the author didn't personally approve of the default values. It would be a horrible user experience. Some applications actually do this with fonts, and yes, it's horrible. Potentially useful functionality made inaccessible because the author decided to ignore system font choices and DPI, and impose his hand-picked non-scalable 10pt font which I can barely read.

[Newbie DarkRadiant Questions]

@Ansome's question is correct. Nothing in real life ever has a perfectly sharp corner, and one of the pieces of advice often given to newbie modellers trying to make things look realistic and avoid the "obvious CG" look, is to give sharp edges a tiny bevel so they look like something that might be manufactured in real life.

The problem you've got in DarkRadiant is (1) dealing with tiny bevels using regular brush geometry is awkward, and (2) brushes aren't smoothed at all (unlike the cube on the right which actually has full smooth shading which you don't notice because of the tiny bevel). So unless you're willing to create imported 3D models with smoothed bevelled edges and place them on the corner of your buildings, adding bevels in brushwork might be more trouble than it's worth.

Probably the most important things with brickwork corners is to make sure the bricks line up properly. There's nothing more obviously CG than a plastered-on brickwork texture which just ends in an unrealistic column of cut-off bricks, with mortar joints that are completely unaligned with the brickwork on the adjacent face.

[Exporting models from Blender into TDM]

The Blender export scripts have been updated to work with the new Blender 4.1 series.

In this Blender version, they removed "Autosmooth" altogether, along with the corresponding parts of the Python API. This meant that the "Use Autosmooth settings" option had to be removed from the LWO exporter, where it was previously the default setting. The new default is "Full", which smooths the whole mesh, giving similar behaviour to ASE models, although "None" is still an option if you want a completely unsmoothed mesh.

[Western Language Support in 2024?]

9 hours ago, nbohr1more said:

I think Tels was trying to push the team to mass convert all missions to move XD data into strings/fm/english.lang but nobody wanted to broach it and even mission authors weren't happy about this way of handling things.

That is my recollection too.

The i18n system was basically Tels' personal pet project (hence the Perl script which is unmaintained because nobody in the world except Tels and Larry Wall have any interest in writing code in Perl). Because of the various implementation problems and general user-unfriendliness, Greebo didn't approve of merging it into the main mod, so it became a sort of optional extra that individual mappers could use by accessing various resources on Tels' personal server.

[Western Language Support in 2024?]

This is how i18n typically works in code:

1. Developers write the strings in English (or their native language), but mark all the strings with a function/macro which identifies them for translation. In C++ this might be _("blah") or tr("blah") — something which is short and easy to write.
2. A tool (which may be integrated into the build system), extracts all the strings marked for translation into a big list of translatable strings. This list is then provided to the translators, who do not need to be developers or compile the code themselves. They just create a translation for each listed string and send back a file in the appropriate format (which may or may not be created with the help of translation tools, perhaps with a GUI).
3. At runtime, the code looks up each translatable string, finds the corresponding translated string in the chosen language, and shows the translated version.

At no point do developers (who in this case would be mission authors) have to mess around with manually choosing string IDs. All they do is use the appropriate function/macro/syntax to mark particular strings as translatable. String IDs may be used internally but are completely invisible to developers.

I suggest that any system that involves instructions like "search the list of known strings for a similar string" or "manually choose a string ID between 20000 and 89999 and then write it as #str_23456" are over-complicated, un-ergonomic and doomed to be largely ignored by mappers.

[[2.13] Sound parameter 0 overrides]

As of 09e5ec1cae16b8350097fc97839de64cf96c4e88 I have changed the logic to write spawnargs if EITHER the speaker radii are different from the shader default, OR if there were min/max spawnargs to begin with. Spawnargs will no longer be created (or deleted) as a result of a speaker move, but will appear and change if the speaker is resized, which I assume is closer to the expected behaviour.

[[2.13] Sound parameter 0 overrides]

10 hours ago, stgatilov said:

But sound spawnargs are merely overrides.
You should not set them at all if you don't intend to override the values set in sound shader.

That's what we originally did, but mappers (or at least one mapper) complained in bug 6062 about the spawnargs disappearing if they were the same as the sound shader. I suppose we could have considered that "not a bug" and kept the original behaviour, but perhaps there are situations where the old behaviour was problematic — there would be no way to distinguish between "this speaker has default radii from the shader" and "this speaker has fixed radii which happen to be the same as the shader but must not change, even if the shader is edited". I don't know how common such a situation is in practice.

10 hours ago, stgatilov said:

Also, how does moving anything affect sound distances?
Whenever you move sound, you should only change its position/orientation and nothing else, shouldn't you?

Correct, but the freezeTransform method is called after the end of any transformation, and does not distinguish between what type of transformation was previously happening. I imagine resizing the speaker to the same size as the shader would also have triggered bug 6062, but speakers are resized less often than they are moved and hitting an exact size with the mouse would be rare, so the issue was only noticed when moving speakers.

10 hours ago, stgatilov said:

Anyway, if DR sets spawnargs to the same values as in sound shader, that's not a problem for the suggested change in the meaning of zero value. But setting maxdistance = 0 will be
 

That's what I'm confused about. I have yet to see any situation in which DR will set a max distance of 0 on a sound shader, other than by explicitly editing the spawnarg to have a "0" value.

[Can DR be used with engines like Godot?]

On 4/12/2024 at 3:29 PM, Skaruts said:

I browsed the source code yesterday a little, but I had no idea where to even start looking for it.

This appears to be the function which calculates the texture values for Q3 export:

https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/radiantcore/map/format/Quake3Utils.h?ref_type=heads#L56

It's largely based on legacy GtkRadiant code and means absolutely nothing to me.

[[2.13] Sound parameter 0 overrides]

The commit which introduced unconditional writing of the s_mindistance and s_maxdistance spawnargs was this one:

https://github.com/codereader/DarkRadiant/commit/541f2638c810588ada12e9a28360f16df6143d45

and it appears it was intended to fix this bug:

https://bugs.thedarkmod.com/view.php?id=6062

The current logic is to set the spawnargs to the same values as in the sound shader, if a shader is set:

// Write the s_mindistance/s_maxdistance keyvalues if we have a valid shader
if (!_spawnArgs.getKeyValue(KEY_S_SHADER).empty())
{
	// Note: Write the spawnargs in meters
	_spawnArgs.setKeyValue(KEY_S_MAXDISTANCE, string::to_string(_radii.getMax(true)));
	_spawnArgs.setKeyValue(KEY_S_MINDISTANCE, string::to_string(_radii.getMin(true)));
}

This happens in the freezeTransform method which is called after performing some manipulation of the speaker entity such as moving or resizing it. In this case _radii is the object which contains the modified speaker radii, so this code is persisting the modified radii into the relevant spawnargs. This seems to be working correctly when I manipulate a speaker with a valid sound shader.

The only way I can get 0 is by creating a speaker with a sound shader like blackjack_swing which does not have radii defined. In this case the speaker has a default minimum radius of 0.0 and a default maximum radius of 10.0. We could avoid setting a radius at all, but then the speaker just appears as an entity box rather than a sphere/circle, which I assume is the original reason for setting a default value.

Right now I have no idea what code path would lead to having both a minimum and a maximum of 0.0. I think we'd need more detailed reproduction steps.

This is the current logic for setting the spawnargs on speaker construction (rather than manipulation, which is the previous code):

// Initialise the speaker with suitable distance values
auto radii = soundShader->getRadii();
entity.setKeyValue("s_mindistance", string::to_string(radii.getMin(true)));
entity.setKeyValue("s_maxdistance", radii.getMax(true) > 0 ? string::to_string(radii.getMax(true)) : "10");

So there is a specific check that s_maxdistance is greater than 0 before setting it as a spawnarg. Code similar to this has existed for many years, as far as I can see, and I have to go as far back as 2009 to find something different (originally all speakers just had hardcoded 16/32 radii to make them visible).

[Can DR be used with engines like Godot?]

20 hours ago, Skaruts said:

Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it. 

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

[Newbie DarkRadiant Questions]

Skins don't require a model path, that's just a convenience feature to allow the skins to be associated with the model(s) in the editor.

However I have no idea if an unassociated skin can be used on a func_static. I suppose there's no reason why it couldn't work, but it's not something I've ever tested and I wouldn't be surprised if it fails to do anything (either in the editor or the game).

[Can DR be used with engines like Godot?]

When you say the value is not correct, do you mean it actually gives wrong results in the Q3 engine, or it just "looks wrong" when examining the text file?

If it's the former, then that's arguably a bug (although supporting Q3 isn't top priority for DR). If it's the latter, then that doesn't really mean much at all — raw numbers in a map file don't necessarily correspond directly to values shown in the GUI, especially when transformations are involved (for example the -180 might be a rotation to match the default orientation in a particular engine).

[Skin Creation Help]

I don't think any declaration names can start with numbers; I doubt this is something specific to skins. This is similar to the rule in most programming languages where you can have a variable called "a1" but not "1a".

However you can organise skins into virtual folders using forward slashes, and individual folder elements can start with numbers. The example in the D3 documentation is "skins/models/weapons/3rox".

[DarkRadiant crashes when trying to change the name of a newly created skin in the skin editor]

On 4/7/2024 at 9:27 PM, jonri said:

1. The rename operation happens every time you type a character, which is a little laggy.  It would be better to rename it when you are done typing and the field loses focus
2. Typing new characters while renaming works as expected, but deleting characters causes the box to highlight so you have to reset the cursor before deleting another one.
3. On the Material Replacements tab, click to edit is not working for me.  I spent a lot of time on this, I can get a box to show up if I replace the editbox+button with a simple edit box.  I think it's related to the compound control not being able to have focus.
4. The skin name is showing up on top of the Close button

I can reproduce all of those.

For (1), I propose that the Skin Name field should be non-editable, and have a separate button (usually the "pencil" icon) to show a popup entry dialog for editing the name. I doubt renaming skins is all that common, and it certainly doesn't need to happen on every keypress. But if people object to additional popups, the field could be editable but only commit the changes on ENTER or if a "tick" button was clicked.

For (3), single-click to edit in a list is rather non-standard (double-click might be more expected). I propose to have two named entry fields below the list for "From" and "To", rather like the key/value fields in the Entity Inspector, with the fields reflecting the currently-selected list item and allowing changes (committed on ENTER or button click).

Not specific to the skin editor, but I think we need an application preference for monospace font size. Reading the declarations is really difficult on my 1440p monitor.

[Skin Creation Help]

I think you need to be more specific. What exactly "does not work"? Does the skin not show up in DR? Does it show up but crash DR? Does it appear but replace the wrong texture, or attach to the wrong model?

From the screenshot of the skin file in Notepad it looks like you have a space in the model name, but I'm not sure if that's the cause of the problem or just a cosmetic artifact of the screenshot.

[DarkRadiant crashes when trying to change the name of a newly created skin in the skin editor]

Reproduced with 3.9.0 on Ubuntu. This is the backtrace:
 

ASSERT INFO:
../src/unix/threadpsx.cpp(1678): assert "This() == this" failed in TestDestroy(): wxThread::TestDestroy() can only be called in the context of the same thread

BACKTRACE:
[1] wxThread::TestDestroy()
[2] wxutil::ThreadedResourceTreePopulator::ThrowIfCancellationRequested()
[3] decl::DeclarationManager::renameDeclaration(decl::Type, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[4] skins::Doom3SkinCache::renameSkin(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] wxTextEntryBase::SendTextUpdatedEvent(wxWindow*)
[12..34] <internal GTK stuff> 
[35] wxGUIEventLoop::DoRun()
[36] wxEventLoopBase::Run()
[37] wxDialog::ShowModal()
[38] wxutil::DialogBase::ShowModal()
[39] cmd::CommandSystem::executeCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&)
[40] cmd::CommandSystem::execute(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[41] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[...] <Other GTK/wxWidgets stuff>

 

[Newbie DarkRadiant Questions]

On 4/3/2024 at 9:10 PM, Petike the Taffer said:

I'm a bit disappointed it's seemingly not possible to resize speakers the same way you can resize brushes

It is possible. You can drag outside a selected speaker and resize it exactly like a brush.

Note that you have to drag outside the entire bounding box of the speaker (as if it were a rectangle), rather than just outside the circular boundary, which isn't particular intuitive. If you enable View -> Show -> Show Size Info you will see sizing axes which give a better idea of where the bounding box is.