Re: [Dri-devel] radeon: two-sided lighting issues
Michel Dänzer wrote: On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). [...] One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I may have stumbled upon this one, see the attached patch. Unfortunately, this doesn't fix the black roofs in bzflag, I wonder if it helps with flightgear... Index: radeon_state.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v retrieving revision 1.18 diff -p -u -r1.18 radeon_state.c --- radeon_state.c 25 Aug 2002 22:24:39 - 1.18 +++ radeon_state.c 12 Oct 2002 01:24:14 - @@ -885,7 +885,7 @@ void radeonUpdateMaterial( GLcontext *ct GLuint mask = ~0; if (ctx-Light.ColorMaterialEnabled) - mask = ~ctx-Light.ColorMaterialBitmask; + mask = ctx-Light.ColorMaterialBitmask; The old code is correct -- if colormaterial is enabled, then calls to glMaterial should only affect the bits of the material that aren't being covered by colormaterial. In other words, the colormaterial should reflect the current color - anything set by glMaterial is instantly overrided by the current color. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon: two-sided lighting issues
I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I havn't made any progress on this one. I wanted to learn more about OpenGL first and was reading Mesa code, too. And I got distracted by other problems :-| I was hoping that the transition to Mesa 4.1 may fix some of the lighting problems (tell me, if my hope is in vain.) So I won't spend too much effort now. I'll see if I can track down that gcc-3.2 wire-box issue during the weekend. Anyway, I'm amazed how quickly the work on the new branches (mesa-4-1, texmem) is proceeding. Great work! (didn't test myself yet, though ;) Cheers, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. [...] I was hoping that the transition to Mesa 4.1 may fix some of the lighting problems (tell me, if my hope is in vain.) Doesn't seem to make a difference there unfortunately. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
On Fri, 11 Oct 2002 18:00:18 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Neither RADEON_NO_VTXFMT nor RADEON_NO_CODEGEN make any difference. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
Am Freitag, 11. Oktober 2002 19:07 schrieb Felix Kühling: On Fri, 11 Oct 2002 18:00:18 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Neither RADEON_NO_VTXFMT nor RADEON_NO_CODEGEN make any difference. Even setenv LIBGL_ALWAYS_INDIRECT do _NOT_ help with all of my VTK apps in wire frame mode. So I point at Mesa. And my older Voodoo5 5500 (tdfx) had the same symptoms. Textures only on one side (the outer). But setenv LIBGL_ALWAYS_INDIRECT or setenv R200_NO_TCL 1 help with texturing of the outer side for the r200 case. It is broken since the TCL merge. graphics/examplesCxx setenv R200_NO_TCL 1 graphics/examplesCxx ./ColorSph [1] 9584 graphics/examplesCxx r200CreateScreen disabling TCL support [1]Fertig./ColorSph See both snapshots. -Dieter ColorSph-with-TCL.png Description: PNG image ColorSph-without-TCL.png Description: PNG image
Re: [Dri-devel] radeon: two-sided lighting issues
On Fri, Oct 11, 2002 at 06:00:18PM +0100, Keith Whitwell wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Any chance this might be similar to the FlightGear lighting problems me and a few other people have been seeing for ages? RADEON_NO_TCL 'fixed' that, but RADON_NO_VTXFMT made no difference . . . Simon (hoping for a solution to this, finally . . .) -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg06962/pgp0.pgp Description: PGP signature
Re: [Dri-devel] radeon: two-sided lighting issues
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). [...] One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I may have stumbled upon this one, see the attached patch. Unfortunately, this doesn't fix the black roofs in bzflag, I wonder if it helps with flightgear... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast Index: radeon_state.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v retrieving revision 1.18 diff -p -u -r1.18 radeon_state.c --- radeon_state.c 25 Aug 2002 22:24:39 - 1.18 +++ radeon_state.c 12 Oct 2002 01:24:14 - @@ -885,7 +885,7 @@ void radeonUpdateMaterial( GLcontext *ct GLuint mask = ~0; if (ctx-Light.ColorMaterialEnabled) - mask = ~ctx-Light.ColorMaterialBitmask; + mask = ctx-Light.ColorMaterialBitmask; if (RADEON_DEBUG DEBUG_STATE) fprintf(stderr, %s\n, __FUNCTION__);
