Advertisement

Per Pixel Dot Product anyone?

Started by September 21, 2003 09:09 AM
10 comments, last by Missing Name 21 years, 5 months ago
I''m working on this lighting algorithm that kindof simulates real ambient and diffuse lighting. I''ve got the ambient part working great, taking slices of a 3d volumetric lightmap. However, the diffuse part seems a bit more complicated, and I''m rather stumped at the moment. Does anyone know about some info on calculating a per pixel dot product? I was thinking maybe this could be done with ARB fragment program or something, but I''m not quite sure how I could write the program at the moment. I''m thinking of a way it could work, but I''d need to be able to send the normal and light direction to the program, and I''m not quite sure how yet, especially sence I''m already using 2 texture slots with multitexture in 1 pass. Any help, comments would be great at the moment. (I''m using a Radeon 9700 pro) Thank you
Well, ARB_FP is certainly a good way to do it, I suggest going to ATI''s or nVidias developer sites, shed loads of tutorials and examples are there of various lighting techniques, including bumpmapping.

Also, you could do the dot with ARB_texture_env_dot3. I wouldn''t be bothered about using 2 texture units, the 9700 Pro has something like 8 of them.

You have to remember that you''re unique, just like everybody else.
If at first you don't succeed, redefine success.
Advertisement
The fragment program extension looks like your best bet, but I can't say the best way to go about doing it (I am working my way through shaders and lighting myself). If you check the ARB_fragment_program documentation, you will see an example towards the bottom of a chrome effect. They seem to have precalculated their lighting data (whether via a vertex program or in their code) and stored the results in the texture coordinates. Though as you said, you have used two of the textures already, so you may not have enough data (not to mention that cards without that many textures are screwed). My recommendation is to comb through the fragment program document (http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt) for any data that might be useful, or any way to pass the pre-calculated data to your shader.

Good luck with that.

[edited by - Rainmaker on September 21, 2003 10:45:17 AM]
Without entering into too much detail (since it would be a very long topic), you can either perform all computations on the vertex and fragment programs (it''s the easiest way) but for this to work you need a high-end graphics card, which hopefully your ATi Radeon 9700 is. But for older graphics cards, this recent functionality may not be fully supported and then you will have to fall back to older techniques, such as register combiners (for GeForce1-4) or fragment shaders (Radeon8500, Radeon9xxx prior to Radeon9500) or texture combiners (Radeon7xxx and few other graphics card). This is a well known problem (that doesn''t only affects the per-pixel lighting topic) that forces you to use different rendering paths for different hardware.
Whatsoever, if you just want your algorithms to run on your machine, don''t bother with the multiple rendering path hassle : just stick to ARB vertex and fragment programs.

You can find many, many resource at NVIDIA''s and ATI''s developer sites ( http://developer.nvidia.com ; http://www.ati.com/developer ) or simply google it and you will find many info too.

As for 3D volumetric lightmapping, I''m not sure about how far you want to use 3D volumetric maps, but I''ve never heard of 3D volume-based lighting, so if it requires much complex mathematics you may definately need fragment programs (and forget about register combiners and fragment shaders which may not be powerful enough)
Whats 3D volumetric lightmapping ? How do you implement it ? Does it work with dynamic lights ?

______________________________



[edited by - snisarenko on September 21, 2003 2:45:43 PM]
Thanks for the tips, and thanks python_regious for telling me about the 8 tex units, it really really helped to know that.

However, after a few hours of banging my head against the wall...

well, not really but I still haven''t yet solved it completely

... I''m going to check out ATI''s and Nvidia''s sites.

quote:


Whats 3D volumetric lightmapping? How do you implement it? Does it work with dynamic lights?


3D volumetric lightmapping is just a name I came up with for an ultra-simple, and ultra-accurate per-pixel ambient lighting algorithm. It should run on most machines.

It''s as follows:

Make a 3d texture using EXT_texture_3D of all of the distances from the light, using the point-light distance algorithm.

Take slices, baised upon distance, of the volumetric texture to get your ambient lighting value.

---------

However, this algorithem is only half right, cuz you also need to somehow take the dot product of the surface (much more complicated) and multiply it by the ambient value, because light is affected by both distance and angle.

(I recently found out that John Carmack invented this very same alg in 1996 (before I thought of it), and called it something like, "Taking slices of a 3d texture")
Advertisement
Idea.. after doing that 3d texture map why don''t you build a normal for each pixel.. since lighting is simply a dotproduct of a light source and a vertex/surface/pixel''s normal that should get you around that problem

- DensitY
How can an ambient term have a direction?

You have to remember that you''re unique, just like everybody else.
If at first you don't succeed, redefine success.
Ok ... I feel like I have some learning to do. I have to find out what a 3D texture is. U wouldn''t know any websites that would direct me on the topic :?
Hey, I just wanna let chall know that I did get it working last night. I''m using ARB_FP for the simple per pixel calculations:

Normalizing the normals at every pixel, normalizing the LightPosition in proportion to the vertex, then taking the dot product of the two.

The vertex calculations - well, really just the light position - is calculated in software, then sent to the fp.

Ooook, it might sound like mumbo-jumbo, but it''s really not "That" hard of a concept (I don''t think).

I''d say the best tutorial about using ARB_FP and ARB_VP (which I avoided, cuz I was sick of trying to get it to work) would be in NEHE''s Downloads section:

"ARB Vertex/Fragment" or something like that, it implements cell-shading using ARB_VP and ARB_FP, it''s a good thing I found it, I offer my thanks to the author.

(I would post some screenshots, but I don''t have a site )

This topic is closed to new replies.

Advertisement