I want normal maps, but I also want material colors

I use glcolor3f to color and adjust modular lights. I use color arrays to adjust bumpmaps. But if I use one I can’t use the other. I want both, and I want it without a lot of complicated shader code.

I even would like to have a color array for bumpmapping normals and another color array for static vertex lighting.

If I could get the normal map to use its own color array, and ignore whatever the source color is, I could have both of these.

Originally posted by Zengar:
[b] Look here

I think it is in the core for some time now (better check it). Never used it however.

I find shaders more straightforward anyway.

P.S. It is not possible to define two different general-purpose colors in fixed GL as there is only one state register for it. Well, if I’m not mistaken, that is :slight_smile: [/b]

one can’t access secondary color in the combiners. I can only think of using cubemap for the normalmap normals, which would still allow use of vertexcolors. Also texture constant is a value you can play with in the combiners. However on old hardware with just 2 combiners, there is not too much space in a single pass.

God, what a drag. I go to these conferences where they talk about sub-specular-sheen, and they can’t even give me normal maps that work with vertex colors?

I guess I could just create a solid colored texture for each unique color in the scene, and use the RGB scale to lighten and darken it. What a hack.

one can’t access secondary color in the combiners.
Since when?

If you’re talking about register combiners, you most certainly can.

And if you’re talking about the texture environment, you still can, provided you have appropriate hardware. I forget what all the extensions are, but the “secondary color” extension is pretty important. Just look at the whole set of texture environment extensions.

Thanks. If I can set up a secondary color array, that will make everything much easier.

I tried wglGetProcAddress(“SecondaryColorPointerEXT”) and wglGetProcAddress(“SecondaryColorPointer”), but neither return a pointer. My engine grabs the pointers to lots of other extension functions this same way with no problem. My GEForce 7800 says it support the “GL_EXT_secondary_color” extension.

wglGetProcAddress(“SecondaryColorPointerEXT”) and wglGetProcAddress(“SecondaryColorPointer”)
OpenGL functions start with “gl”.

My GEForce 7800
BTW, is there some specific reason why you’re using outdated extensions and constructs like texture environment on a 7800, when you could just be using glslang?

Okay…I am going to bed now…I forgot the “gl”!

Originally posted by Korval:
[b]Since when?

If you’re talking about register combiners, you most certainly can.

And if you’re talking about the texture environment, you still can, provided you have appropriate hardware. I forget what all the extensions are, but the “secondary color” extension is pretty important. Just look at the whole set of texture environment extensions. [/b]
I am talking ARB_texture_env_combine, and there is no secondary_color for it. It is also stated in the extension itself that it wont work as secondary color does not have an alpha, which it would need.

I love the thought of halo putting all this effort into not using glsl, when all the while the driver’s eating up CPU trying to match glsl shaders to current gl states.

Well, it sure makes for interesting reading.

:slight_smile:

I’m working with what I am familiar with, and what is most widely compatible. Are you going to help me or just sit back and make smug remarks?

Smug remarks as usual, I expect. Like: “you’re obviously not that familiar with combiners”.

When you say “most widely compatible”, which market are you aiming your renderer at? If you’re aiming it at people who play fps, then you really ought to look at the Half Life 2 survey data, which is now almost a year old. That suggested that most people were using at least a SM2 GPU, and therefore were having all the texture stage extensions emulated by the driver in shader code. So what you’re doing now is coding yourself into a layered mode corner.
I don’t mean any offense, I don’t care what you do, but this is a discussion forum and I feel duty bound to give you some cold facts. You’re obviously very talented, but you could get a better return on your invested time and effort by changing your target hardware.

Originally posted by halo:
Are you going to help me or just sit back and make smug remarks?
having been here for four years, you should have noticed that knackered has his very own ways of helping…anyway, cool down. you’ve posted some funky stuff here- a smug remark shouldn’t crack your ego.

and by the way, knackered, since you posted that link: can you say a bit more about where the numbers come from? i can hardly believe that amd to intel is ~51 to ~48 percent.

From reading through the forum, it appears that the secondary color cannot be used with gltexenvf(). So I suppose I have to get into shaders in order to get bumpmaps working. This isn’t really what I was looking for, because I was trying to get a stable, reliable rendering base set up using what I already know, and what every example on the internet tells you to do.

I’m pretty disappointed, because I had my renderer 98% done, and now I have to tear it all apart and start over.

Whoa, before you starting tearing stuff apart, take a breather!

Now, to be honest, I couldn’t make much sense of
your initial post, but if all you want to do is
simple bumpmapping, then the simplist solution
I am aware of that uses ARB extensions is DOT3 bumpmapping. Google it. All you need is multitexture and texture combiners + dot3.

Now, as I just said, I couldnt make out this secondary color business, but have you looked into
making multiple rendering passes to possibly solve this problem?

I render everything in one pass:

-bumpmap
-lightmap
-base texture
-cubemap (shows through the base texture’s alpha map)

The problem is that sometimes I need to set the base material color when I am doing dynamic lighting. I draw the surface in a second pass with additive blending, using a circular gradient texture in place of the lightmap.

Additive pass for dynamic light:
(adjust color to make light color and intensity)
(enable color pointer for bumpmap)
-bumpmap
-circular gradient texture
-base texture

I use glcolor3f to adjust the color and brightness of the additive pass. However, I still want to draw the bumpmap in this additive pass, because it looks good when dynamic lights use bumpmapping. Here I am shining a “flashlight” at the floor. The light picks up on the edges of the surface facing the light. But I can’t make the light fade or be any color other than full-bright white:

So I need some method of turning on a color array for the bumpmap, while still using the original material color for the subsequent textures. I would really prefer to do this in as few of passes as possible.

…or continue stubbornly on without acknowledging the point. So rude.