View Issue Details

IDProjectCategoryView StatusLast Update
0004644DarkRadiantModelspublic10.07.2022 21:45
ReporterVanishedOne Assigned Togreebo  
Status closedResolutionfixed 
Product Version2.4.0 
Target Version2.12.0Fixed in Version2.12.0 
Summary0004644: Use of BITMAP field in ASE differs from TDM
DescriptionTDM includes a model called models/darkmod/architecture/stairs/Arcturus_stairs.ase -- it originally appeared in Arcturus's Animated Grass Test demo map.

One of its materials shows up as missing (the Shader Not Found image) in DR. DR's model viewer reports its name as blocks_mixedsize03_mo (which looks like a truncated textures/darkmod/stone/cobblestones/blocks_mixedsize03_mossy).

Inside the ASE file we have:

    *MATERIAL 1 {
        *MATERIAL_NAME "blocks_mixedsize03_mo"


        *MAP_DIFFUSE {
            *MAP_NAME "blocks_mixedsize03_mo"
            *MAP_CLASS "Bitmap"
            *MAP_SUBNO 1
            *MAP_AMOUNT 1.0000
            *BITMAP "//base/Arcturus_stone_1"



Unlike MATERIAL_NAME and MAP_NAME, the BITMAP field doesn't have blocks_mixedsize03_mo but Arcturus_stone_1. This is the name of a material that actually exists in the grass demo (but is missing from TDM core): it's a vertex-blended mix of textures/darkmod/stone/cobblestones/blocks_mixedsize03_mossy and textures/darkmod/nature/grass/short_dry_grass.

Since the model works properly in the grass demo FM, my suspicion is that DR is mistaken about which field TDM will treat as the name of the material to use: TDM uses BITMAP, but DR reports either MATERIAL_NAME or MAP_NAME.
TagsNo tags attached.


related to 0002499 closedgreebo Xreal: Support MATERIAL_NAME shaders for ASE models 




03.11.2017 17:56

administrator   ~0009531

The ASE model in TDM is different than the one in the grass.pk4 I found on moddb (linked from the forum thread here:

The one in TDM actually refers to "\\base\textures\darkmod\stone\cobblestones\blocks_mixedsize03_mossy" as MATERIAL 1, whereas the one in the grass PK4 refers to "//base/Arcturus_stone_1".

Neither of them shows a "shader not found" texture on my end. Can you check which model you're working on, and where you got it from?


03.11.2017 18:32

reporter   ~0009532

It's the one in tdm_models01.pk4 in my TDM 2.05 installation.

Maybe the model got fixed in SVN since then? I seem to have reported it back in


03.11.2017 18:47

administrator   ~0009533

Last edited: 03.11.2017 18:48

Yes, it appears to have been fixed around December 2016 in TDM SVN.



03.11.2017 18:49


Arcturus_stairs.7z (30,781 bytes)


03.11.2017 18:49

administrator   ~0009534

I've attached the one found in TDM SVN.


03.11.2017 19:14

reporter   ~0009535

Last edited: 03.11.2017 19:48

Cheers; I can confirm it works on my end.

I see the fixed version has

MATERIAL_NAME blocks_mixedsize03_mossy
MAP_NAME blocks_mixedsize03_mossy
BITMAP \\base\textures\darkmod\stone\cobblestones\blocks_mixedsize03_mossy

and in DR's model viewer the material is reported as textures/darkmod/stone/cobblestones/blocks_mixedsize03_mossy

So here DR *did* use the BITMAP. Whereas the version from grass.pk4 has

MATERIAL_NAME blocks_mixedsize03_mo
MAP_NAME blocks_mixedsize03_mo
BITMAP //base/Arcturus_stone_1

and the DR model viewer reports blocks_mixedsize03_mo

If I copy grass.pk4 to my main darkmod directory so DR will load its contents, meaning it can see the Arcturus_stone_1 def, then the model viewer reports the material as Arcturus_stone_1 (and it looks correct). Maybe DR is falling back on one of the other fields when it can't find the BITMAP?

Edit: I tried using this material def for blocks_mixedsize03_mo:

    diffusemap _white

DR used it (for the grass.pk4 version of the model only) and I got white instead of Shader Not Found. TDM didn't try to use it; surfaces still showed up black and there was a 'couldn't load image: arcturus_stone_1' console error.



03.11.2017 20:08

reporter   ~0009536

It's the MATERIAL_NAME that's being used: models/darkmod/misc/clipmodels/ironsignmount_cm.ase appears in DR's model viewer to use a nonexistent material called 'iron', and the file has

BITMAP //tdm_collision_metal (should have been //base/tdm_collision_metal)


04.11.2017 04:03

administrator   ~0009539

Last edited: 04.11.2017 04:03

Yes, the DR code has a fallback routine in there (which had been added in 2011 to better support the ASE models in the XreaL game).

It's in plugins/model/RenderablePicoSurface.cpp:49



05.11.2017 07:12

administrator   ~0009550

So, I assume this issue can be closed?


05.11.2017 15:39

reporter   ~0009554

Well, it's up to you whether it's worth doing anything about. From my point of view, DR is giving misinformation about what materials TDM will look for. Still, it's an infrequent problem, and I can see it's an awkward case; if the fallback were applied or skipped depending on the game being mapped for, that too could cause confusion.


06.11.2017 04:53

administrator   ~0009563

I'll leave this entry open then, in case it's causing troubles with more models down the road.


05.02.2021 17:07

administrator   ~0013653

I checked the behaviour in the game's model loading code: TDM is only accepting materials through the *BITMAP field.
Therefore I adjusted the StaticModelSurface fallback code to only do this if the game config allows this. The TDM game config now defaults to no fallback, which aligns DarkRadiant's behaviour with what the engine is doing.

Related Changesets

DarkRadiant: master 0bcf5307

05.02.2021 16:52


Details Diff
0004644: TDM/idTech4 is not falling back to *MATERIAL_NAME if *BITMAP is not loadable, so wrap a condition around the XreaL behaviour to check the flag in the game config. Affected Issues
mod - install/games/ Diff File
mod - install/games/ Diff File
mod - install/games/ Diff File
mod - radiantcore/model/picomodel/StaticModelSurface.cpp Diff File

DarkRadiant: master 90d10fc8

05.02.2021 17:03


Details Diff
0004644: Add unit test to check the material fallback behaviour in the TDM game configuration Affected Issues
mod - test/Models.cpp Diff File
add - test/resources/tdm/models/missing_texture.ase Diff File

Issue History

Date Modified Username Field Change
03.11.2017 17:35 VanishedOne New Issue
03.11.2017 17:35 VanishedOne Relationship added related to 0004390
03.11.2017 17:56 greebo Note Added: 0009531
03.11.2017 17:56 greebo Status new => feedback
03.11.2017 18:32 VanishedOne Note Added: 0009532
03.11.2017 18:32 VanishedOne Status feedback => new
03.11.2017 18:47 greebo Note Added: 0009533
03.11.2017 18:48 greebo Note Edited: 0009533
03.11.2017 18:48 greebo Status new => feedback
03.11.2017 18:49 greebo File Added: Arcturus_stairs.7z
03.11.2017 18:49 greebo Note Added: 0009534
03.11.2017 19:14 VanishedOne Note Added: 0009535
03.11.2017 19:14 VanishedOne Status feedback => new
03.11.2017 19:36 VanishedOne Note Edited: 0009535
03.11.2017 19:48 VanishedOne Note Edited: 0009535
03.11.2017 20:08 VanishedOne Note Added: 0009536
04.11.2017 04:03 greebo Note Added: 0009539
04.11.2017 04:03 greebo Note Edited: 0009539
05.11.2017 07:12 greebo Note Added: 0009550
05.11.2017 07:12 greebo Status new => feedback
05.11.2017 15:39 VanishedOne Note Added: 0009554
05.11.2017 15:39 VanishedOne Status feedback => new
06.11.2017 04:53 greebo Note Added: 0009563
06.11.2017 04:53 greebo Status new => confirmed
05.02.2021 16:46 greebo Relationship added related to 0002499
05.02.2021 16:50 greebo Assigned To => greebo
05.02.2021 16:50 greebo Status confirmed => assigned
05.02.2021 16:50 greebo Target Version => 2.12.0
05.02.2021 17:03 greebo Changeset attached => DarkRadiant master 0bcf5307
05.02.2021 17:03 greebo Changeset attached => DarkRadiant master 90d10fc8
05.02.2021 17:04 greebo Status assigned => resolved
05.02.2021 17:04 greebo Resolution open => fixed
05.02.2021 17:04 greebo Fixed in Version => 2.12.0
05.02.2021 17:07 greebo Note Added: 0013653
05.09.2021 18:21 greebo Status resolved => closed
10.07.2022 21:45 Dragofer Relationship deleted related to 0004390