Masked texure trouble

(stil) #1

I’ve made a copy of one of the alpha textures from the rtcw /alpha texture package. I’ve also extracted the appropriate texture from pak0, and renamed it/placed it in a custom texture path.

This is the original shader


textures/alpha/mesh_c03
{
 //   surfaceparm metalsteps
    nomipmaps
    nopicmip
    cull twosided
    surfaceparm alphashadow
    {
        map textures/alpha/mesh_c03.tga
        alphaFunc GE128
        depthWrite
        rgbGen identity
    }
}

and this is my shader


textures/pac_textures/mymesh_A
{
    surfaceparm playerclip
    surfaceparm clipmissile
    surfaceparm nomarks
    nomipmaps
    nopicmip
    cull twosided
    surfaceparm alphashadow
    {
        map textures/pac_textures/mymesh_A.tga
        alphaFunc GE128

        depthWrite
        rgbGen identity
    }
}

My version appears ingame as a one sided texture, without masking.
I have no idea why it’s not showing up the same way as the original shader does. ?

(ydnar) #2

Try “cull none”.

Also, don’t extract any preexisting textures for use in your own shaders. Just reference the original texture with a qer_editorimage and the texture path in the shader stage.

Change the rgbGen from identity to vertex as well as add “surfaceparm pointlight” to the shader.

Is your shader in the scripts dir where RTCW can locate it?

y

(stil) #3

Thanks, I’ll try cull none.

The shader is in the scripts dir where RTCW can find it. :slight_smile:

(Hewster) #4

@Ydnar

The reason why I suggested to stil that he try extracting the texture
he wished to use, is because of a problem that was discovered when
you reference a stock texture from within a custom shader.

mp_interception by Tunn at TramDesign http://www.tramdesign.net is a
case in point.
Download: http://www.rtcwfiles.com/file.info?ID=8099

When Tunn first released his map, he got reports that textures in other
maps suddenly stopped working, the most obvious of which was
mp_base…
when mp_interception was in place, the following texture would be
missing in mp_base:

this was the offending shader:

textures/tunnstuff/grating
{
qer_editorimage textures/metal_misc/diamond_m01
surfaceparm metalsteps
{
map $lightmap
rgbGen identity
}
{
map textures/metal_misc/diamond_m01.tga
blendFunc GL_DST_COLOR GL_ZERO
rgbGen identity
}
}

I created a fix for him, where I removed this shader, and copied the
diamond_m01.tga from the stock pk3 & renamed it to grating.jpg…
this fixed the problem.

I must admit I did not report this, as I was sure it must be a known
issue ?

Hewster

(ydnar) #5

Note the offending shader’s qer_editorimage. It doesn’t end in .tga, does it? It’s not a valid editorimage line! :slight_smile:

Not completely his fault, though–it does cause an interaction with a shader caching bug present in RTCW, hence the shader borkage.

y

(stil) #6

Hmm, I changed the texture path back to the original texture, then changed cull to “none” still the same result. Ugly one sided black textures :confused:

(hummer) #7

I’m wondering if this is the same bug I’ve encountered…

Shader is fence_c10

Basically, a particular alpha texture that comes with RtCW… the one used on beach for the metal grating walkways outside is having some issues on new compiles.

On some machines, the texture simply doesn’t show, both with stock and tweaked cfgs. Doesn’t matter.

On my machine it works fine… but on on about 1/2 to 1/3 of the testers, it didnt show.

I’m pretty sure it didn’t work out of the box… plus I wanted alpha shadows anyway… so I copied the shader over, added the alphashadow line, and still same result. Extracting the image ended up the same as well.

I’d post screens… but… there’s nothing there. It either shows or it doesn’t.

(RabidCow) #8

I think some of this problem is a misunderstanding of how the q3 engine parses the baseq3 directory. The pak0…pak* are read in numerical order, each overwriting the last. Then the .pk3’s with names are parsed for files. If you reference a particular texture and do not move it to a different directory for your specific map, write a new shader for it, and then give that file out, you are overwriting everyone else’s shader that comes numerically or alphabetically before yours( in terms of .pk3 name). In turn, if a new map is released that has a name starting with a letter later than yours in the alphabet, it will overwrite your shader’s effect on that texture. It works this way, I assume, so that updates can be added as new pak files and it works quite well. I usually name test paks zzz*.pk3 to make sure they overwrite all others in my install. The problem is masked when some people experience it and others do not…usually because one or the other has extra .pk3’s that may be overwriting the problem shader and “fixing” it. Of course I may be way off base here…:slight_smile:

(RabidCow) #9

sorry, hit back in browser and double posted :slight_smile:
RC