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

 Home / 3D Theory & Graphics / Lighting calculation 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.
 
Jeroen

April 19, 1999, 04:12 PM

Hi all,

Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
and light-position relative to that vertex). Doing this requires normalization of one of the
vectors, which in turn requires a square root. Is there a way to avoid this, and still have
full dynamics?

Jeroen

 
Jorrit Tyberghein

April 20, 1999, 05:55 AM



Jeroen wrote:
>>Hi all,
>>
>>Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
>>lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
>>and light-position relative to that vertex). Doing this requires normalization of one of the
>>vectors, which in turn requires a square root. Is there a way to avoid this, and still have
>>full dynamics?

You could make sure that your normals are already normalized in advance. This
is the way that Crystal Space does it.

Greetings,


>>
>>Jeroen

 
Conor Stokes (aKa DirtyPunk)

April 20, 1999, 09:01 AM



Jorrit Tyberghein wrote:
>>
>>
>>Jeroen wrote:
>>>>Hi all,
>>>>
>>>>Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
>>>>lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
>>>>and light-position relative to that vertex). Doing this requires normalization of one of the
>>>>vectors, which in turn requires a square root. Is there a way to avoid this, and still have
>>>>full dynamics?
>>
>>You could make sure that your normals are already normalized in advance. This
>>is the way that Crystal Space does it.
>>
>>Greetings,
>>
>>
>>>>
>>>>Jeroen

I have been working on a way for per texel perspective correct dot product lighting, involving
a special method, to get a normal to a special plane, which is actually 1-cos(theta), which
can be easily changed to cos(theta).

Conor Stokes

 
Jeroen

April 22, 1999, 08:08 AM

Jorrit Tyberghein wrote:

>>>>Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
>>>>lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
>>>>and light-position relative to that vertex). Doing this requires normalization of one of the
>>>>vectors, which in turn requires a square root. Is there a way to avoid this, and still have
>>>>full dynamics?
>>
>>You could make sure that your normals are already normalized in advance. This
>>is the way that Crystal Space does it.

Of course the normal vectors are already normalized. It's the this vector:

RelLight.X = Vertex.X - Light.X;
RelLight.Y = Vertex.Y - Light.Y;
etc.

Which needs normalizing. The dot-product gives the cosine of the angle between two vectors
times the product of their lengths:

RelLight * Vertex.Normal = cos(theta)*|RelLight|*|Vertex.Normal|

Now |Vertex.Normal| has a fixed length (127 for fong-shading purposes). But RelLight can
be anything and therefore a sqrt and division are needed per vertex to take care of this.

Is this how you do it?

Jeroen

 
Conor Stokes

April 23, 1999, 11:02 PM



Jeroen wrote:
>>Jorrit Tyberghein wrote:
>>
>>>>>>Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
>>>>>>lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
>>>>>>and light-position relative to that vertex). Doing this requires normalization of one of the
>>>>>>vectors, which in turn requires a square root. Is there a way to avoid this, and still have
>>>>>>full dynamics?
>>>>
>>>>You could make sure that your normals are already normalized in advance. This
>>>>is the way that Crystal Space does it.
>>
>>Of course the normal vectors are already normalized. It's the this vector:
>>
>>RelLight.X = Vertex.X - Light.X;
>>RelLight.Y = Vertex.Y - Light.Y;
>>etc.
>>
>>Which needs normalizing. The dot-product gives the cosine of the angle between two vectors
>>times the product of their lengths:
>>
>> RelLight * Vertex.Normal = cos(theta)*|RelLight|*|Vertex.Normal|
>>
>>Now |Vertex.Normal| has a fixed length (127 for fong-shading purposes). But RelLight can
>>be anything and therefore a sqrt and division are needed per vertex to take care of this.
>>
>>Is this how you do it?
>>
>>Jeroen
That would be how I do it, but I cheat, using a plane partitioning system, working on only
having so many different intensities, and I put the top four bits of the relative vector
(without the sign, as a cheat) x and y into a look up table, which in turn gives me my
dot product.

This means I can use rather quick generation of a 255 table per plane ;-)

Conor Stokes

PS And I am working on a bump-mapping method for this.

 
Jeroen

April 26, 1999, 05:26 AM

Conor Stokes wrote:

>>>>....
>>>>Is this how you do it?

>>That would be how I do it, but I cheat, using a plane partitioning system, working on only
>>having so many different intensities, and I put the top four bits of the relative vector
>>(without the sign, as a cheat) x and y into a look up table, which in turn gives me my
>>dot product.

I think I got it. It's a bit like fake phong then other way around. I'll implement it,
and see if it works.

Thanks,

Jeroen


 
Harmless

April 29, 1999, 05:54 PM



Jeroen wrote:
>>Hi all,
>>
>>Who knows a good way to calculate the angle between two vectors? I want to have fully dynamic
>>lighting, and in order to do that I need to know the angle between two vectors (Vertex-normal
>>and light-position relative to that vertex). Doing this requires normalization of one of the
>>vectors, which in turn requires a square root. Is there a way to avoid this, and still have
>>full dynamics?
>>
>>Jeroen

Actually you can get away using an accelerated 1/sqrt() routine, depending on the precision you need you can get this down to as low as 11 cycles on a pentium based machine, which is faster than either the division or the sqrt independantly.

I dumped a copy of some accelerated 1/sqrt() code at http://www.bloodshed.com/~harmless/dl/sqrt.zip

You can use this code to accelerate vector normalization without ill effects. I'll see if I can dig up my very low precision LUT based version as well.

Basically instead of doing:

(x,y,z) / sqrt(x*x+y*y+z*z) it becomes
(x,y,z) * oosqrt(x*x+y*y+z*z)

This doesn't address your problem of finding a way to determine the angle between non normalized vectors without the sqrt, it just speeds up the process a bit, which I think is about the best you can do without changing the problem, by precalculating more stuff.

-Harmless


 
Parashar Krishnamachari

May 11, 1999, 08:52 AM



Jeroen wrote:
>>
>>Of course the normal vectors are already normalized. It's the this vector:
>>
>>RelLight.X = Vertex.X - Light.X;
>>RelLight.Y = Vertex.Y - Light.Y;
>>etc.
>>
>>Which needs normalizing. The dot-product gives the cosine of the angle between two vectors
>>times the product of their lengths:
>>

I never even bother trying to normalize that vector... I just use the fact that intensity
falls off with the square of the distance. Basically, I find length^2, which is basically a
dot product with the same vector. I then divide what you call "RelLight" by length^2. End
result is actually a lighting equation that falls off inversely to distance rather than
inverse-square. But, hey, we're talking about speed here, and it still looks more realistic
than no falloff at all. For the divide, I have my own software FPU 1/x routine. Just uses a
table for mantissa and negates exponent... I don't even bother with an N-R loop. 15 bits of
accuracy can be safely stored in a 64k block.
Of course, if you can write a routine like that, you could just as well have 1/sqrt(x)
routine. Or even a 1/(x^1.5) routine -- so you can actually get inverse-square relationship.
But I just figure, the 1/x routine is really the most useful because you're gonna do a lot
of divides in an engine, and who wants so many LUT's?

- C.P.I. / ASMiNC

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