hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha object seems to turn on depth buffering when its in the chain!
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
Oh and I confirmed it also happens with Chris's Nov 14th OSX binary.
Both machines have nvidia cards.
Ben
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha object seems to turn on depth buffering when its in the chain!
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
On Fri, 28 Nov 2003 ben@ekran.org wrote:
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha object seems to turn on depth buffering when its in the chain!
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
Guenter
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
At 7:23 PM +0100 11/28/03, guenter geiger wrote:
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
The alpha object is really a mess though. The depth test message is 'auto' ?? That's not very descriptive, and neither is 'test' or 'function'. How does the following strike you?
- 'alpha-test' for setting m_alphaTest (I'm not even sure what this really does...) - 'depth-test' or just 'depth' for turning the depth mask on and off - 'source' (or 'src') for setting the source arg for glBlendFunc - 'destination' (or 'dst') for setting that arg of glBlendFunc
The src/dst messages could either take numbers for each of the possible gl constants or a string comparison could be done on the full name. This would allow for any combination, although I have to admit only a few are even very useful.
Also, the depth object works opposite of the way one would expect. Sending a 1 to it turns off the depth buffer?? That doesn't make a whole lot of sense to me.
I'm going to write a tutorial on render order and how it affects things like blending, because, to be perfectly honest, I had to look at Ben's patch twice before I realized why I couldn't get the damned red square to be inside the cube!! Obviously, one has to consider the render order in this case to determine which pixels are already in place for the alpha blending function to work on. I think Ben or someone had asked about Z-buffer sorting that would basically change this dynamically, but I'm not sure how we would do this in GEM without some sort of mad caching scheme.
cgc
Guenter
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Fri, 28 Nov 2003, chris clepper wrote:
At 7:23 PM +0100 11/28/03, guenter geiger wrote:
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
The alpha object is really a mess though. The depth test message is 'auto' ?? That's not very descriptive, and neither is 'test' or 'function'. How does the following strike you?
- 'alpha-test' for setting m_alphaTest (I'm not even sure what this
really does...)
- 'depth-test' or just 'depth' for turning the depth mask on and off
- 'source' (or 'src') for setting the source arg for glBlendFunc
- 'destination' (or 'dst') for setting that arg of glBlendFunc
The src/dst messages could either take numbers for each of the possible gl constants or a string comparison could be done on the full name. This would allow for any combination, although I have to admit only a few are even very useful.
Also, the depth object works opposite of the way one would expect. Sending a 1 to it turns off the depth buffer?? That doesn't make a whole lot of sense to me.
I'm going to write a tutorial on render order and how it affects things like blending, because, to be perfectly honest, I had to look at Ben's patch twice before I realized why I couldn't get the damned red square to be inside the cube!! Obviously, one has to consider the render order in this case to determine which pixels are already in place for the alpha blending function to work on. I think Ben or someone had asked about Z-buffer sorting that would basically change this dynamically, but I'm not sure how we would do this in GEM without some sort of mad caching scheme.
Me neither..
The naming is really a problem though :(
Guenter
cgc
Guenter
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with depth-buffering on?
Ben
On Fri, 28 Nov 2003 ben@ekran.org wrote:
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha object seems to turn on depth buffering when its in the chain!
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
Guenter
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Fri, 28 Nov 2003 ben@ekran.org wrote:
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with depth-buffering on?
What do you mean with "fix" the lighting ? Is there another problem I have overlooked ?
Guenter
Ben
On Fri, 28 Nov 2003 ben@ekran.org wrote:
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha object seems to turn on depth buffering when its in the chain!
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
Guenter
I'm using lighting (because lighting tends to get messed up when using "depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
At 8:20 PM +0100 11/30/03, guenter geiger wrote:
On Fri, 28 Nov 2003 ben@ekran.org wrote:
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with depth-buffering on?
What do you mean with "fix" the lighting ? Is there another problem I have overlooked ?
I think Ben's problem was with the way the [depth] object works. It's actually backwards - sending a 1 to the object turns depth buffering OFF! I've made a change to the object to make the 0 state turn off the Z and will commit it unless there are some objections.
cgc
Guenter
On Sun, 30 Nov 2003, chris clepper wrote:
At 8:20 PM +0100 11/30/03, guenter geiger wrote:
On Fri, 28 Nov 2003 ben@ekran.org wrote:
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with depth-buffering on?
What do you mean with "fix" the lighting ? Is there another problem I have overlooked ?
I think Ben's problem was with the way the [depth] object works. It's actually backwards - sending a 1 to the object turns depth buffering OFF! I've made a change to the object to make the 0 state turn off the Z and will commit it unless there are some objections.
The only objection could be backwards compatibility.
Guenter
When the "depth" object is in a gemchain lighting is not rendered properly.
(objects become hollow (ie reversed) with the front facing missing and the lighting that of a hollow box)
now if depth turns off depth buffering this would explain it.
It would be nice to be able to make a box in gem that is properly transparent (all the back faces being visible. with lighting on. Right now if you just create a box without depth lighting works, but not all the sides are transparent! (I imagine because of the render order of the faces) all sides do become transparent with [depth] but then lighting does not work.
I really would be happy to drop all this render order nonesense. Objects further back (in z) get rendered first. If the user wants to override this, then then can specify a render-order with [tigger] or gemhead arguments. This would simply be a lot more intuitive approach. (if its possible.)
Ben
----- Original Message ----- From: "guenter geiger" geiger@xdv.org To: ben@ekran.org Cc: gem-dev@iem.at Sent: Sunday, November 30, 2003 2:20 PM Subject: Re: [GEM-dev] gem cvs alpha-depth bug?
On Fri, 28 Nov 2003 ben@ekran.org wrote:
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with
depth-buffering on?
What do you mean with "fix" the lighting ? Is there another problem I have overlooked ?
Guenter
Ben
On Fri, 28 Nov 2003 ben@ekran.org wrote:
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha
object
seems to turn on depth buffering when its in the chain!
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
Guenter
I'm using lighting (because lighting tends to get messed up when
using
"depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Mon, 1 Dec 2003, B. Bogart wrote:
When the "depth" object is in a gemchain lighting is not rendered properly.
(objects become hollow (ie reversed) with the front facing missing and the lighting that of a hollow box)
now if depth turns off depth buffering this would explain it.
It would be nice to be able to make a box in gem that is properly transparent (all the back faces being visible. with lighting on. Right now if you just create a box without depth lighting works, but not all the sides are transparent! (I imagine because of the render order of the faces) all sides do become transparent with [depth] but then lighting does not work.
That was actually what the new feature of alpha was trying to achieve. It only turns off depth test for the affected object. Thats what is suggested for implementing blending in the OpenGL Guide.
See attachment for an example of a transparent cube with lighting. Of course, this is not a "real" solution...
I really would be happy to drop all this render order nonesense. Objects further back (in z) get rendered first. If the user wants to override this, then then can specify a render-order with [tigger] or gemhead arguments. This would simply be a lot more intuitive approach. (if its possible.)
I think it is possible, but it is quite an effort to do so. We would have to calculate all the matrixes twice and then do the sorting by hand, per polygon. Not something I see feasible in the near future, but I am not a OpenGL guru.
Ben
----- Original Message ----- From: "guenter geiger" geiger@xdv.org To: ben@ekran.org Cc: gem-dev@iem.at Sent: Sunday, November 30, 2003 2:20 PM Subject: Re: [GEM-dev] gem cvs alpha-depth bug?
On Fri, 28 Nov 2003 ben@ekran.org wrote:
I'm actually very fond of z-buffering
could we "fix" lighting so that it works as expected with
depth-buffering on?
What do you mean with "fix" the lighting ? Is there another problem I have overlooked ?
Guenter
Ben
On Fri, 28 Nov 2003 ben@ekran.org wrote:
hey all,
I just updated my gem cvs again today.
I've noticed an odd bug with alpha (again). this time the alpha
object
seems to turn on depth buffering when its in the chain!
Ooops, obviously my fault. I have changed default behaviour of alpha to the one it was in 0.87. Damn, I really forgot about that, ...
It is not really a bug, but a feature that lets you use alpha blending independent from position, but the default behaviour should of course stay the same. Sorry ..
Guenter
I'm using lighting (because lighting tends to get messed up when
using
"depth" to show the effect. without a depth object in a chain, the cube looks identical to its depth counterpart, as long as the alpha object is in the chain. If I turn off the alpha object it works fine. (looks as it does without using depth.
Here is an example patch.
Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
B. Bogart -
ben＠ekran.org
-
chris clepper -
guenter geiger