[vtk-developers] vtkShadowRenderer

Lisa Avila lisa.avila at kitware.com
Tue Apr 1 10:14:53 EST 2003


Hi Brian,

There is probably an alternate way - if you have access to the renderer (I 
think you do) from each of these places you can check if it is a shadow 
renderer and not do the makecurrent or the turning off of the texture in 
that case. The makecurrent one doesn't worry me - as long as you document 
in the shadow renderer that you should not cause any other context to be 
current (through a command/observer callback or the Update mechanism) then 
it should be fine. The texture call does worry me - if you don't turn 
texturing off there, where do you turn it off? Is everything textured? What 
about if it already has a texture? I suspect this will break under certain 
rendering conditions.

Also - it sounds like you are relying on some extensions for this to work 
(at least in your alternate solution). How are you handling this on 
platforms that do not support the extension?

Lisa




At 09:28 AM 4/1/2003, Wylie, Brian wrote:
>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
> >
> >
> >
> >






More information about the vtk-developers mailing list