[vtk-developers] OSMesa depth buffer issues
burlen
burlen.loring at gmail.com
Thu Jan 28 19:18:19 EST 2010
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
>>>
>>>
>>
>
>
>
>
More information about the vtk-developers
mailing list