Quake3World

well.. this is really my first time ever working on a shader...
I'm having an issue with a particular texture that isn't displaying properly.

The lighting is doing what it's supposed to but the light "bulb" isn't showing through the main texture like I want it to.


as you can see the texture between the stairs is mostly black. There should be some glowing going on there but there isn't.

Here's the shader (a copy of a light shader from the base_trim directory that does pretty much the same exact thing as Im trying to do)
any help on figuring this out would be greatly appreciated.

ok here's something a little interesting.
I copied the base_trim texture Im using as a reference for this current texture to my test texture directory.
I didn't change anything except the directory name so the shader would point to the right images.

The texture shows up but the glow effect doesn't just like the other one Im having with. The texture lights the area around it but there's no light in the black holes.

Odd...

Try texturing that shader on a larger peice of brushwork and observe the effect. Does it show lighting then?

Try texturing your stairs with the original Id surfacelight shader and see if it works.

Make sure you're not running in vertex lighting mode, this prevents most shaders from rendering more than one texture stage.

obsidian wrote:Try texturing that shader on a larger peice of brushwork and observe the effect. Does it show lighting then?

Try texturing your stairs with the original Id surfacelight shader and see if it works.

Hmm... Ill try to use it on a larger brush. I did use the original ID surfacelight shader and it does work. But if I copy it in to a different directory and try using that copy it wont work even though the shader is the same.

Shallow - I dont think Im running in vertex lighting mode as the other shaders (basic_trim etc) show up fine. Only the shaders in this particular directory wont work properly =\

still no good.

I even tried using the blendfunc add and blendfunc blend on it to see if there are any results.

I used a jpg format and a tga format too and neither work.

Check for shader name overwriting. Maybe rename it to something more original, like "textures/silmil_test/light1k"

I suppose "test" is in shaderlist.txt?

indeed it is.
What seems to be happening is that the base texture is hiding the light texture like a mask. There's no transparent parts.

I made a test box to see my changes more quickly and this is what it looks like



as you can see, the black's still black.

Yet the texture is giving off the green light like it should... (there isn't a single light entity in the test box. Its all lit by the trim texture on the box in the middle)

I'm going to try moving the textures into a different directory to see what happens. Like you said, could be overlap.

well I downloaded the q3ase program and made the same shader using the same texture.
And guess what? Now the shader works.

Cool beans.

take that back... the light emitting properties are gone...
should be easy enough to get working again though. The important thing is, I have green in my blacks :icon25:

an image of the stairs in the first shot with the new shader:

I like the box above better.

Shouldn't q3map_surfacelight be mentioned after q3map_lightimage?

Not sure if that's the culprit, but that's how I've always seen light shaders scripted.

And is the q3map_lightimage even necessary?

I'm sorry: I may well be talking out of my ass, since I've been out of it for quite a long time.


Anyway, I'd rewrite the script like so:

Plan B wrote:Shouldn't q3map_surfacelight be mentioned after q3map_lightimage?

I think the issue you're thinking of is to do with which image is used to determine the light colour.

If a lightimage is specified the compiler uses that, but if there is a qer_editorimage listed before the lightimage, that gets used instead! If neither of these is found then the image from the first non-lightmap texture stage is used (you're quite right in saying that a lightimage often isn't necessary). Not sure how these priorities fit around q3map_lightRGB in versions of q3map2 that support it.

Pretty sure q3mp_lightRGB takes priority over everything, which would make sense since you are trying to take direct control over the surfacelight colour rather than let Q3Map2 set one for you from the bitmaps.

When you add a light to a texture surface with a shader, the compiler simply adds some point lights just in front of that surface and lights it just as it would if you'd put a light in there yourself.

It creates these point lights in a grid over the surface of your texture. if your light texture is very thin, the places it's putting lights might be inside other brushes and such, and hence that light might not cast back onto the surface.

longstoryshort, if that is the issue you're best off adding lights manually. Alternatively there's a shader key for controlling the size of the light grid created.

Foo - so then I should just drop the shader, throw the sfx texture and the base texture together to make just one texture and manually stick some small lights in front?

I don't understand why you need 2 textures with that shader in the first place, especially since you are not doing any scrolling or fading effects with it. Just combine the textures.

In terms of emitting light, there doesn't seem to be a problem with the surfacelights in your screenshot in the first post.

q3map_lightSubdivide controls the spacing between generated surfacelights.

You can also use q3map_backSplash to redirect more light towards the surface.

yea I dont know why Im using two textures either after I really started to think about what it was I was doing.

The first screenshot is light working but the texture wasn't transparent like it should have been.

The latest shot is the texture being transparent like it should be but not emitting light like it should have in the first shot. Dont know why neither want to work. I think one texture might solve the problem.

My current lightsubdivide key is 64
Ill try a smaller number?

I need to read up on q3map_backsplash. Thanks for the tip =)

Shallow/Obsidian:
Just outof interest....Would it be normal for the lightmap stage to be placed where it is? I know for alpha blending stuff its done this way, but I thought the lightmap stage normally goes at the end. Also does the first texture stage require a blendFunc, since it isnt blended with anything?

It's pretty common for the lightmap stage to get placed first in multi-stage shaders, especially ones that represent lights like this one. I think it makes a subtle difference to the end result but never paid much attention since I found it looks right either with lighting first, or after the main texture. You wouldn't want the lightmap to be absolutely the last stage in this kind of shader though, that would put the lightmap on top of the glow stage. Maybe putting the lightmap first is a reminder not to do this!

Any shader stage that has no blendfunc will be opaque, its texture will completely replace whatever is in the framebuffer. So in this shader the first stage (lightmap) is opaque, then the second stage has a filter blend to produce the effect of the lighting showing on the main texture - even though it's actually the main texture showing on the lighting :icon28: - and finally the additive glow stage.

understood

Lightmaps are just another texture that you are layering with the other textures with blendFuncs. The order in which textures/lightmaps/etc. appear only depends on the effect that you want to produce.

As Shallow said, you typically want the additive glow to appear last, but whether you want to filter the lightmap over the texture or filter the texture over the lightmap doesn't make a difference to appearance.

It gets trickier with alpha-tested blends, but that's another story.