[vtk-developers] vtkShadowRenderer

[Wylie, Brian]

Hi Lisa,

There are two things going on for shadow mapping.

1) For performance reasons you use 'render to texture' for the light view.
The current context is set to a pbuffer and you render into that pbuffer
from the light point of view.
2) When conducting the second pass, rendering from the camera point of view,
the light depth texture is 'bound' before calling this->UpdateGeometry() so
that you can do the depth compare through texgen.

So the makecurrent() ruins the first, and glDisable(GL_TEXTURE_2D) ruins the
second.

If Kitware prefers to keep those two lines, the following can be done.
1) Do a much slower read back from the depth buffer instead of 'render to
texture'
2) The shadow map (light depth texture) can be a GL_TEXURE_RECTANGLE_NV
instead of a GL_TEXTURE_2D. 

I've tested these two changes already and they work with a non-modified
version of VTK.

So, probably what I'll do is make those changes for the 'normal' version and
anyone who wants to use pbuffers can 'bleed' a little bit and hack their VTK
distribution. 


	Brian Wylie
	Sandia National Laboratories
	MS 0822 - Org 9227 - Building 880/A1-J
     (505) 844-2238   FAX (505) 845-0833


> -----Original Message-----
> From: Lisa Avila [mailto:lisa.avila at kitware.com]
> Sent: Monday, March 31, 2003 2:42 PM
> To: Wylie, Brian; 'vtk-developers at public.kitware.com'
> Subject: Re: [vtk-developers] vtkShadowRenderer
> 
> 
> Hi Brian,
> 
> 
> >vtkOpenGLPolyDataMapper.cxx -- line 126
> >ren->GetRenderWindow()->MakeCurrent();
> 
> This line is needed because the Update call made to update 
> the input data 
> may have caused another OpenGL context to become current. 
> This line cannot 
> be removed.
> 
> 
> >vtkOpenGLProperty.cxx -- line 51
> >glDisable(GL_TEXTURE_2D);
> 
> This actually should be replaced - instead of enabling and 
> disabling things 
> we should probably push the attribute bits and pop them - the 
> only problem 
> is that the path through the rendering code goes through the OpenGL 
> property early on - so we could push there - but it is not 
> quite as clear 
> where we would do the pop.  This is the same reason why the 
> disable is here 
> - it may have been enabled in a previous prop but not 
> disabled, so it is 
> done in the next prop's property. Do you know why this 
> particular disable 
> is causing you problems?
> 
> Lisa
> 
> 
> 
>