Thread: [Algorithms] Direct Sunlight Lighting Model
Brought to you by:
vexxed72
From: David W. <da...@pl...> - 2005-11-17 19:20:40
|
Does anyone have any reference to a lighting equation that is better than N.L for direct sunlight? The problem with N.L is that when the light hits the surface direct on, the color at the pixel is exactly that of the texel. But you never get any additional contribution from the light source. Specular doesn't help as much as I'd like because if you use that, you start to get everything looking glossy which isn't natural either. I'm already doing a highpass filter into a glow buffer and all that, but getting things bright enough in the first place to look like they are "bathed in sunlight" just seems to be a real problem.... nothing much will pass the highpass filter in the first place. I'm experimenting with simply allowing L to be a value greater than 1 (for brighter light) but not sure if I'm on the right track with that. Ideas? -- David |
From: Tibor S. <tib...@zo...> - 2005-11-17 19:26:13
|
I'm not sure, but maybe you could try to implement Phong or Blinn lighting model. I haven't implemented them yet, but as I saw the demos, I think they add pretty of realism and feeling to the scene. David Whatley wrote: > Does anyone have any reference to a lighting equation that is better > than N.L for direct sunlight? The problem with N.L is that when the > light hits the surface direct on, the color at the pixel is exactly > that of the texel. But you never get any additional contribution from > the light source. > > Specular doesn't help as much as I'd like because if you use that, you > start to get everything looking glossy which isn't natural either. > > I'm already doing a highpass filter into a glow buffer and all that, > but getting things bright enough in the first place to look like they > are "bathed in sunlight" just seems to be a real problem.... nothing > much will pass the highpass filter in the first place. > > I'm experimenting with simply allowing L to be a value greater than 1 > (for brighter light) but not sure if I'm on the right track with > that. Ideas? > > -- David > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > |
From: Richard M. <mi...@tr...> - 2005-11-17 19:32:00
|
I've always found a dull specular worked OK. I'd recommend getting a copy of Burnout 2 for reference, there's some lovely shiny roads and buildings in that. -- ()() Richard Mitton ( '.') (")_(") code jester .:. treyarch .:. mi...@tr... ----- Original Message ----- From: "David Whatley" <da...@pl...> To: <gda...@li...> Sent: Thursday, November 17, 2005 11:20 am Subject: [Algorithms] Direct Sunlight Lighting Model > Does anyone have any reference to a lighting equation that is better than > N.L for direct sunlight? The problem with N.L is that when the light hits > the surface direct on, the color at the pixel is exactly that of the > texel. But you never get any additional contribution from the light > source. > > Specular doesn't help as much as I'd like because if you use that, you > start to get everything looking glossy which isn't natural either. > > I'm already doing a highpass filter into a glow buffer and all that, but > getting things bright enough in the first place to look like they are > "bathed in sunlight" just seems to be a real problem.... nothing much will > pass the highpass filter in the first place. > > I'm experimenting with simply allowing L to be a value greater than 1 (for > brighter light) but not sure if I'm on the right track with that. Ideas? > > -- David > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Jon W. <hp...@mi...> - 2005-11-17 20:05:21
|
> Does anyone have any reference to a lighting equation that is better > than N.L for direct sunlight? The problem with N.L is that when the > light hits the surface direct on, the color at the pixel is exactly that > of the texel. But you never get any additional contribution from the > light source. That's typically how light interaction is modeled. If you want a black surface to have a little bit of light on it, make it not black, but dark gray. > Specular doesn't help as much as I'd like because if you use that, you > start to get everything looking glossy which isn't natural either. That's because specular models glossiness, not diffuse color. > I'm experimenting with simply allowing L to be a value greater than 1 > (for brighter light) but not sure if I'm on the right track with that. > Ideas? That sounds about right -- you can do this with shaders, but the fixed function pipe will clamp to 1.0. If you want to move away from the Phong/Blinn-like models that our hardware approximates, you can look into the various other BRDF approximations that exist -- the ones based on spherical harmonics are especially interesting. However, the biggest problem is that you want to model a high-contrast scene using the very low-contrast dynamic range of 8 bit colors. With HDR and tone mapping, that would be much easier. One trick you could do is set the gamma ramp of the display to make 128 be the brightest (and lose one bit of precision); I think some versions of Quake used to do that for over-brightness. Cheers, / h+ -- -- The early bird gets the worm, but the second mouse gets the cheese. |
From: Paul J. <pa...@ap...> - 2005-11-17 20:58:00
|
Hi. I've been thinking of upgrading my rendering pipeline to support HDR properly as opposed to just having some dodgy alpha-bloom effect as a post-process. Setting up a fat format rendertarget is doable on my target hardware level, but with no alpha-blending, I got no clue how to do decent lighting and shadows (that require multipass - no SM3 for me). This has confused me a bit as I see people referring to "fake" HDR, but in reality it's not fake at all - using an 8888 format for the rendertarget is your only option for a realistic scene (ie one with more than one light and maybe even some translucent windows) so "fake" is all you can really do AIUI. If that really is the case, where does tone-mapping fit in. So, am I missing something here ? Got a resource on the net that explains how to *actually* implement proper HDR as opposed to the "I can do a bloom effect too" brigade ? I have seen some interesting articles about tone-mapping as a final pass, but they never seem to explain how they fill their scene up in the first place. Many thanks... Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. www.rubiconmobile.com |
From: Jonathan B. <jo...@nu...> - 2005-11-17 22:16:48
|
If you need alpha blending (and most people do), you just can't do a reasonable game with HDR, even on cards that have deep render targets, if it doesn't support alpha blending on those targets. I switched a project away from the X800 to a different card for exactly this reason. Even so, you shouldn't need SM3 to do decent lighting and shadows. Multipass is not necessary for most things if you are allowed to have reasonably long SM2 shaders. In any case, "real" HDR is only generally useful on a subset of the high-end PC graphics cards, and on the next generation of consoles (Lots of those games use real HDR). Paul Johnson wrote: > Hi. I've been thinking of upgrading my rendering pipeline to support HDR > properly as opposed to just having some dodgy alpha-bloom effect as a > post-process. > > Setting up a fat format rendertarget is doable on my target hardware > level, > but with no alpha-blending, I got no clue how to do decent lighting and > shadows (that require multipass - no SM3 for me). This has confused me > a bit > as I see people referring to "fake" HDR, but in reality it's not fake at > all - using an 8888 format for the rendertarget is your only option for a > realistic scene (ie one with more than one light and maybe even some > translucent windows) so "fake" is all you can really do AIUI. If that > really > is the case, where does tone-mapping fit in. > > So, am I missing something here ? Got a resource on the net that > explains > how to *actually* implement proper HDR as opposed to the "I can do a > bloom > effect too" brigade ? I have seen some interesting articles about > tone-mapping as a final pass, but they never seem to explain how they > fill > their scene up in the first place. > > Many thanks... > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > www.rubiconmobile.com > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Richard M. <mi...@tr...> - 2005-11-17 22:26:33
|
One possibility is to convert your alpha value into a pixel coverage value, and then rely on the MSAA to convert that stipple pattern back into an approximation of an alpha blend. May or may not give acceptable results, but I just thought I'd point it out. (also has the advantage that you don't need to sort-by-transparency) -- ()() Richard Mitton ( '.') (")_(") code jester .:. treyarch .:. mi...@tr... ----- Original Message ----- From: "Jonathan Blow" <jo...@nu...> To: <gda...@li...> Sent: Thursday, November 17, 2005 2:16 pm Subject: Re: [Algorithms] HDR translucency > If you need alpha blending (and most people do), you just can't do a > reasonable game with HDR, even on cards that have deep render targets, if > it doesn't support alpha blending on those targets. > > I switched a project away from the X800 to a different card for exactly > this reason. > > Even so, you shouldn't need SM3 to do decent lighting and shadows. > Multipass is not necessary for most things if you are allowed to have > reasonably long SM2 shaders. > > In any case, "real" HDR is only generally useful on a subset of the > high-end PC graphics cards, and on the next generation of consoles (Lots > of those games use real HDR). > > > Paul Johnson wrote: > >> Hi. I've been thinking of upgrading my rendering pipeline to support HDR >> properly as opposed to just having some dodgy alpha-bloom effect as a >> post-process. >> >> Setting up a fat format rendertarget is doable on my target hardware >> level, >> but with no alpha-blending, I got no clue how to do decent lighting and >> shadows (that require multipass - no SM3 for me). This has confused me a >> bit >> as I see people referring to "fake" HDR, but in reality it's not fake at >> all - using an 8888 format for the rendertarget is your only option for a >> realistic scene (ie one with more than one light and maybe even some >> translucent windows) so "fake" is all you can really do AIUI. If that >> really >> is the case, where does tone-mapping fit in. >> >> So, am I missing something here ? Got a resource on the net that >> explains >> how to *actually* implement proper HDR as opposed to the "I can do a >> bloom >> effect too" brigade ? I have seen some interesting articles about >> tone-mapping as a final pass, but they never seem to explain how they >> fill >> their scene up in the first place. >> >> Many thanks... >> >> Regards, >> Paul Johnson. >> >> Managing Director, >> Rubicon Mobile, Ltd. >> www.rubiconmobile.com >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Paul J. <pa...@ap...> - 2005-11-18 00:06:45
|
That might actually be worth a hack :) Thanks for this and to the others who also responded. I guess I might give this a go after all, but keep it strictly on the back-burner in case the above doesn't work out too well. Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. www.rubiconmobile.com ----- Original Message ----- From: "Richard Mitton" <mi...@tr...> To: <gda...@li...> Sent: Thursday, November 17, 2005 10:26 PM Subject: Re: [Algorithms] HDR translucency > One possibility is to convert your alpha value into a pixel coverage > value, and then rely on the MSAA to convert that stipple pattern back into > an approximation of an alpha blend. > > May or may not give acceptable results, but I just thought I'd point it > out. > (also has the advantage that you don't need to sort-by-transparency) > > -- > ()() Richard Mitton > ( '.') > (")_(") code jester .:. treyarch .:. mi...@tr... > > > ----- Original Message ----- > From: "Jonathan Blow" <jo...@nu...> > To: <gda...@li...> > Sent: Thursday, November 17, 2005 2:16 pm > Subject: Re: [Algorithms] HDR translucency > > >> If you need alpha blending (and most people do), you just can't do a >> reasonable game with HDR, even on cards that have deep render targets, if >> it doesn't support alpha blending on those targets. >> >> I switched a project away from the X800 to a different card for exactly >> this reason. >> >> Even so, you shouldn't need SM3 to do decent lighting and shadows. >> Multipass is not necessary for most things if you are allowed to have >> reasonably long SM2 shaders. >> >> In any case, "real" HDR is only generally useful on a subset of the >> high-end PC graphics cards, and on the next generation of consoles (Lots >> of those games use real HDR). >> >> >> Paul Johnson wrote: >> >>> Hi. I've been thinking of upgrading my rendering pipeline to support >>> HDR >>> properly as opposed to just having some dodgy alpha-bloom effect as a >>> post-process. >>> >>> Setting up a fat format rendertarget is doable on my target hardware >>> level, >>> but with no alpha-blending, I got no clue how to do decent lighting and >>> shadows (that require multipass - no SM3 for me). This has confused me a >>> bit >>> as I see people referring to "fake" HDR, but in reality it's not fake at >>> all - using an 8888 format for the rendertarget is your only option for >>> a >>> realistic scene (ie one with more than one light and maybe even some >>> translucent windows) so "fake" is all you can really do AIUI. If that >>> really >>> is the case, where does tone-mapping fit in. >>> >>> So, am I missing something here ? Got a resource on the net that >>> explains >>> how to *actually* implement proper HDR as opposed to the "I can do a >>> bloom >>> effect too" brigade ? I have seen some interesting articles about >>> tone-mapping as a final pass, but they never seem to explain how they >>> fill >>> their scene up in the first place. >>> >>> Many thanks... >>> >>> Regards, >>> Paul Johnson. >>> >>> Managing Director, >>> Rubicon Mobile, Ltd. >>> www.rubiconmobile.com >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>> Register for a JBoss Training Course. Free Certification Exam >>> for All Training Attendees Through End of 2005. For more info visit: >>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Richard M. <mi...@tr...> - 2005-11-18 00:20:58
|
Certain consoles have an API render state to do this directly. I'm not sure if there is one on DX/OpenGL etc. If not, you can always run the alpha value through your own dither-matrix texture and use that instead. Of course, if you're using 4xMSAA, that only gives you 5 levels of transparency.... might be enough though. You might be able to hack some more in by using a larger dither matrix. Oh, and the whole thing also relies on the card being able to do HDR *and* MSAA. :-) I've never actually tried doing any of this, so let me know how it goes :-) -- ()() Richard Mitton ( '.') (")_(") code jester .:. treyarch .:. mi...@tr... ----- Original Message ----- From: "Paul Johnson" <pa...@ap...> To: <gda...@li...> Sent: Thursday, November 17, 2005 3:54 pm Subject: Re: [Algorithms] HDR translucency > That might actually be worth a hack :) > > Thanks for this and to the others who also responded. I guess I might give > this a go after all, but keep it strictly on the back-burner in case the > above doesn't work out too well. > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > www.rubiconmobile.com > > ----- Original Message ----- > From: "Richard Mitton" <mi...@tr...> > To: <gda...@li...> > Sent: Thursday, November 17, 2005 10:26 PM > Subject: Re: [Algorithms] HDR translucency > > >> One possibility is to convert your alpha value into a pixel coverage >> value, and then rely on the MSAA to convert that stipple pattern back >> into an approximation of an alpha blend. >> >> May or may not give acceptable results, but I just thought I'd point it >> out. >> (also has the advantage that you don't need to sort-by-transparency) >> >> -- >> ()() Richard Mitton >> ( '.') >> (")_(") code jester .:. treyarch .:. mi...@tr... >> >> >> ----- Original Message ----- >> From: "Jonathan Blow" <jo...@nu...> >> To: <gda...@li...> >> Sent: Thursday, November 17, 2005 2:16 pm >> Subject: Re: [Algorithms] HDR translucency >> >> >>> If you need alpha blending (and most people do), you just can't do a >>> reasonable game with HDR, even on cards that have deep render targets, >>> if it doesn't support alpha blending on those targets. >>> >>> I switched a project away from the X800 to a different card for exactly >>> this reason. >>> >>> Even so, you shouldn't need SM3 to do decent lighting and shadows. >>> Multipass is not necessary for most things if you are allowed to have >>> reasonably long SM2 shaders. >>> >>> In any case, "real" HDR is only generally useful on a subset of the >>> high-end PC graphics cards, and on the next generation of consoles (Lots >>> of those games use real HDR). >>> >>> >>> Paul Johnson wrote: >>> >>>> Hi. I've been thinking of upgrading my rendering pipeline to support >>>> HDR >>>> properly as opposed to just having some dodgy alpha-bloom effect as a >>>> post-process. >>>> >>>> Setting up a fat format rendertarget is doable on my target hardware >>>> level, >>>> but with no alpha-blending, I got no clue how to do decent lighting and >>>> shadows (that require multipass - no SM3 for me). This has confused me >>>> a bit >>>> as I see people referring to "fake" HDR, but in reality it's not fake >>>> at >>>> all - using an 8888 format for the rendertarget is your only option for >>>> a >>>> realistic scene (ie one with more than one light and maybe even some >>>> translucent windows) so "fake" is all you can really do AIUI. If that >>>> really >>>> is the case, where does tone-mapping fit in. >>>> >>>> So, am I missing something here ? Got a resource on the net that >>>> explains >>>> how to *actually* implement proper HDR as opposed to the "I can do a >>>> bloom >>>> effect too" brigade ? I have seen some interesting articles about >>>> tone-mapping as a final pass, but they never seem to explain how they >>>> fill >>>> their scene up in the first place. >>>> >>>> Many thanks... >>>> >>>> Regards, >>>> Paul Johnson. >>>> >>>> Managing Director, >>>> Rubicon Mobile, Ltd. >>>> www.rubiconmobile.com >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>>> Register for a JBoss Training Course. Free Certification Exam >>>> for All Training Attendees Through End of 2005. For more info visit: >>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>>> _______________________________________________ >>>> GDAlgorithms-list mailing list >>>> GDA...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>> Archives: >>>> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>> Register for a JBoss Training Course. Free Certification Exam >>> for All Training Attendees Through End of 2005. For more info visit: >>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Paul J. <pa...@ap...> - 2005-11-17 22:55:44
|
Thanks for that Jonathan, I guess I can stop dreaming about this for a while then! My target audience is mainly X360 live arcade, but I won't be doing "Halo 4" quality games and I want to keep the renderer running on more sensible hardware on PC so I can show demos and allow our guys to develop on pretty much any card in their pc, like when they work from home. Almost all other effects that I could make better with SM3 wouldn't be missed by just being turned off on lower cards, but a buggered scene draw isn't gonna cut it. I really just wanted to try it out and see what results I could get, but the downside in my case is too great, which is a shame. Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. www.rubiconmobile.com ----- Original Message ----- From: "Jonathan Blow" <jo...@nu...> To: <gda...@li...> Sent: Thursday, November 17, 2005 10:16 PM Subject: Re: [Algorithms] HDR translucency > If you need alpha blending (and most people do), you just can't do a > reasonable game with HDR, even on cards that have deep render targets, if > it doesn't support alpha blending on those targets. > > I switched a project away from the X800 to a different card for exactly > this reason. > > Even so, you shouldn't need SM3 to do decent lighting and shadows. > Multipass is not necessary for most things if you are allowed to have > reasonably long SM2 shaders. > > In any case, "real" HDR is only generally useful on a subset of the > high-end PC graphics cards, and on the next generation of consoles (Lots > of those games use real HDR). > > > Paul Johnson wrote: > >> Hi. I've been thinking of upgrading my rendering pipeline to support HDR >> properly as opposed to just having some dodgy alpha-bloom effect as a >> post-process. >> >> Setting up a fat format rendertarget is doable on my target hardware >> level, >> but with no alpha-blending, I got no clue how to do decent lighting and >> shadows (that require multipass - no SM3 for me). This has confused me a >> bit >> as I see people referring to "fake" HDR, but in reality it's not fake at >> all - using an 8888 format for the rendertarget is your only option for a >> realistic scene (ie one with more than one light and maybe even some >> translucent windows) so "fake" is all you can really do AIUI. If that >> really >> is the case, where does tone-mapping fit in. >> >> So, am I missing something here ? Got a resource on the net that >> explains >> how to *actually* implement proper HDR as opposed to the "I can do a >> bloom >> effect too" brigade ? I have seen some interesting articles about >> tone-mapping as a final pass, but they never seem to explain how they >> fill >> their scene up in the first place. >> >> Many thanks... >> >> Regards, >> Paul Johnson. >> >> Managing Director, >> Rubicon Mobile, Ltd. >> www.rubiconmobile.com >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Jonathan B. <jo...@nu...> - 2005-11-17 23:31:46
|
For most of development I used a laptop, which you can imagine didn't support alpha blending on deep render targets. For that I just wrote a quick fallback mode that would just do all the regular HDR stuff, but with an 8-bits-per-channel target instead of the usual deep one. Banding was horrible, but hey, it worked, and alpha blending worked, and I could develop the game. Of course I couldn't do this when I was actually working on graphics quality issues or tuning how things looked, but that was a minority of the time. For demos... yeah, you probably don't want to show them like that. Paul Johnson wrote: > Thanks for that Jonathan, I guess I can stop dreaming about this for a > while then! > > My target audience is mainly X360 live arcade, but I won't be doing > "Halo 4" quality games and I want to keep the renderer running on more > sensible hardware on PC so I can show demos and allow our guys to > develop on pretty much any card in their pc, like when they work from > home. Almost all other effects that I could make better with SM3 > wouldn't be missed by just being turned off on lower cards, but a > buggered scene draw isn't gonna cut it. > > I really just wanted to try it out and see what results I could get, > but the downside in my case is too great, which is a shame. > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > www.rubiconmobile.com > > ----- Original Message ----- From: "Jonathan Blow" <jo...@nu...> > To: <gda...@li...> > Sent: Thursday, November 17, 2005 10:16 PM > Subject: Re: [Algorithms] HDR translucency > > >> If you need alpha blending (and most people do), you just can't do a >> reasonable game with HDR, even on cards that have deep render >> targets, if it doesn't support alpha blending on those targets. >> >> I switched a project away from the X800 to a different card for >> exactly this reason. >> >> Even so, you shouldn't need SM3 to do decent lighting and shadows. >> Multipass is not necessary for most things if you are allowed to have >> reasonably long SM2 shaders. >> >> In any case, "real" HDR is only generally useful on a subset of the >> high-end PC graphics cards, and on the next generation of consoles >> (Lots of those games use real HDR). >> >> >> Paul Johnson wrote: >> >>> Hi. I've been thinking of upgrading my rendering pipeline to >>> support HDR >>> properly as opposed to just having some dodgy alpha-bloom effect as a >>> post-process. >>> >>> Setting up a fat format rendertarget is doable on my target hardware >>> level, >>> but with no alpha-blending, I got no clue how to do decent lighting and >>> shadows (that require multipass - no SM3 for me). This has confused >>> me a bit >>> as I see people referring to "fake" HDR, but in reality it's not >>> fake at >>> all - using an 8888 format for the rendertarget is your only option >>> for a >>> realistic scene (ie one with more than one light and maybe even some >>> translucent windows) so "fake" is all you can really do AIUI. If >>> that really >>> is the case, where does tone-mapping fit in. >>> >>> So, am I missing something here ? Got a resource on the net that >>> explains >>> how to *actually* implement proper HDR as opposed to the "I can do a >>> bloom >>> effect too" brigade ? I have seen some interesting articles about >>> tone-mapping as a final pass, but they never seem to explain how >>> they fill >>> their scene up in the first place. >>> >>> Many thanks... >>> >>> Regards, >>> Paul Johnson. >>> >>> Managing Director, >>> Rubicon Mobile, Ltd. >>> www.rubiconmobile.com >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >>> Register for a JBoss Training Course. Free Certification Exam >>> for All Training Attendees Through End of 2005. For more info visit: >>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Will V. <wi...@se...> - 2005-11-17 22:30:51
|
I'm still quite a fan of the bloom effects, provided you use dest alpha to select bright objects it can look quite good, and is another way of faking HDR. But since CG is all fake anyway, it doesn't really matter what you do so long as the end result pleases the audience. (That said, I don't really like the 'bloom everything brighter than 220' approach, although there are games where it makes visual sense.) To do it 'properly' using an 8888 buffer, you could use the RGBE format (RGB + exponent) with the exponent in the alpha channel of the buffer. So you unpack every time you read a colour value, and pack before you write it. Once you've got the unpacked colours in the shader you can use full precision. I imagine that alpha blending would still be a problem though, because using a linear blend on the exponent wouldn't really be correct. Might look OK though. I seem to recall reading about an implementation of this a few years ago on Masa Kawase's site: http://www.daionet.gr.jp/~masa/ I've certainly implemented 'real' HDR with tonemapping on Shader Model 2 hardware, but I didn't support transparency (it was a technical exercise more than a game demo) Lighting was with PRT * HDR skybox for indirect lights and a distant sunlight for direct, and a tonemap was indeed required to format the floating point intensities for display on an 8-bit RGB device. You can see what it might look like here: http://www.secondintention.com/business/portfolio/worldlight/ > So, am I missing something here ? Got a resource on the net that explains > how to *actually* implement proper HDR as opposed to the "I can do a bloom > effect too" brigade ? All it *really* requires is that you can feed arbitrary numbers (greater than one) into your lighting pipeline (so light intensities should be floats) and that you can represent similar values in an intermediate buffer. Often a 16-bit RGB format, but you can also use packed formats. Tonemapping of some kind will be required to present these values for display. If you're doing multipass lighting or alpha blended transparency it's obviously going to help if you can use alpha blending with this buffer. This isn't a shader model 3 feature, but it isn't something which is supported on all that many cards prior to the current generation. However you can always replace a true read-modifiy-write blend with a ping pong. i.e. Write light 1 to buffer 1 Read light 1 from buffer 1 and add light 2, write total to buffer 2 Read lights 1+2 from buffer 2 and add light 3, write total to buffer 1 etc. HTH, Will Vale |
From: Zulfiqar M. <zul...@gm...> - 2005-11-18 05:04:36
|
HDR (with tone mapping) would definitely do you good. However if you want t= o stick to 8 bit colors then can sort of "fake HDR" by doing a post-process pass which filters out pixels above a specified range. You can then additively blend that texture over the frame buffer to over-brighten the scene. This will give you a nice contrast between bright and dark areas. Yo= u can optionally use bloom filter (using seperable guassian blur or some othe= r blurring technique) to give a nice look to the scene. The overbrighting pas= s need not use a full resolution texture which can give you a bit of speed up with lower memory requirements. However, already bright pixels might over brighten too much (giving a burned out feel which might not look for some surfaces), so you have to adjust your filtering according to the scene. It might take a bit of testing. @Jon: You are right. Quake III Arena does use the gamma ramp technique to overbrighten the scene. -- Regards, Zulfiqar Inayat Malik. |
From: David W. <da...@pl...> - 2005-11-19 02:24:04
|
This is, in fact, what we are doing. But we didn't really get very good results until we allowed the light values to extend past 1.0. Looks like we need some texture balancing though... the problem being that places painted "white" can blow out when it really shouldn't. So I guess we have to adjust the textures so white is like 80% grey or something. -- David Zulfiqar Malik wrote: > HDR (with tone mapping) would definitely do you good. However if you > want to stick to 8 bit colors then can sort of "fake HDR" by doing a > post-process pass which filters out pixels above a specified range. > You can then additively blend that texture over the frame buffer to > over-brighten the scene. This will give you a nice contrast between > bright and dark areas. You can optionally use bloom filter (using > seperable guassian blur or some other blurring technique) to give a > nice look to the scene. The overbrighting pass need not use a full > resolution texture which can give you a bit of speed up with lower > memory requirements. However, already bright pixels might over > brighten too much (giving a burned out feel which might not look for > some surfaces), so you have to adjust your filtering according to the > scene. It might take a bit of testing. > > @Jon: You are right. Quake III Arena does use the gamma ramp technique > to overbrighten the scene. > > -- > Regards, > Zulfiqar Inayat Malik. > |
From: Zulfiqar M. <zul...@gm...> - 2005-11-19 06:52:02
|
Yeah, you will have to do that. You can also look into doing HDR using RGBE which is doable on even older hardware. On 11/19/05, David Whatley <da...@pl...> wrote: > > This is, in fact, what we are doing. But we didn't really get very good > results until we allowed the light values to extend past 1.0. Looks > like we need some texture balancing though... the problem being that > places painted "white" can blow out when it really shouldn't. So I > guess we have to adjust the textures so white is like 80% grey or > something. > > -- David > > > Zulfiqar Malik wrote: > > > HDR (with tone mapping) would definitely do you good. However if you > > want to stick to 8 bit colors then can sort of "fake HDR" by doing a > > post-process pass which filters out pixels above a specified range. > > You can then additively blend that texture over the frame buffer to > > over-brighten the scene. This will give you a nice contrast between > > bright and dark areas. You can optionally use bloom filter (using > > seperable guassian blur or some other blurring technique) to give a > > nice look to the scene. The overbrighting pass need not use a full > > resolution texture which can give you a bit of speed up with lower > > memory requirements. However, already bright pixels might over > > brighten too much (giving a burned out feel which might not look for > > some surfaces), so you have to adjust your filtering according to the > > scene. It might take a bit of testing. > > > > @Jon: You are right. Quake III Arena does use the gamma ramp technique > > to overbrighten the scene. > > > > -- > > Regards, > > Zulfiqar Inayat Malik. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > -- Regards, Zulfiqar Inayat Malik. |
From: David W. <da...@pl...> - 2005-11-19 17:11:09
|
You mean use RGBE for the textures? I'm not sure what that would buy me if I'm not using float point buffers. -- David Zulfiqar Malik wrote: > Yeah, you will have to do that. You can also look into doing HDR using > RGBE which is doable on even older hardware. > > On 11/19/05, *David Whatley* < da...@pl... <mailto:da...@pl...>> > wrote: > > This is, in fact, what we are doing. But we didn't really get > very good > results until we allowed the light values to extend past 1.0. Looks > like we need some texture balancing though... the problem being that > places painted "white" can blow out when it really shouldn't. So I > guess we have to adjust the textures so white is like 80% grey or > something. > > -- David > > > Zulfiqar Malik wrote: > > > HDR (with tone mapping) would definitely do you good. However if you > > want to stick to 8 bit colors then can sort of "fake HDR" by > doing a > > post-process pass which filters out pixels above a specified range. > > You can then additively blend that texture over the frame buffer to > > over-brighten the scene. This will give you a nice contrast between > > bright and dark areas. You can optionally use bloom filter (using > > seperable guassian blur or some other blurring technique) to give a > > nice look to the scene. The overbrighting pass need not use a full > > resolution texture which can give you a bit of speed up with lower > > memory requirements. However, already bright pixels might over > > brighten too much (giving a burned out feel which might not look > for > > some surfaces), so you have to adjust your filtering according > to the > > scene. It might take a bit of testing. > > > > @Jon: You are right. Quake III Arena does use the gamma ramp > technique > > to overbrighten the scene. > > > > -- > > Regards, > > Zulfiqar Inayat Malik. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > <http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click> > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > <mailto:GDA...@li...> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > -- > Regards, > Zulfiqar Inayat Malik. |
From: Dan G. <dan...@gm...> - 2005-11-21 03:24:39
|
On 11/20/05, David Whatley <da...@pl...> wrote: > > You mean use RGBE for the textures? I'm not sure what that would buy me i= f > I'm not using float point buffers. > > -- David I think he means write RGBE into RGBA of the framebuffer, then do the tone mapping on that. Instead of running a luminance filter on the screen to get the bright parts, the lighting calculations store what is bright. From my understand of the ppt slides, this is how Wreckless worked. HTH DanG -- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras' |
From: Zulfiqar M. <zul...@gm...> - 2005-11-21 06:38:36
|
The basic idea is to do rendering in high dynamic range and instead of writing values outside the range 0 - 1 (since you are using 8-bit format) you write "scaled" values (each R, G and B channel is scaled with some factor such that all 3 end up in 0 - 1 range) and the common scaled factor (also called exponent) is written in the alpha channel (hence the name RGBE). A little bit more information in. You should be able to find more information. http://www.anyhere.com/gward/hdrenc/hdr_encodings.html I haven't used this format myself and hence don't know of its short comings= . One obvious short coming is that you lose the alpha channel. You can also look into the technique detailed by Humus in the following link http://www.humus.ca/index.php?page=3D3D Hope its useful. -Zul On 11/21/05, Dan Glastonbury <dan...@gm...> wrote: > > > On 11/20/05, David Whatley <da...@pl...> wrote: > > > > You mean use RGBE for the textures? I'm not sure what that would buy me > > if I'm not using float point buffers. > > > > -- David > > > I think he means write RGBE into RGBA of the framebuffer, then do the ton= e > mapping on that. Instead of running a luminance filter on the screen to g= et > the bright parts, the lighting calculations store what is bright. From my > understand of the ppt slides, this is how Wreckless worked. > > HTH > DanG > > -- > Dan Glastonbury, Dan dot Glastonbury at gmail dot com > `Pour encourjay lays ortras' > -- Regards, Zulfiqar Inayat Malik. |
From: Alen L. <ale...@cr...> - 2005-11-17 22:14:58
|
> Does anyone have any reference to a lighting equation that is better > than N.L for direct sunlight? The problem with N.L is that when the > light hits the surface direct on, the color at the pixel is exactly that > of the texel. But you never get any additional contribution from the > light source. > > Specular doesn't help as much as I'd like because if you use that, you > start to get everything looking glossy which isn't natural either. > > I'm already doing a highpass filter into a glow buffer and all that, but > getting things bright enough in the first place to look like they are > "bathed in sunlight" just seems to be a real problem.... nothing much > will pass the highpass filter in the first place. The problem is not in the lighing equation, but in the fact that you want some overexposure. If you can afford HDR, that will come by itself. If you are stuck with 32bit render targets, for the "bathed in the sunlight" effect, I recommend using multiply x2 to apply light to the texture. It is even doable on fixed function with SRC*DST+DST*SRC blending mode for lightmaps. Then just scale the light's value down a bit. Light colors above 0.5 will then give you that extra white you are looking for. It will clamp, but that's more or less what you'd get after overexposing a HDR image. It looks really good in practice. HTH, Alen |