[vtk-developers] vtkShadowRenderer

[Wylie, Brian]

Lisa,

Good suggestions. It will probably be best to avoid pbuffers (for the most
compatibility) anyway. As you point out, the use of extensions is also a
problem. We need the following extensions...

GL_NV_register_combiners	/* Could be optional but would give black
shadows */
GL_NV_texture_rectangle		/* Could be optional */
GL_ARB_depth_texture
GL_ARB_shadow 

So, perhaps at creation time (a temp ren win could be opened, extensions
checked, and if failure return a regular vtkRenderer). Obviously there's
still lots of work to make a general solution... :(

I'm not sure how to handle the texture issue if we use GL_TEXTURE_2D...

Thanks for the helpful feedback, I will work on it some more and keep
vtkdevelopers abreast of the progress...

	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: Tuesday, April 01, 2003 8:15 AM
> To: Wylie, Brian; 'Lisa Avila'; 'vtk-developers at public.kitware.com'
> Subject: RE: [vtk-developers] vtkShadowRenderer
> 
> 
> 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
> > >
> > >
> > >
> > >
> 
> 
> 
>