From: <Mar...@be...> - 2007-07-25 19:05:16
|
Hello, =20 We're trying out deep-color channels with OSMesa, but have run into a few issues. We're using the VC8 .sln file and changing the CHAN_BITS value in config.h. =20 First, if I compile OSMesa/Mesa with CHAN_BITS set to 32, blending (and subsequently our transparency) no longer works, even if rendering into an 8-bit buffer. I'm fairly certain the reason for this is because s_triangle.c checks for CHAN_TYPE =3D=3D GL_FLOAT and doesn't compile certain sections that deal with blending if this check comes back true (Is this incorrect?). =20 Second, if I compile OSMesa/Mesa with CHAN_BITS set to 16, stencils do not function properly when rendering into an 8-bit buffer. I've had trouble narrowing down where exactly the stencil stuff could be messing up. =20 I searched through the archives for anyone who ran into these issues before, but could not find anything. Any insights? Does it sound like I'm properly setting up Mesa to use these deep-color channels?=20 =20 Mark Schlosser =20 |
From: Brian P. <bri...@tu...> - 2007-07-25 22:32:01
|
Mar...@be... wrote: > Hello, > > > > We’re trying out deep-color channels with OSMesa, but have run into a > few issues. We’re using the VC8 .sln file and changing the CHAN_BITS > value in config.h. > > > > First, if I compile OSMesa/Mesa with CHAN_BITS set to 32, blending (and > subsequently our transparency) no longer works, even if rendering into > an 8-bit buffer. I’m fairly certain the reason for this is because > s_triangle.c checks for CHAN_TYPE == GL_FLOAT and doesn’t compile > certain sections that deal with blending if this check comes back true > (Is this incorrect?). Not really. There's a few triangle drawing routines that are optimized for certain texturing states, but are omitted when CHAN_BITS != 8. For CHAN_BITS != 8 a generic triangle function is used. Blending, etc. will still be done. > Second, if I compile OSMesa/Mesa with CHAN_BITS set to 16, stencils do > not function properly when rendering into an 8-bit buffer. I’ve had > trouble narrowing down where exactly the stencil stuff could be messing up. > > > > I searched through the archives for anyone who ran into these issues > before, but could not find anything. Any insights? Does it sound like > I’m properly setting up Mesa to use these deep-color channels? I just did a quick test of a 32-bit/channel build (on Linux) and things mostly looked OK. I do see a couple glitches in the 32-bit rendering from the ostest1.c program. I'll look into that. A small test program would help me debug your problem. -Brian |
From: <Mar...@be...> - 2007-07-27 15:18:48
|
Hey Brian, We just wanted to let you know that we resolved the blending issues - it ended up being a problem on our end. We have seen some of the rendering issues that you mentioned in the 32-bit portion of the ostest1 demo, however. - Mark -----Original Message----- From: Brian Paul [mailto:bri...@tu...]=20 Sent: Wednesday, July 25, 2007 6:32 PM To: Mark Schlosser - Intern Cc: mes...@li...; Karin Smith; George Smith Subject: Re: [Mesa3d-users] Blending/stencil issues with OSMesa deep-color channels Mar...@be... wrote: > Hello, >=20 > =20 >=20 > We're trying out deep-color channels with OSMesa, but have run into a=20 > few issues. We're using the VC8 .sln file and changing the CHAN_BITS=20 > value in config.h. >=20 > =20 >=20 > First, if I compile OSMesa/Mesa with CHAN_BITS set to 32, blending (and=20 > subsequently our transparency) no longer works, even if rendering into > an 8-bit buffer. I'm fairly certain the reason for this is because=20 > s_triangle.c checks for CHAN_TYPE =3D=3D GL_FLOAT and doesn't compile=20 > certain sections that deal with blending if this check comes back true > (Is this incorrect?). Not really. There's a few triangle drawing routines that are optimized for certain=20 texturing states, but are omitted when CHAN_BITS !=3D 8. For CHAN_BITS = !=3D 8 a generic triangle function is used. Blending, etc. will still be done. > Second, if I compile OSMesa/Mesa with CHAN_BITS set to 16, stencils do > not function properly when rendering into an 8-bit buffer. I've had=20 > trouble narrowing down where exactly the stencil stuff could be messing up. >=20 > =20 >=20 > I searched through the archives for anyone who ran into these issues=20 > before, but could not find anything. Any insights? Does it sound like=20 > I'm properly setting up Mesa to use these deep-color channels? I just did a quick test of a 32-bit/channel build (on Linux) and things=20 mostly looked OK. I do see a couple glitches in the 32-bit rendering=20 from the ostest1.c program. I'll look into that. A small test program would help me debug your problem. -Brian |
From: Brian P. <bri...@tu...> - 2007-07-27 15:56:31
|
Mar...@be... wrote: > Hey Brian, > > We just wanted to let you know that we resolved the blending issues - it > ended up being a problem on our end. We have seen some of the rendering > issues that you mentioned in the 32-bit portion of the ostest1 demo, > however. The issue there (which I fixed in git) is the float color values may be outside the range [0,1] (because of lighting) and need to be clamped before conversion to ubyte. Calling OSMesaClampColors(GL_TRUE) fixed that. -Brian |