 |
The ASE model in TDM is different than the one in the grass.pk4 I found on moddb (linked from the forum thread here: http://forums.thedarkmod.com/topic/12985-animated-grass-test-map) 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? |
 |
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 http://forums.thedarkmod.com/topic/18525-beta-testing-205/#entry397760 |
|
|
Yes, it appears to have been fixed around December 2016 in TDM SVN. |
|
|
I've attached the one found in TDM SVN. |
|
|
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: blocks_mixedsize03_mo { stone 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. |
|
|
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 MATERIAL_NAME iron MAP_NAME Tex BITMAP //tdm_collision_metal (should have been //base/tdm_collision_metal) |
|
|
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 |
|
|
So, I assume this issue can be closed? |
|
|
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. |
|
|
I'll leave this entry open then, in case it's causing troubles with more models down the road. |
|
|
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. |
- Anonymous
