 |
My workaround for this problem is to define the same set of custom textures in each mission, so if I switch between missions, I don't run the risk of "shader not found". At release time, I'd be inclined to ship the entire set of custom textures with each mission (for simplicity), even if I'm not using them all. This adds a bit of bulk to each mission pk4. |
 |
I tried to reproduce this, but failed, so either my test case is too simple or I'm doing it wrong. - I have this material: textures/dr_test1 { metal diffusemap textures/darkmod/nature/dirt/dry_earth_muddy_leaves bumpmap textures/darkmod/metal/grate/brass_grate_local specularmap textures/darkmod/metal/grate/brass_grate_s } and this testmap: Version 2 // entity 0 { "classname" "worldspawn" "editor_drLastCameraPos" "65.2623 -57.2201 103.355" "editor_drLastCameraAngle" "-31.5 19.5 0" // primitive 0 { brushDef3 { ( 0 0 1 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 510.5 ) ) "textures/dr_test1" 0 0 0 ( 0 1 0 -64 ) ( ( 0.0078125 0 2.5 ) ( 0 0.0078125 0.5 ) ) "textures/dr_test1" 0 0 0 ( 1 0 0 -320 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.5 ) ) "textures/dr_test1" 0 0 0 ( 0 0 -1 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 2.5 ) ) "textures/dr_test1" 0 0 0 ( 0 -1 0 -64 ) ( ( 0.0078125 0 510.5 ) ( 0 0.0078125 0.5 ) ) "textures/dr_test1" 0 0 0 ( -1 0 0 192 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.5 ) ) "textures/dr_test1" 0 0 0 } } } - I open the map in DR, it's a simple brush cube - I apply the texture to the cube and fit it (1x1) by using the Surface Inspector - Saving the map yields the above map file output. - Closing DR - I edit the .mtr file and change the material name to something different - Reopen DR and load the map - The cube is still there with the shader not found texture, fit 1x1 - Save the map over the existing one, produces the same result (?) - Changing the mtr file to the old texture name again (i.e. fix the broken reference) - Re-open DR and re-load the map, it's still everything there What am I doing wrong? |
|
|
I can't get your example to work. I create this: E:/test1/ E:/test1/textures/test1.mtr E:/test1/maps/test1.map And set DR's preferences to: Mod: E:/darkmod/ Mod Base: E:/test1/ When I open test1.map in DR, I get the "shader not found" painted on the cube. The Surface Inspector shows textures/dr_test1 as the texture, but I can't find it in the Media tab. What am _I_ doing wrong? |
|
|
The .mtr file needs to go into "materials/". |
|
|
Ah, poop. |
|
|
After correcting for the above brain-lapse ... I opened DR and changed the natural scale on the texture to 0.25x0.25 and applied it to all sides of the cube. I saved the map and closed DR. I opened the mtr file, changed textures/dr_test1 to textures/xxxxxx, and saved it. I started DR and opened the map file and--as expected--the cube was now painted with "shader not found". I checked the scaling on the cube's surfaces and found it to be 2x2. (A multiple of 8 times the original scaling, as described in the bug description.) So the problem is still there in 2.0.4 pre-1. |
|
|
Ah, you're referring to the value in the Surface Inspector's entry boxes? These values are indeed subject to the texture's pixel dimensions. Let's put that value aside, and focus on the problem occurring after restoring the missing material: What I've been trying to reproduce is this: after changing the material's name back to what it was, after re-starting DR and loading the map, the values are restored to the values they initially had and everything looks fine? Or has the alignment gone bad? |
|
|
It works fine, even when I write the map when the "not found" texture is shown. I'll have to go back to the map I was working with when I filed the problem, and see if it still exhibits the problem. If it works okay now, then I'll try switching back to 2.02 and see if I can reproduce the problem. I know it happened, because I had to re-scale large numbers of surfaces to restore the original scaling, and once I realized the workaround, I've been using the workaround since. |
|
|
Using 2.0.4 pre-1 ... Getting confused now ... I found the last good version of ws2_homeagain.map where the custom texture I used on the Builder church was scaled correctly. textures/darkmod/map_specific/steele/dark_brick_old_red I changed DR's preferences to Mode Base: E:/steele/ws2_homeagain/ I edited E:/steele/ws2_homeagain/materials/steele.mtr to rename the texture so it would now come up missing. Saved the mtr file. Started DR and opened the map. Found that DR, instead of painting the "shader not found" texture, painted the now missing texture instead. See the attached picture of the DR screen. Where is DR getting the shader definition from? |
|
|
I renamed materials/steele.mtr to materials/steele.rand and DR was still able to find that texture somewhere. I checked darkmod/materials and the texture is not included anywhere there. |
|
|
Maybe a PK4, I can't say without seeing your system. You can go to the Media Browser and seek the texture in question, then RMB it and select "Show Shader Definition". It shows the file the material is defined in. |
|
|
I'll put together a PK4. In the meantime, examine the attached picture. The missing texture doesn't appear in the Media Browser, so I can't RMB it. If I come at it from the direction of the Surface Inspector, the second dialogue box shows that the texture is present, but the red question mark shows that it doesn't display where DR found it. |
|
|
I attached test1.pk4. It shows a second cube textured with a custom red brick. If you edit the material file and rename the shader to the line that's currently commented out ('goopy'), the red brick still shows when you start DR and open the map file. I'm guess that DR is failing to find the custom shader, and is painting the cube with either the *_ed file or the diffuse file. |
|
|
Your guess is correct, if the material is not existing, it is also checked whether it directly matches an item in the filesystem. I assume in your case the diffuse map image file can be found at the exact position indicated by the material name. This is some sort of legacy "feature" coming from previous idtech engines, long before material defs were used. |
|
|
You can close this one. Having reproduced the "shader not found" state, I can't reproduce the messed up scaling state. When "shader not found" is painted, DR shows a scaling change to 4x2, instead of the 0.5x0.5 I used on the brick. If I make additions to the map and save it, a year ago, the 4x2 stuck around, screwing up the results when the texture was restored. But today it's reverting to 0.5x0.5 once I restore the brick texture in the mtr file. ----------------------- I looked at the good and bad versions of the map I was working on a year ago, to see if the good scaling was being retained when "shader not found" occurred. Note the change in the first plane that uses dark_brick_old_red. In the good version, for example, the x scale is 0.00390625 and in the bad version, DR changed that to 0.00048828125, which is 1/8th the good scale. A similar change was made to the y scale. Not having made any scaling changes to that plane, it was disconcerting to find that DR had done so quietly. I can't reproduce that behavior in 2.0.4, so either something very odd happened back in April or the problem's been fixed perhaps as a side effect of fixing something else. ---------------------------- ws2_homeagain167a.map (good) ----------------- // primitive 495 { brushDef3 { ( 0 0 1 261 ) ( ( -0.015625 0 116.5 ) ( 0 0.015625 27.125 ) ) "textures/common/caulk" 0 0 0 ( 1 0 0 -2112 ) ( ( 0.00390625 0 28.8125 ) ( 0 0.0078125 255.875 ) ) "textures/darkmod/map_specific/steele/dark_brick_old_red" 0 0 0 ( 0 0 -1 -392 ) ( ( -0.015625 0 115.375 ) ( 0 0.015625 26 ) ) "textures/common/caulk" 0 0 0 ( 0 -1 0 -864 ) ( ( -0.015625 0 115.5625 ) ( 0 0.015625 26 ) ) "textures/common/caulk" 0 0 0 ( 0 1 0 812 ) ( ( 0.00390625 0 33.890625 ) ( 0 0.0078125 255.875 ) ) "textures/darkmod/map_specific/steele/dark_brick_old_red" 0 0 0 ( -1 0 0 1932 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "textures/common/caulk" 0 0 0 } } ---------------------------- ws2_homeagain168.map (bad) ------------------- // primitive 495 { brushDef3 { ( 0 0 1 261 ) ( ( -0.015625 0 116.5 ) ( 0 0.015625 27.125 ) ) "textures/common/caulk" 0 0 0 ( 1 0 0 -2112 ) ( ( 0.00048828125 0 3.6015625 ) ( 0 0.001953125 63.96875 ) ) "textures/darkmod/map_specific/steele/dark_brick_old_red" 0 0 0 ( 0 0 -1 -392 ) ( ( -0.015625 0 115.375 ) ( 0 0.015625 26 ) ) "textures/common/caulk" 0 0 0 ( 0 -1 0 -864 ) ( ( -0.015625 0 115.5625 ) ( 0 0.015625 26 ) ) "textures/common/caulk" 0 0 0 ( 0 1 0 812 ) ( ( 0.00048828125 0 4.236328125 ) ( 0 0.001953125 63.96875 ) ) "textures/darkmod/map_specific/steele/dark_brick_old_red" 0 0 0 ( -1 0 0 1932 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "textures/common/caulk" 0 0 0 } } |
|
|
Just had a thought ... Since it looks like the scaling presented in the Surface Inspector depends not only on what the mapper entered, but also the resolution of the texture, would DR change the scaling in the *.map file if it used a texture of a different resolution? For example, the map is created with a 1024x1024 resolution image, but when the Mod Base gets switched and the only findable image is 256x256, would DR then change the stored scaling to match the new image's resolution? So when the 1024x1024 image is subsequently restored, DR uses the new scaling with the larger resolution image, thus screwing up how the image is painted on the plane? |
|
|
No, as far as I understand it, the contents of the .map file are not subject to change if you choose a different texture resolution. The texture projection matrix maps the world coordinates of the brush to texture coordinates which are independent of the actual resolution of the image. If it changed the .map contents, it would also happen when the shader not found texture is kicking in as a substitute for missing materials. The actual image behind the "shader not found" material is 64x64, I think, so the contents would have changed already in our tests above - but they didn't, so this kind of proves it. Nevertheless, thanks for providing the test cases and taking the time to test. I'm going to close this one, feel free to re-open this or open a new one if you run into texture wreckage cause by DR. |
|
|
Currently not reproducible. |
|
|
Thanks for looking at it. |
- Anonymous
