Hello Theodore,

Hall, Theodore wrote:
> The direction of DirectionalLights is opposite to what I expected, and 
> opposite to the behavior of SpotLights -- at least in OpenSG 1.8.  I've been 
> tracing through the logic, and here's what I've figured out:
> 
>> >From the OpenGL documentation:
> 
>    http://www.opengl.org/sdk/docs/man/
> 
>    "If the w component of the position is 0, the light is treated as
>     a directional source ...  The initial position is (0, 0, 1, 0);
>     thus, the initial light source is directional, parallel to, and
>     in the direction of the -z axis."
> 
> So the direction is opposite to the GL_POSITION, and conversely, the 
> GL_POSITION is opposite to the direction, and the GL_SPOT_DIRECTION is 
> ignored.

OpenGL is probably more consistent than OpenSG here as it simple sets 
the position of a directional light at one of the infinitely far away 
points you have when using homogeneous coordinates.

> But in OpenSG 1.8 DirectionalLight::drawEnter(Action *action) I see:
> 
>    Vec4f dir(_sfDirection.getValue());
> 
>    dir[3] = 0;
>     
>    glLightfv(light, GL_POSITION   , dir.getValues());
>    glLightf (light, GL_SPOT_CUTOFF, 180.f          );
> 
> So it's setting the GL_POSITION from the specified direction, instead of its 
> opposite.  The direction is pointing toward the light, instead of away from 
> it as with the SpotLight.  I suppose it would break a lot of client code, but 
> I would change one line:
> 
>    glLightfv(light, GL_POSITION   , (-dir).getValues());
>    
> Thoughts?

Since offhand it sounds a bit more natural to specify a direction 
(instead of an infinitely far away) for a DirectionalLight that is what 
OpenSG calls the relevant field.
For consistency it probably should invert the direction, but I'm not 
sure if this is worth breaking applications in a somewhat subtle way.
BTW drawEnter is a callback registered with the DrawAction (not the 
RenderAction) which is mostly unused at this point as it renders in pure 
immediate mode (no state sorting, etc.), but in this case renderEnter() 
eventually does the same thing.

> Does OpenSG 2.0 follow the same logic?

yes.

        Cheers,
                Carsten

------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to