View Full Version : 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.
08-17-2006, 05:29 PM
Originally posted by Zengar:
Look here (http://oss.sgi.com/projects/ogl-sample/registry/EXT/secondary_color.txt)
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 :-)
08-17-2006, 06:05 PM
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.
08-17-2006, 08:38 PM
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.
08-17-2006, 09:43 PM
wglGetProcAddress("SecondaryColorPointerEXT") and wglGetProcAddress("SecondaryColorPointer")OpenGL functions start with "gl".
My GEForce 7800BTW, 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"!
08-18-2006, 04:47 AM
Originally posted by Korval:
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. 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.
08-18-2006, 05:36 AM
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.
08-18-2006, 06:07 AM
Well, it sure makes for interesting reading.
08-18-2006, 09:01 AM
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?
08-18-2006, 02:23 PM
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 (http://steampowered.com/status/survey.html) 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.
08-18-2006, 02:44 PM
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.
08-18-2006, 02:57 PM
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.
08-18-2006, 06:06 PM
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:
-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)
-circular gradient 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.
08-19-2006, 06:35 AM
...or continue stubbornly on without acknowledging the point. So rude.
08-19-2006, 10:56 AM
as stated before use GL_CONSTANT_ARB as source in the combiner for your lightcolor/intensity stuff
I see. Let me play with this parameter and see what I can come up with.
Seems to work well so far.
Here's the combiner extension modes:
COMBINE_RGB_ARB Texture Function
MODULATE Arg0 * Arg1
ADD Arg0 + Arg1
ADD_SIGNED_ARB Arg0 + Arg1 - 0.5
INTERPOLATE_ARB Arg0 * (Arg2) + Arg1 * (1-Arg2)
SUBTRACT_ARB Arg0 - Arg1
Is there by chance an extension that will do something like this? It would be quite useful:
Arg0 * Arg1 * Arg2
Then I could do this:
Operand0 = GL_PREVIOUS
Operand1 = GL_TEXTURE
Operand2 = GL_CONSTANT
This would color a texture and modulate it with the previous color.
08-20-2006, 04:03 AM
nope, the only other combiners that exist are NV_...combine4: a0*a1 + a2*a3
and ATI_...combine3: a0*a2 + a1
08-20-2006, 04:34 AM
can you say a bit more about where the numbers come from?As far as I can remember, these numbers come from an automated survey built into steam. When first installing a steam game (e.g. HL2), you were asked if you'd like to participate in the survey.
08-20-2006, 04:27 PM
Originally posted by RigidBody:
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. This is the gaming market, which is quite different from the total market. In the gaming market AMD has always been a strong player, often having higher market share than Intel.
08-20-2006, 08:52 PM
Originally posted by knackered:
survey (http://steampowered.com/status/survey.html) data, which is now almost a year old.They conduct the survey on a continual basis, perhaps every 3 months and since all you have to do is tell them your internet speed and everything else is automatically extracted, most people participate.
"i can hardly believe that amd to intel is ~51 to ~48 percent."
Yup, specially since benchmarks show AMD to be superior. The next Intel P4 duo is making a come back.
Thanks for the GL_CONSTANT_ARB tip. Getting bumpmaps to work with colors is a pretty common complaint I hear. Hopefully this will be useful for others.
08-21-2006, 03:18 PM
Yes, other forward thinking people like you, halo.
08-22-2006, 04:34 AM
according to these stats intel and ati had more overall market share in desktop graphics, however in the hl2 survey intel plays virtually no role. So it purely depends on what sort of clients one makes his app for. Even in the hl2 survey it was "just" 50-60% with shader model 2.0 cards, and those stats come from "gamers". So still using some old extensions is not that wrong imo. Surely the new intel chips also do arb fragment program, but still providing some codepath for older hardware imo is not fundamentally wrong.
on the other hand its of course making your own life harder using this stuff ;)
08-22-2006, 05:07 AM
"Desktop market" doesn't just mean home users.
How many people in a call center are going to run some fancy looking FPS with bumpmaps and "cool" shadows?
In my entourage, I have met very very very few people who are into gaming. Everyone else thinks a graphics card is a VGA device. It converts a digital image into a analog output at a 60Hz refresh rate. They don't understand why these new GPUs need so much electricty and a fan, or why the company puts 256MB of VRAM.
08-22-2006, 05:22 AM
Originally posted by V-man:
In my entourage, I have met very very very few people who are into gaming. Everyone else thinks a graphics card is a VGA device. It converts a digital image into a analog output at a 60Hz refresh rate. They don't understand why these new GPUs need so much electricty and a fan, or why the company puts 256MB of VRAM. i recommend that you go out and find yourself some new friends :p
08-22-2006, 06:03 AM
CrazyButcher has a point. It really depends on the market you're after. There is certainly nothing fundamentally wrong with targeting the largest possible audience, as long as you can truly appeal to that audience, and within a reasonable time frame :)
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.