View Issue Details

IDProjectCategoryView StatusLast Update
0004138DarkRadiantShader Systempublic09.01.2016 13:16
Reportergrayman Assigned Togreebo  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version2.0.2 
Target Version2.0.3Fixed in Version2.0.4 
Summary0004138: DR changes horizontal and vertical scaling when it shouldn't, wreaking havoc
DescriptionIf you bring up a map in DR that uses a custom texture (defined in your "Mod base"), but you have your "Mod base" set to a folder tree that doesn't include that custom texture, DR replaces the custom texture in your map with the "shader not found" texture.

If you realize you have the wrong "Mod base" set, you can correct that and the next time you restart DR, your custom texture comes back.

HOWEVER ...

When DR paints the "shader not found" texture, it ALSO changes the horizontal and vertical scaling at the same time, for all worldspawn brushes that use the texture. In the cases I've seen, it's multiplying the stored values by 4 or 8.

I can understand showing the "shader not found" texture, but DR has no business changing the horizontal and vertical scales.
 
Func_statics, models, and patches appear to be immune to this problem.
 
If you straighten out the "Mod base" folder, restart DR, and bring your map up again, you'll find that your custom texture is once again visible on your brushes, but the horiz/vert scaling is all shot to hell.
 
This bug bit me because I'm working on WS2/3/4 at the same time, and switching back and forth between them.
TagsNo tags attached.

Relationships

related to 0000633 closed If a texture is removed from the mod (giving "shader not found"), the surfaces lose their scale and position settings 
related to 0000389 closedgreebo Find and replace textures ignores texture alignment 

Activities

grayman

grayman

02.07.2015 13:56

administrator   ~0007611

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.
greebo

greebo

07.01.2016 12:39

administrator   ~0007985

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?
grayman

grayman

07.01.2016 13:28

administrator   ~0007987

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?
greebo

greebo

07.01.2016 13:32

administrator   ~0007988

The .mtr file needs to go into "materials/".
grayman

grayman

07.01.2016 13:40

administrator   ~0007989

Ah, poop.
grayman

grayman

07.01.2016 13:48

administrator   ~0007990

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.
greebo

greebo

07.01.2016 14:01

administrator   ~0007991

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?
grayman

grayman

07.01.2016 14:26

administrator   ~0007992

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.
grayman

grayman

07.01.2016 15:30

administrator  

missing texture.jpg (917,273 bytes)
grayman

grayman

07.01.2016 15:36

administrator   ~0007993

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?
grayman

grayman

07.01.2016 15:57

administrator   ~0007994

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.
greebo

greebo

08.01.2016 09:08

administrator   ~0008000

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.
grayman

grayman

08.01.2016 12:24

administrator   ~0008001

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.
grayman

grayman

08.01.2016 12:42

administrator  

test1.pk4 (1,584,642 bytes)
grayman

grayman

08.01.2016 12:45

administrator   ~0008002

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.
greebo

greebo

08.01.2016 14:03

administrator   ~0008003

Last edited: 08.01.2016 14:04

View 2 revisions

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.

grayman

grayman

08.01.2016 15:07

administrator   ~0008004

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
}
}
grayman

grayman

08.01.2016 15:16

administrator   ~0008005

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?
greebo

greebo

09.01.2016 08:42

administrator   ~0008014

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.
greebo

greebo

09.01.2016 08:43

administrator   ~0008015

Currently not reproducible.
grayman

grayman

09.01.2016 13:16

administrator   ~0008016

Thanks for looking at it.

Issue History

Date Modified Username Field Change
14.04.2015 17:29 grayman New Issue
02.07.2015 13:56 grayman Note Added: 0007611
05.01.2016 16:07 greebo Status new => acknowledged
07.01.2016 12:39 greebo Note Added: 0007985
07.01.2016 12:39 greebo Status acknowledged => feedback
07.01.2016 13:09 greebo Relationship added related to 0000633
07.01.2016 13:11 greebo Relationship added related to 0000389
07.01.2016 13:28 grayman Note Added: 0007987
07.01.2016 13:28 grayman Status feedback => new
07.01.2016 13:32 greebo Note Added: 0007988
07.01.2016 13:40 grayman Note Added: 0007989
07.01.2016 13:48 grayman Note Added: 0007990
07.01.2016 14:01 greebo Note Added: 0007991
07.01.2016 14:26 grayman Note Added: 0007992
07.01.2016 15:30 grayman File Added: missing texture.jpg
07.01.2016 15:36 grayman Note Added: 0007993
07.01.2016 15:57 grayman Note Added: 0007994
08.01.2016 09:08 greebo Note Added: 0008000
08.01.2016 12:24 grayman Note Added: 0008001
08.01.2016 12:42 grayman File Added: test1.pk4
08.01.2016 12:45 grayman Note Added: 0008002
08.01.2016 14:03 greebo Note Added: 0008003
08.01.2016 14:04 greebo Note Edited: 0008003 View Revisions
08.01.2016 15:07 grayman Note Added: 0008004
08.01.2016 15:16 grayman Note Added: 0008005
09.01.2016 08:42 greebo Note Added: 0008014
09.01.2016 08:43 greebo Note Added: 0008015
09.01.2016 08:43 greebo Status new => closed
09.01.2016 08:43 greebo Assigned To => greebo
09.01.2016 08:43 greebo Resolution open => no change required
09.01.2016 08:43 greebo Fixed in Version => 2.0.4
09.01.2016 13:16 grayman Note Added: 0008016