[vtk-developers] OSMesa depth buffer issues

[burlen]

Fair enough Francois. thanks for the help/explanations.
Burlen

Francois Bertel wrote:
> Usually OpenGL implementations pack the depth buffer and the stencil
> buffer in the same chunk of memory
> 24 of for depth+8 for stencil=32.
>
> If you are using X window, type glxinfo and you'll see that most of
> the visuals provide this kind of format.
>
> Nothing odd about 16-bit depth buffer, as I said before there is no
> API in vtkRenderWindow that allow you to specify the number of bits in
> any buffer so it is let to the system to provide whatever it has as a
> default configuration.
> I agree it sucks and it should be a VTK feature request.
>
> On Thu, Jan 28, 2010 at 7:18 PM, burlen <burlen.loring at gmail.com> wrote:
>   
>> Hi Guys,
>>
>> Yes I did try the environment variable. Just to be clear, we are talking
>> about OSMesa. OSMesa doesn't honor that environment variable. To check me on
>> this you can take a look at the mesa source code where OSMesaCreateContext
>> is defined. Mesa-7.7/src/mesa/drivers/osmesa/osmesa.c:1068:
>>
>> To get a default value for the depth buffer it uses the compile time
>> constant DEFAULT_SOFTWARE_DEPTH_BITS, which is conditionally #defined as 16
>> at Mesa-7.7/src/mesa/main/config.h:280
>>
>> I guess this does present another solution, that I didn't see before, namely
>> to add a -D DEFAULT_SOFTWARE_DEPTH_BITS=32 in my CFLAGS when I build mesa.
>> at the same time it doesn't seem right for VTK to default to a 16 bit depth
>> buffer...
>>
>> 24 bits of depth also solves the problem. but I would guess that 32 might be
>> advantageous form a performance standpoint given this is a natural size of
>> the intel registers... just a guess. How come you want 24?
>>
>> Francois Bertel wrote:
>>     
>>> Excellent point!
>>>
>>> On Thu, Jan 28, 2010 at 4:33 PM, Jeff Lee <jeff at cdnorthamerica.com> wrote:
>>>
>>>       
>>>> I am surprised it doesn't honor
>>>>
>>>>  MESA_GLX_DEPTH_BITS=24
>>>>  export MESA_GLX_DEPTH_BITS
>>>>
>>>> - this seems to work fine for me.
>>>> -Jeff
>>>>
>>>> On Thu, Jan 28, 2010 at 4:30 PM, Francois Bertel
>>>> <francois.bertel at kitware.com> wrote:
>>>>
>>>>         
>>>>> Hi Burlen,
>>>>>
>>>>> I just looked at vtkWindow/vtkRenderWindow and too bad, there is no
>>>>> API to let the user specify the render window settings regarding the
>>>>> depth in bit of each type of buffer (color buffer, depth buffer,
>>>>> stencil buffer, accumulation buffers) in the framebuffer.
>>>>> That would have be better than hardcoding the values in
>>>>> vtkXOpenGLRenderWindow.
>>>>>
>>>>> Anyway the typical values for on-screen are 24 bits for depth buffer,
>>>>> 8 bits for stencil buffer, 16 bits per channel for accumulation
>>>>> buffer.
>>>>> What happen in your case if you use these values instead the one you
>>>>> provided in your patch?
>>>>>
>>>>> On Thu, Jan 28, 2010 at 4:14 PM, burlen <burlen.loring at gmail.com> wrote:
>>>>>
>>>>>           
>>>>>> Hi Guys,
>>>>>>
>>>>>> I'm having some issues in ParaView that relate back to VTK's OSMesa
>>>>>> rendering context. Specifically VTK asks OSMesa for the default RGBA
>>>>>> context, which only has a 16 bit depth buffer. That's causing some
>>>>>> artifacts
>>>>>> and compositing issues in certain situations. for example:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts.png
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts-decomp.png
>>>>>>
>>>>>> Explicitly requesting a 32 bit depth buffer solves the problems.
>>>>>>
>>>>>> I attached a small patch that makes this change in VTK. It replaces the
>>>>>> call
>>>>>> to OSMesaCreateContext with one to OSMesaCreateContextExt specifying a
>>>>>> 32
>>>>>> bit depth buffer and carries forward the current default values for
>>>>>> accumulation and stencil buffers. I guess this function was The
>>>>>> OSMesaCreateContextExt was added to in mesa release 3.5, the current
>>>>>> release
>>>>>> is 7.7.
>>>>>>
>>>>>> Is this the right fix? Or is something more sophisticated necessary?
>>>>>> e.g.
>>>>>> run time configurable. And while we're on the subject, are OSMesa's
>>>>>> other
>>>>>> buffer defaults reasonable? accum (8 bits per channel) and stencil
>>>>>> buffers
>>>>>> (16 bits).
>>>>>>
>>>>>> Thanks
>>>>>> Burlen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> --
>>>>> François Bertel, PhD  | Kitware Inc. Suite 204
>>>>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>>>>>                     | Clifton Park NY 12065, USA
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>>
>>>>>
>>>>>           
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>