Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / per pixel diffuse dot3 bump mapping (?) Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Vast

March 07, 2005, 08:48 PM

Ok, I implemented diffuse dot3 bump mapping, based on an ATI demo here (http://www.ati.com/developer/sdk/RADEONSDK/Html/Samples/OpenGL/RADEONSimpleDOT3.html) anyway, As i implemented it, i realized that i dont want to have diffuse "lighting" but i would rather have per pixel attenuation. Well, I understand how THIS works, but i have NO idea on how to disable this diffuse lighting since the glColor3fv sets the tangent space light vector, and if i take it away then im screwed (the bump map will get "baked" into the texture (thanks to Stalker for explaining it to me in GT forums).

Anyway, i dont want to use any shaders, or nv texture combiners, so ill probably have to find a way to do the ppxl lighting some other way (arb texture combiners?) and then render that as a second pass, but if i do, i still have the diffuse lighting, which pisses me off.

So, anyone has any suggestions regarding how would i get rid of the diffuse lighting, and still keep the bump mapping?
Please be specific.

Thanks,
Tim.

 
Reedbeta

March 07, 2005, 11:43 PM

How can you have bump mapping without diffuse lighting? I don't understand what you want. If you disable diffuse lighting, you will have only ambient light, which comes from all directions and thus isn't affected by bump mapping.

 
Vast

March 08, 2005, 09:20 AM

srry! lol, i confused diffuse with vertex lighting, hehe... *shy*.

I light every vertex for some reason, when i do the bump mapping, i just now realized, would per pixel attenuation map cancel out the lit areas? and light up only whatever is covered by the "white" part of the attenuation map, right?

Thanks!
Tim

 
Reedbeta

March 08, 2005, 01:11 PM

Hmmm.. if you've set up the combiners to do dot3, you shouldn't be getting vertex lighting effects at all. Make sure GL_LIGHTING is disabled? Maybe you could post a screenshot of what it looks like now, I'm not sure I'm understanding you properly. Per-pixel attentuation would indeed light up only the areas that are white on the attentuation map.

 
Vast

March 08, 2005, 03:46 PM

www.vaskosoftware.fre3.com/postGT.htm, refer to image 1. note, how the top right vertex is "lit" meaning it is brighter, than others.

Tim

 
Reedbeta

March 08, 2005, 03:49 PM

Isn't that just the dot3 effect, because the upper corner of the quad is more nearly facing the light than the lower parts?

It looks like in that picture the light is in the upper left. Put the light in the lower right and you should see the lower right corner be brighter. Put the light in the middle of the quad, close to its surface and you should see a bright spot in the middle. This is the normal way that light works.

 
Vast

March 08, 2005, 04:52 PM

Well, thats not the case here. If i put the light closer to the middle, the whole quad gets lit. If i move the light 3000 units from the quad, it still gets lit. If i move the light to the right, 2 right vertices get lit, if i move the light to the left, left 2 vertices get lit.

As i said, i did not implement per pixel attenuation, so im asking, if i will, will this unwanted effect be gone?

If u still have doubts, u could download the demo, and see for yourself.

Regards,
Tim.

I was told in another forum, that if i multiple the attenuation map with the current texture's pixels i would get the effect of correct lighting, and the vertex lighting would dissapear (or get canceled out during texture multiplication)

So, would that work?

 
Reedbeta

March 08, 2005, 06:26 PM

Why don't you just try it and see? =D

 
Vast

March 08, 2005, 07:42 PM

lol, because i have to find out how to do it. I never did that before, if i did, i would try it first, and then ask. Just dont want to waste time, doing something wrong, if i can waste time doing something right, after a couple of questions =)

Tim

 
Reedbeta

March 08, 2005, 08:07 PM

Well, from what I've seen so far it indeed seems like per-pixel attentuation is what you are looking for. Implementing it can be kind of tricky given the limitations of the combiners, but here's a hint: perform the dot3 in the RGB unit of combiner 0, and calculate the attentuation in the alpha unit of combiner 0 (remember the RGB and alpha units are separate, so can have completely different sources and ops). Then you can multiply them together in combiner 1, and go from there.

 
Vast

March 08, 2005, 08:47 PM

something makes me think ur talking about nvidia combiners =)

Is there an alternative? The *biggest* problem in this case, is my unwillingness of wanting to use nvidia's combiners (or any vendor-specific extension) AND i dont want to use shaders... since even gf3 doesnt support pixel shaders, and thats just sad...

So, would you happen to know any alternatives?

Or were you speaking of arb texture combiners? Than i have to study those.

Thanks for the hint though, im sure it will help me, since there arnt too many alternatives besides the arb combiners =(

Regards,
Tim.

 
Reedbeta

March 08, 2005, 11:39 PM

I was talking about ARB combiners. I have a demo that does this, using only ARB extensions and no shaders, if you want to take a look at it sometime.

 
realytic

March 09, 2005, 01:35 AM

gf3 doesnt support pixel shaders

Really ? I thought they'd have shaders 1.1 ???
Are those accessable by opengl ?

 
Scali

March 09, 2005, 02:57 AM

Yes, I believe the correct term is Texture Shader... combined with the register combiners, those are pretty much the equivalent of ps1.1 in Direct3D.
They are only accessible in OpenGL through NVIDIA's extensions (and ofcourse don't work on other brands).

 
Vast

March 09, 2005, 09:42 AM

Hey Reedbeta, I would LOVE to take a look at it. If you could be so nice as to put it up here, or e-mail it to me (vasko.tim@gmail.com), i would greatly appreciat it. I was looking for something like that for a while now.

Thanks!

Regards,
Tim.

 
Reedbeta

March 09, 2005, 03:52 PM

Okay, I emailed it to you.

 
Vast

March 09, 2005, 04:27 PM

Hmm, I still havn't recieved it. Going to have to wait a little =)

I hope it is not an executable, since gmail blocks those! lol,

Thanks a lot ReedBeta!
Regards,
Tim

 
Reedbeta

March 09, 2005, 04:48 PM

Ahh, just checked my email and had a failure-delivery notice: "illegal attachment." It was a ZIP file, though. Odd..

Anyways, I've posted it on the web:
http://reedbeta.tripod.com/combiners.html

 
Vast

March 09, 2005, 05:10 PM

Thanks ReedBeta, i got it!

Regards,
Tim

EDIT: Aww, my geForce3 ti 200 doesnt support GL_Ext_texture_mirror_clamp extension =( Is it absolutely necessary? Or can i get rid of it, and still have the app running?

 
Reedbeta

March 09, 2005, 05:15 PM

It's not necessary, but you will have to modify the program a bit to make it work without it. texture_mirror_clamp is used on the attentuation map, so that the actual texture holds only the first quadrant of the attentuation map and the rest is mirrored. You can modify the attentuation map generator function to store the whole attentuation map in the texture, and then modify the function that sets texture coordinates for the attentuation map accordingly.

 
Vast

March 09, 2005, 05:23 PM

Just tried turning off the "return false;" for that check, my card also doesnt seem to support:
GL_Arb_texture_env_crossbar
GL_SGIS_texture_edge_clamp

After i disable those, the attenuation happens, but REALLY strange.
Here is a shot:
www.vaskosoftware.fre3.com/postFC.htm

Is there anything i can do to avoid those also?

Thanks!
Regards,
Tim.

 
Reedbeta

March 09, 2005, 05:29 PM

I'm really surprised your GF3 doesn't support texture_edge_clamp - but yeah, change all the GL_CLAMP_TO_EDGE_SGIS in the code to GL_CLAMP and it should work (though might have some artifacts).

As for ARB_texture_env_crossbar, I'm afraid that one is essential =( You won't be able to do both per-pixel dot3 and attentuation without it.

 
Vast

March 09, 2005, 05:34 PM

Aww. I see. Mabe my card just doesnt support SGIS one? I remember using EXT_texture_edge_clamp without any problems.

Thanks anyway though!
Regards,
Tim.

 
Vast

March 09, 2005, 05:40 PM

I was thinking about a technique, to have something like dynamic light mapping, and a mask on the whole world(mask could be another pass, of the whole world, but darker). In the places where the lightmapping shines, the mask should be transparent. Or something of equivalent supidity ;)

What do u think?

Regards,
Tim

 
Reedbeta

March 09, 2005, 05:41 PM

Ahh, yes the SGIS and EXT versions are the same as far as I know. My own card advertises both - I can't remember now why I used the SGIS one, though.

Multipass might be a way to make this work. However, without texture_env_crossbar you can't calculate the dot3 and the attentuation at the same time - so to have multiple lights, you would have to use the accumulation buffer. I.e. render the dot3 in one pass, then render the attentuation as a second pass, then add it to the accumulation buffer, clear the color buffer and go on with the next light.

 
Vast

March 09, 2005, 05:49 PM

ah, sounds like a pain, but better than my plan! =D

Anyway, i was just looking up some stuff on google, and found this post on flipcode, by vincoof, and i quote:
"Just a side note about ARB_texture_env_crossbar : NVIDIA cards do not support it with the exact string "GL_ARB_texture_env_crossbar" because of a little insignificant spec contradiction with NV_texture_env_combine4.
Still the feature is available. "
Unfortunately, i dont think he mentions the actual extension to be used (unless he meant NV_texture_env_combine4).

Here is the address of the post:
http://www.flipcode.com/cgi-bin/fcmsg.cgi?thread_show=7338

Would accumulation buffer rendering be much slower than using crossbar?

Thanks!
Regards,
Tim

 
Vast

March 09, 2005, 05:56 PM

Just checked the info on http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_texture_env_crossbar about opengl hardware extensions, and correct me if im wrong, but NO geforce card seems to support GL_ARB_texture_env_crossbar... i guess ill just have to use NV_texture_env_combine4... and on other cards, use crossbar.

Regards,
Tim.

 
Reedbeta

March 09, 2005, 05:57 PM

Yes, accumulation buffer would likely be much slower because of the excessive amount of copies involved.

That's great! I was thinking it was strange for a GF3 to lack support for crossbar. All crossbar means is that one combiner can read textures from any texture unit (without it, combiner 0 can only access texture units 0, and so on.) So just comment out the check for crossbar, change the SGIS to EXT, and hopefully it will work. (It will still look strange if you haven't modified the attentuation map code, though).

Edit: just looked over NV_texture_env_combine4, and it sounds (though it's not entirely clear) as if it basically implements crossbar along with a couple other things. So if you check for crossbar or NV_combine4, either should work (with no changes to the rest of the code).

 
Vast

March 09, 2005, 06:15 PM

I see =) Well, im glad i still have a chance =)

Where exactly (in code) do you make use of crossbar extension? I cant seem to find it...

Thanks!
Regards,
Tim

 
Reedbeta

March 09, 2005, 08:10 PM

In the setup for the combiners, combiner 0 dots the light vector with the surface normal (which is calculated by putting the interpolated vertex normal through the normalization cubemap), and calculates the attentuation as attentuation map (which gives the X and Y terms in tangent space) minus Z term (which is constant over each face). So combiner 0 reads from two texture units, which necessitates crossbar.

 
This thread contains 30 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.