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

 Home / 3D Theory & Graphics / Light/Normal Vector to Vertex Color 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.
 
four

May 06, 1999, 08:48 PM

Aw man! I just typed a huge message, and it got lost because I didn't put an email address :( Basically I was just saying how great I think this forum is :) You can take my word for it :)

Basically, my problem is this: Given the cosine between a light unit vector, and a normal unit vector (which is 1 to -1), how do I map that value to a 24 bit color model?

My light is a headlight, which is attached to a moving camera. It's purpose is to pretty much light the polygons as the headlight of a car, or a flashlight would. Polygons perpindicular to the light (or view vector), and facing it are pure white, and polygons perpindicular and facing away from the light are pure black.

I was making the oversight that my cosine was between 0 and 1 - I was ignoring the 0 to -1 polygons - and just using that 0 - 1 as my color intensity for each element RGB. I just realized though that the results are wrong.

Here's my current code for mapping the cosine to a 24 color value:

// SurfaceIntensity is the cosine (0 to 1 in this method):
Vertex[A].r = SurfaceIntensity * 255;
Vertex[A].g = SurfaceIntensity * 255;
Vertex[A].b = SurfaceIntensity * 255;

With this method, if the camera is stationary, in the center of a sphere, the polygons to the left of the camera are pure black, the polygons to the front of the camera are grey, the polygons to the right of the camera are pure white, and all polygons beyond the camera are pure black as well.

I need a way of mapping the cosine to the color so that the polygons to the left are grey, to the front are pure white, to the right are grey, and to the back are pure black.

All of the books that I've checked out use the method that I am currently using, but I really don't see how it can work properly. Am I missing something?


 
Jeroen

May 07, 1999, 07:04 AM


four wrote:
>>Basically, my problem is this: Given the cosine between a light unit vector, and a normal unit vector (which is 1 to -1), how do I map that value to a 24 bit color model?
>>
>>My light is a headlight, which is attached to a moving camera. It's purpose is to pretty much light the polygons as the headlight of a car, or a flashlight would. Polygons perpindicular to the light (or view vector), and facing it are pure white, and polygons perpindicular and facing away from the light are pure black.
>>
>>I was making the oversight that my cosine was between 0 and 1 - I was ignoring the 0 to -1 polygons - and just using that 0 - 1 as my color intensity for each element RGB. I just realized though that the results are wrong.
>>
>>Here's my current code for mapping the cosine to a 24 color value:
>>
>>// SurfaceIntensity is the cosine (0 to 1 in this method):
>>Vertex[A].r = SurfaceIntensity * 255;
>>Vertex[A].g = SurfaceIntensity * 255;
>>Vertex[A].b = SurfaceIntensity * 255;
>>
>>With this method, if the camera is stationary, in the center of a sphere, the polygons to the left of the camera are pure black, the polygons to the front of the camera are grey, the polygons to the right of the camera are pure white, and all polygons beyond the camera are pure black as well.
>>
>>I need a way of mapping the cosine to the color so that the polygons to the left are grey, to the front are pure white, to the right are grey, and to the back are pure black.
>>
>>All of the books that I've checked out use the method that I am currently using, but I really don't see how it can work properly. Am I missing something?

Off hand, I see two possible causes for your problem:
1) You calculate the surface-intensity in a wrong way.
2) You get intensities from 0..255 here. for a 24-bit color mode that's okay, but maybe you're
using a 16-mode. This causes overflows.

Maybe I'm stating the obvious, but it would be helpfull if you posted the code which calculates
the cosine.


Jeroen

 
four

May 07, 1999, 11:33 AM

Here's the code. Hopefully the tags work, as I don't post code too often :) It lights an entire polygon. The normal vector is already unit length. This is all done in view space. The headlight is in view space, and the polygon, and it's normal are in view space.

As far as the color issue that you brought up. That's not the problem. This is all implemented in Glide 2.4, which simulates a 24 bit color model, but does a bunch of bit twidling to eventually dither it down to 16 bit. So that's not an issue. Any RGB value between 0 and 255 gives acceptable results.

As far as the way I'm calculating the cosine, it makes perfect sense to me. It's the same way you would calculate it for backface removal, and that works fine. In backface removal, a cosine between 1 and 0 is a visible surface, and any negative value is non visible.


for(A = 0; A < Polygon->NumVertices; A++)
{
Direction.I = Polygon->Vertex[A].x;
Direction.J = Polygon->Vertex[A].y;
Direction.K = Polygon->Vertex[A].z;

Magnitude = sqrt((Direction.I * Direction.I) +
(Direction.J * Direction.J) +
(Direction.K * Direction.K));

Direction.I /= Magnitude;
Direction.J /= Magnitude;
Direction.K /= Magnitude;

SurfaceIntensity = ((Polygon->Normal.I * -Direction.I) +
(Polygon->Normal.J * -Direction.J) +
(Polygon->Normal.K * -Direction.K));

// backfaces are all black (this shouldn't be needed as far as I can tell):
if(SurfaceIntensity < 0)
surfaceIntensity = 0;

Polygon->Vertex[A].r = SurfaceIntensity * 255;
Polygon->Vertex[A].g = SurfaceIntensity * 255;
Polygon->Vertex[A].b = SurfaceIntensity * 255;
}


 
Jeroen

May 07, 1999, 03:43 PM

four wrote:

>>Here's the code.
....(snip)....

Hmm, it looks allright to me. In fact, it's almost identical to my own code, which works
perfectly well. I guess it's something else.
But hey, that's the fun in coding isn't it :).


Good luck,

Jeroen



 
four

May 09, 1999, 05:23 PM

Problem solved. Stack it up to another dumb mistake :) I was of the opinion that the problem was in the lighting function, that I didn't even realize that I was lighting AFTER perspective projection ;] That was a dumb mistake.

Thanks for taking the time to help. You were right. "The problem must be somewhere else." :)

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