Normal mapping problem

[Stonemonkey]

Currently I'm doing my normal map lighting with a single texture unit in 2 passes for each light(no cubmapping) The first pass does dot3 on the primary colour and the rgb normal map and writes the result into the alpha channel, the second pass modulates the light colour (with fall off) using the alpha channel and blends the result with the colour buffer. This all works great but I'm now trying to do this in a single pass with 2 TUs but I'm already using the primary colour for the light vector.
I had a look at secondary colour but as far as i can see it is only added to the fragment and is pretty useless for this, I also thought about creating a single pixel texture for the light colour but that won't allow for the fall off and wasn't too keen on that idea anyway.

Is there any other way to send the light vector without using a cubmap or any other way to send a colour value to a texture unit other than primary colour or using a texture?

[Jim]

Isn't there a constant colour, as well as the iterated one and the one from the texture?
If not, this is where the whole thing falls over and you need to dive into the world of pixel shaders.

Jim

[Stonemonkey]

Looks like there is so now to find some details on it, just thought too that i might be able to scale the light vector for the fall off. Thanks Jim.

[ninogenio]

good luck mate if anyones up too it im sure you are.

have you thought about yousing fragment shaders in glsl ive only ust started messing about in there but theres a lot more flexibility over lighting using vertex/fragment shaders.

[Stonemonkey]

Well, it worked but by taking out 1 pass per light source for 3 light sources and adding blending using constant colour it slowed down

[Jim]

Is this the same dot3 demo you posted?  If so, it's still running at 60fps here   Very nice!

Jim

[Stonemonkey]

Yeah, it's the same one. Having to do quite a few passes for the lighting so, you know me Jim.

[Stonemonkey]

Anyone know if it's possible to use the colour or alpha components for texture coords of 1d or 2d textures? (without going into shaders)

[Jim]

I don't remember ever seeing that option.  And you have the problem that traditionally you need the uvs before you can retrieve the texture colour for the colour mixing pipeline.  Effectively they're needed in a different bit of the pipeline, and before you compute the colour.  Of course, with shaders, the hardware doesn't look like that any more, in fact it hasn't been like that since at least Pixelshader 1.

Willing to be corrected though - maybe OpenGL has a few tricks up its sleeve.

Jim

[Clyde]

I think I've read that you can alter the vertex colours. Possibly you can blend with those. Please correct me if Im talking nonsense with that. If so I'll get my coat, hehehe.

[taj]

I cant think of a way to do this ... a quick review of extensions reveals nothing either and what Jim writes makes sense. You want to use the fragment colour in the texturing stage, and its not available at that time. So *if* its possible, its multipass.

I do remember an experimental demo at SGI of this exact feature. But I cant find any details on it now. I guess it never made it to opengl due to implementation problems.

[Stonemonkey]

Clyde:
Get yer coat. It is possible to specify vertex colours and to blend or combine them in various ways but as far as I know only with other colours or alpha values from textures or colour buffers

Everyone else:
Thankyou, I thought as much but hoped there was something I'd missed somewhere.