Thread: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo
Brought to you by:
vexxed72
From: Sébastien L. <seb...@do...> - 2010-01-29 15:54:25
|
Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Jon W. <jw...@gm...> - 2010-01-30 00:38:43
|
I don't quite understand your coupling between harmonic orders and coefficients. If I remember correctly, spherical harmonics of order 0 is a flat value -- 1 coefficient. Order 1 adds three cardinal directions -- 3 additional coefficients, for a total of 4. Order 2 adds another 5, for a total of 9. Order 3 adds another 7, for a total of 16. Order 4 adds another 9, for a total of 25. ... You may be able to omit the constant term (calculating it or assuming it) which would get a total harmonic count for order 3 of 15. Perhaps that's where the number comes from (but I have not had time to check the paper, just guessing here). Generally, if you separate out the diffuse/ambient reflection/albedo texture to a "regular" texture, you don't need to store the light response in RGB channels, just like you don't use different light fall-off equations for the different color channels. (Except when you do Rayleigh scattering and similar for atmospherics, I think...) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. 2010/1/29 Sébastien Lagarde <seb...@do...> > Hello all, > > > > I tried to contact the author of this two (now old) paper, without > success,: > > "Lighting and Material of Halo 3" published at siggraph 2008 ( > http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf > ) > > and GDC 2008 conference "Lightmap compression in Halo 3" ( > http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) > > so I will ask some question to the list, if anyone is interested by the > subject and has better understanding of math than me :) > > > > 1. "Lighting and Material of Halo 3" About equation (5) the diffuse > reflectance using SH basis > > the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i > > A_i is the projection of the cosine lobe in SH, and as it is radially > symetric. > > all coefficient with m != 0 are 0. > > After that the author give the first three term of A_i. > > I wondering how many band are use for this calculation ? (order 3, 4 or > more ?) > > > > I read from "Stupid spherical harmonics tricks" from Perter Pike sloan ( > http://www.ppsloan.org/publications/StupidSH36.pdf) > > that order 3 SH is sufficient for approximate light source > > but for HDR light sources he recommand order 5. > > As order 4 is 0 (From paper > http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for > A_i) > > This mean 4 coefficient to store by color channel. > > As I am pretty sure the author store HDR data, can someone lighten me ? > > > > 2. About texture storage (which are deduced from above statement) > > > > I try to figure out how are encoded the incident radiance in their > SHLightmap. > > From GDC 2008 conference "Lightmap compression in Halo 3" I can read that > the author need to > > store for each texel a vector of 5 * 3 float values. > > I don't figure what are the values exactly. > > > > My assumption is that "3" is for each channel color RGB, > > But I can't figure what's the 5 is ? > > Are they 5 first band of SH order like I suppose above (but as I said, we > only need 4 coefficient in this case) > > or maybe order 6 ? > > > > In this same paper later I found: > > A. Two DXT5 texture for each SH coefficient channel (HDR, > positive/negative) > > And > > B. Each band of the SH coefficients (RGB) are converted to Luvw space > > > > I suppose that Luvw space is what is describe in this paper "Rendering from > Compressed High Dynamic Range Textures on > > Programmable Graphics Hardware" by Peter Pike sloan and al.( > ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) > > > > What I don't understand is that A and B seem different. I can't understand > what is store. > > Are they storing for each band the triplet RGB of SH coeeficient, mean 3 > float value for two DXT5 x order > > or do they store store 5 SH coefficient for channel color R in two DXT5 ? > > > > So what are the total storage cost of all the 5 * 3 float value in term of > DXT5 texture ? > > Cause It looks like to be pretty big. > > > > Thanks for anyone interested by this post > > > > Best regards > > > > Lagarde Sébastien > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |
From: Sébastien L. <seb...@do...> - 2010-02-01 12:42:01
|
Yes, in fact I was not clear, I will sum up my questions :) And yes you remember correctly. Question: What SH order Halo 3 uses for their SH lightmap (2 (4 coeff), 3 (9 coeff), 4 (16 coeff) ), 5 (25 coeff) etc...) ? And what are the value stored ? From the paper, it seems that they store HDR RGB value. So multiply the number of SH coefficient by 3 but they only need to store the integration of the diffuse equation (5) in the paper "lighting and material in halo 3" which contain the projection of the cosine lobe in SH, which is radially symmetric. Mean that only zonal harmonic coefficient matter (all coefficient with m != 0 are 0). So this reduce the number of SH coefficient depend on the order: (2 (2 coeff), 3 (3 coeff), 4 (3 coeff) ), 5 (4 coeff) etc...) (note that order 4 zonal harmonic is 0) So if halo 3 store 3 SH order for RGB we get: 3 *3 = 9 colored SH coefficient and for order 4 : 3 * 4 = 12 colored SH coefficient but they saisd that they store 5 * 3 float value, so I am lost. What represent this float value ? Thanks you for any advice :) Lagarde Sébastien De : Jon Watte [mailto:jw...@gm...] Envoyé : samedi 30 janvier 2010 01:46 À : Game Development Algorithms Objet : Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3" I don't quite understand your coupling between harmonic orders and coefficients. If I remember correctly, spherical harmonics of order 0 is a flat value -- 1 coefficient. Order 1 adds three cardinal directions -- 3 additional coefficients, for a total of 4. Order 2 adds another 5, for a total of 9. Order 3 adds another 7, for a total of 16. Order 4 adds another 9, for a total of 25. ... You may be able to omit the constant term (calculating it or assuming it) which would get a total harmonic count for order 3 of 15. Perhaps that's where the number comes from (but I have not had time to check the paper, just guessing here). Generally, if you separate out the diffuse/ambient reflection/albedo texture to a "regular" texture, you don't need to store the light response in RGB channels, just like you don't use different light fall-off equations for the different color channels. (Except when you do Rayleigh scattering and similar for atmospherics, I think...) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. 2010/1/29 Sébastien Lagarde <seb...@do...> Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
From: Sam M. <sam...@ge...> - 2010-02-01 15:06:52
|
I can’t help you with the “what sh order halo 3..” question, but I think there’s a bit of confusion over the zonal harmonic part. Convolving an arbitrary SH (e.g. your input lighting) against a clamped cosine SH (for the diffuse integral - which is radially symmetric) does not produce a radially symmetric SH. But it does greatly reduce the need for higher order coefficients. Diffuse lighting is very low frequency and in practice I’ve never found a need for more than L2, and L1 is often adequate for most purposes. “Zonal” harmonics, where m != 0 are 0, are a bit of a special case. I’m not sure how they are used in the paper you mentioned, but in general diffuse lighting over a sphere isn’t radially symmetric. Not sure if that helps or not! Ta, Sam From: Sébastien Lagarde [mailto:seb...@do...] Sent: 01 February 2010 12:23 To: Game Development Algorithms Subject: Re: [Algorithms] Some question about "Lighting and MaterialofHalo3" and "Lightmap compression in Halo 3" Yes, in fact I was not clear, I will sum up my questions :) And yes you remember correctly. Question: What SH order Halo 3 uses for their SH lightmap (2 (4 coeff), 3 (9 coeff), 4 (16 coeff) ), 5 (25 coeff) etc...) ? And what are the value stored ? From the paper, it seems that they store HDR RGB value. So multiply the number of SH coefficient by 3 but they only need to store the integration of the diffuse equation (5) in the paper "lighting and material in halo 3" which contain the projection of the cosine lobe in SH, which is radially symmetric. Mean that only zonal harmonic coefficient matter (all coefficient with m != 0 are 0). So this reduce the number of SH coefficient depend on the order: (2 (2 coeff), 3 (3 coeff), 4 (3 coeff) ), 5 (4 coeff) etc...) (note that order 4 zonal harmonic is 0) So if halo 3 store 3 SH order for RGB we get: 3 *3 = 9 colored SH coefficient and for order 4 : 3 * 4 = 12 colored SH coefficient but they saisd that they store 5 * 3 float value, so I am lost. What represent this float value ? Thanks you for any advice :) Lagarde Sébastien De : Jon Watte [mailto:jw...@gm...] Envoyé : samedi 30 janvier 2010 01:46 À : Game Development Algorithms Objet : Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3" I don't quite understand your coupling between harmonic orders and coefficients. If I remember correctly, spherical harmonics of order 0 is a flat value -- 1 coefficient. Order 1 adds three cardinal directions -- 3 additional coefficients, for a total of 4. Order 2 adds another 5, for a total of 9. Order 3 adds another 7, for a total of 16. Order 4 adds another 9, for a total of 25. ... You may be able to omit the constant term (calculating it or assuming it) which would get a total harmonic count for order 3 of 15. Perhaps that's where the number comes from (but I have not had time to check the paper, just guessing here). Generally, if you separate out the diffuse/ambient reflection/albedo texture to a "regular" texture, you don't need to store the light response in RGB channels, just like you don't use different light fall-off equations for the different color channels. (Except when you do Rayleigh scattering and similar for atmospherics, I think...) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. 2010/1/29 Sébastien Lagarde <seb...@do...> Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
From: Francis B. <fra...@ub...> - 2010-02-01 15:40:04
|
FWIW there here is a new compression scheme to be presented @ I3D 2010 http://www.cg.tuwien.ac.at/research/publications/2010/Habel-2010-EIN/ @inproceedings\{Habel-2010-EIN, title = "Efficient Irradiance Normal Mapping", author = "Ralf Habel and Michael Wimmer", year = "2010", abstract = "Irradiance normal mapping is a method to combine two popular techniques, light mapping and normal mapping, and is used in games such as Half-Life 2 or Halo 3. This combination allows using low-resolution light caching on surfaces with only a few coefficients which are evaluated by normal maps to render spatial high-frequency changes in the lighting. Though there are dedicated bases for this purpose such as the Half-Life 2 basis, higher order basis functions such as quadratic Spherical Harmonics are needed for an accurate representation. However, a full spherical basis is not needed since the irradiance is stored on the surface of a scene. In order to represent the irradiance signals efficiently, we propose a novel polynomial, hemispherically orthonormal basis function set that is specifically designed to carry a directional irradiance signal on the hemisphere and which makes optimal use of the number of coefficients. To compare our results with previous work, we analyze the relations and attributes of previously proposed basis systems and show that 6 coefficients are sufficient to accurately represent an irradiance signal on the hemisphere. To create the necessary irradiance signals, we use Spherical Harmonics as an intermediate basis due to their fast filtering capabilities.", pages = "%pages_from%--%pages_to%", month = feb, location = "Washington D.C.", booktitle = "Proceedings of I3D 2010", keywords = "real-time rendering, irradiance, lightmap, normal mapping", URL = "http://www.cg.tuwien.ac.at/research/publications/2010/Habel-2010-EIN/", } From: Sébastien Lagarde [mailto:seb...@do...] Sent: Friday, January 29, 2010 10:29 AM To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Peter-Pike S. <pet...@ho...> - 2010-02-01 21:44:52
|
Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Sébastien L. <seb...@do...> - 2010-02-05 17:23:01
|
I think halo wanted to store direct + indirect lighting in their SH lightmap, so they require L2 coeff , (if only indirect lighting was store L1 coeff will be sufficient) As RGB * 9 coeff = 27 float represent too much data to store in texture, they compress by converting the L2 coeff by L1 coeff + a directional light RGB You can find a similar conversion in "Stupid spherical harmonics tricks" section "Extracting Conventional Lights from SH" where an ambient light + directional light is extracted from SH coefficient. The difference here is that instead of using a conventional ambient light, the ambient light is the remaining L1 SH coefficient after removing the contribution of the directional light in the optimal linear direction (at least, I suppose they do that). You can find explanation and code of this in this paper: http://ati.amd.com/developer/SIGGRAPH08/Chapter03-SBOT-March_of_The_Froblins.pdf So to sum up, they get their L2 coeff, they calc the dominant light intensity RGB from them, they extract this dominant light intensity RGB from L2 coeff and discard quadratic coefficient to only conserve L1 coeff. So you get remaining L1 coeff RGB = 12 float and HDR dominant RGB = 3 float, this result in 15 float instead of the 27 initially which they claim of similar quality. At runtime, mesh are lighted by a RGB directional light as usual, and the L1 contribution is added to the diffuse part of the lighting. If you not compress, you light your mesh with L2 coeff directly (for the diffuse part). The point here is that they store the intensity RGB, they don't need to store "optimal linear" direction as it can be retrieve from L1 SH coeff. (at least, this is my question, if L1 coeff are remaining SH light, we won't get the same "optimal linear" direction, so I suppose they store the L1 SH light, and remove dominant RGB contribution in the shader, any though about this ?) Of course, all this is just guess. Peter ? Lagarde Sébastien De : Sam Martin [mailto:sam...@ge...] Envoyé : vendredi 5 février 2010 17:46 À : Game Development Algorithms Objet : Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3" Hi Peter, Do you have a link to a paper/slides explaining why they store an "optimal linear" direction separately? I'm not sure why you wouldn't want to just use the L1 coeffs as a vector? I couldn't find an explanation in the links below. Thanks, Sam From: Peter-Pike Sloan [mailto:pet...@ho...] Sent: 01 February 2010 21:45 To: gda...@li... Subject: Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan ________________________________ Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Nathaniel H. <na...@io...> - 2010-02-08 06:21:53
|
SIGGRAPH Talks are due on February 18, less than two weeks away. Submitting a talk proposal is actually quite easy. More details in a recent post on the Real-Time Rendering blog: http://www.realtimerendering.com/blog/game-developers-submit-a-siggraph-talk-before-february-18/ Thanks, Naty Hoffman |
From: Sébastien L. <seb...@do...> - 2010-02-03 09:44:15
|
Hi all, I take some time to try to fully understand what was saying :), I have increase my level of understanding, thanks to both of you Sam and David , I made the difference between incoming lighting and diffuse irradiance now, and better understand the convolution with cosine lobe. Alright for this part. Thanks to you Peter-Pike, for pointing the problem, in fact I didn't notice the rotation in local frame, and now I think I have more question than before :) I tried to understand what Halo 3 do cause this is a real XBOX360 shipped game with SH lighting in it with all console constraint on memory and shader performance. So I try to figure what tricks they used :) What I think now for halo 3 for their SH lightmap is: Incoming lighting generated by global illumination solver are projected in 9S H coefficient by color channel SH coefficient are rotated in tangent space Then they extract dominant light (intensity and direction). I suppose they store the DC + linear SH term , so 4 coefficient by channel, (as stated by Peter-Pike) And they store the intensity (RGB). This give the 5 * 3 float value At runtime, I suppose they used the linear SH term to retrieve the dominant light direction, the dominant light is used for the analytic cook torrance specular model. the dominant light should be used for diffuse part too: I think they need to extract dominant light intensity from SH, so they light with one diffuse directional light, and SH coefficient remaining after extraction of dominant light intensities. I think the extraction is done in shader and not in SH lightmap in order to be able to recover the right dominant light direction (I am certainly wrong :) ). But after that, I am lost with the rotation in local frame: I don't get the thing for the equation (5). which only require the 3 ZH coefficient. As my SH coefficient are store in tangent space, I am already in the case of equation (5). so I don't need to rotate SH coefficient once again (maybe I am wrong here, do I need to rotate with the tangent space normal extract from normal map ?), and so I only require SH coefficient for i = 0, 2, 6 ? The convolution by cosine lobe seems to be applied at this time, but two thing are missing, the constant: sqrt(4 pi / (2l + 1)) and the divide by PI to turn irradiance into the exit radiance. (But in their shader code provided, they divided lightprobe_color by Pi at end of diffuse_reflectance, so maybe they just not say it) But doing the convolution at this time mean that we store incoming lighting in SH lightmap, and not diffuse irradiance. So extracting dominant light from incoming lighting is maybe wrong ? Last though, with their 15 float to store, they said they used two DXT5 by SH band, mean we require 10 DXT5 to store only one lightmap. even if the compression get a 4:1 ratio, this require 10Mo for a SH lightmap of 1024x1024 without mipmap Which seems very huge for console memory even with a good streaming texture system... I am just curious about all these SH tricks, Anyway, thanks for the help you already provide to me. Lagarde Sébastien De : Peter-Pike Sloan [mailto:pet...@ho...] Envoyé : lundi 1 février 2010 22:46 À : gda...@li... Objet : Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan ________________________________ Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Sébastien L. <seb...@do...> - 2010-02-03 10:10:11
|
> even if the compression get a 4:1 ratio, => even if the compression get a 6:1 ratio, De : Sébastien Lagarde Envoyé : mercredi 3 février 2010 11:01 À : Game Development Algorithms Objet : Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3" Hi all, I take some time to try to fully understand what was saying :), I have increase my level of understanding, thanks to both of you Sam and David , I made the difference between incoming lighting and diffuse irradiance now, and better understand the convolution with cosine lobe. Alright for this part. Thanks to you Peter-Pike, for pointing the problem, in fact I didn't notice the rotation in local frame, and now I think I have more question than before :) I tried to understand what Halo 3 do cause this is a real XBOX360 shipped game with SH lighting in it with all console constraint on memory and shader performance. So I try to figure what tricks they used :) What I think now for halo 3 for their SH lightmap is: Incoming lighting generated by global illumination solver are projected in 9S H coefficient by color channel SH coefficient are rotated in tangent space Then they extract dominant light (intensity and direction). I suppose they store the DC + linear SH term , so 4 coefficient by channel, (as stated by Peter-Pike) And they store the intensity (RGB). This give the 5 * 3 float value At runtime, I suppose they used the linear SH term to retrieve the dominant light direction, the dominant light is used for the analytic cook torrance specular model. the dominant light should be used for diffuse part too: I think they need to extract dominant light intensity from SH, so they light with one diffuse directional light, and SH coefficient remaining after extraction of dominant light intensities. I think the extraction is done in shader and not in SH lightmap in order to be able to recover the right dominant light direction (I am certainly wrong :) ). But after that, I am lost with the rotation in local frame: I don't get the thing for the equation (5). which only require the 3 ZH coefficient. As my SH coefficient are store in tangent space, I am already in the case of equation (5). so I don't need to rotate SH coefficient once again (maybe I am wrong here, do I need to rotate with the tangent space normal extract from normal map ?), and so I only require SH coefficient for i = 0, 2, 6 ? The convolution by cosine lobe seems to be applied at this time, but two thing are missing, the constant: sqrt(4 pi / (2l + 1)) and the divide by PI to turn irradiance into the exit radiance. (But in their shader code provided, they divided lightprobe_color by Pi at end of diffuse_reflectance, so maybe they just not say it) But doing the convolution at this time mean that we store incoming lighting in SH lightmap, and not diffuse irradiance. So extracting dominant light from incoming lighting is maybe wrong ? Last though, with their 15 float to store, they said they used two DXT5 by SH band, mean we require 10 DXT5 to store only one lightmap. even if the compression get a 4:1 ratio, this require 10Mo for a SH lightmap of 1024x1024 without mipmap Which seems very huge for console memory even with a good streaming texture system... I am just curious about all these SH tricks, Anyway, thanks for the help you already provide to me. Lagarde Sébastien De : Peter-Pike Sloan [mailto:pet...@ho...] Envoyé : lundi 1 février 2010 22:46 À : gda...@li... Objet : Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan ________________________________ Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Sam M. <sam...@ge...> - 2010-02-05 16:32:52
|
Hi Peter, Do you have a link to a paper/slides explaining why they store an "optimal linear" direction separately? I'm not sure why you wouldn't want to just use the L1 coeffs as a vector? I couldn't find an explanation in the links below. Thanks, Sam From: Peter-Pike Sloan [mailto:pet...@ho...] Sent: 01 February 2010 21:45 To: gda...@li... Subject: Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan ________________________________ Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. >From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Peter-Pike S. <pet...@ho...> - 2010-02-06 16:25:04
|
I don't believe they do - the "5*3" numbers from the talk are (DC + linear + optimal_linear intensity) * 3 = (1 + 3 + 1)*3 I hope that makes sense... Peter-Pike Date: Fri, 5 Feb 2010 16:03:56 +0000 From: sam...@ge... To: gda...@li... Subject: Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi Peter, Do you have a link to a paper/slides explaining why they store an “optimal linear” direction separately? I’m not sure why you wouldn’t want to just use the L1 coeffs as a vector? I couldn’t find an explanation in the links below. Thanks, Sam From: Peter-Pike Sloan [mailto:pet...@ho...] Sent: 01 February 2010 21:45 To: gda...@li... Subject: Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hi, I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.) The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients. I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction. Which is 5*3 scalars.) The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used... Peter-Pike Sloan Date: Fri, 29 Jan 2010 16:28:57 +0100 From: seb...@do... To: gda...@li... Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3" Hello all, I tried to contact the author of this two (now old) paper, without success,: "Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf) and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf) so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :) 1. "Lighting and Material of Halo 3" About equation (5) the diffuse reflectance using SH basis the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i A_i is the projection of the cosine lobe in SH, and as it is radially symetric. all coefficient with m != 0 are 0. After that the author give the first three term of A_i. I wondering how many band are use for this calculation ? (order 3, 4 or more ?) I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf) that order 3 SH is sufficient for approximate light source but for HDR light sources he recommand order 5. As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i) This mean 4 coefficient to store by color channel. As I am pretty sure the author store HDR data, can someone lighten me ? 2. About texture storage (which are deduced from above statement) I try to figure out how are encoded the incident radiance in their SHLightmap. From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to store for each texel a vector of 5 * 3 float values. I don't figure what are the values exactly. My assumption is that "3" is for each channel color RGB, But I can't figure what's the 5 is ? Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case) or maybe order 6 ? In this same paper later I found: A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative) And B. Each band of the SH coefficients (RGB) are converted to Luvw space I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf) What I don't understand is that A and B seem different. I can't understand what is store. Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order or do they store store 5 SH coefficient for channel color R in two DXT5 ? So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ? Cause It looks like to be pretty big. Thanks for anyone interested by this post Best regards Lagarde Sébastien |
From: Zafar Q. <zaf...@co...> - 2010-04-12 16:02:40
|
Hi, I'm trying to do some fairly realistic-looking cloud-rendering, in a 3D game. These are the main requirements... 1) Have a high-cloud layer that can range from 0 to full coverage 2) Have lower clouds (sprites) that fade&roll in and out and move around and are "lit by the Sun", so the light can catch edges, and cause the other side to appear in shadow etc. 3) Have colours of the sky change, as the sun rises/sets etc Can anyone suggest any ideas/tips/tricks or links to help me in my quest? Your input would be very much appreciated. Cheers Zaf ********************************************************************************** Disclaimer The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** |
From: Jon W. <jw...@gm...> - 2010-04-12 16:49:44
|
A few years ago, when programmable shaders and multi-texturing-passes were novel, there was a lot written up on this. I remember a very in-depth article by Naty Hoffman on light scattering and how it affects color in haze, sunsets, etc. There are also cloud/sky/daylight models that you can buy and plug into your game or simulation, if you want very realistic effects. If you just want to fake it, then some combination of distance/elevation-based fog with a perturbation function, stand-in geometry that uses normal maps to simulate cloud roundness, and spherical lighting functions (clamp(1+NdotL) instead of clamp(NdotL), for example) is a quick-and-easy start. Elevation-based fog is typically implemented as two fog exponents, one for "above" and one for "below" the separating plane, and you calculate how far it travels within in each of the halves, and apply fog appropriately. Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Mon, Apr 12, 2010 at 8:11 AM, Zafar Qamar <zaf...@co...>wrote: > Hi, > > I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D > game. > > > > These are the main requirements... > > > > 1) Have a high-cloud layer that can range from 0 to full coverage > > 2) Have lower clouds (sprites) that fade&roll in and out and move > around and are “lit by the Sun”, so the light can catch edges, and cause the > other side to appear in shadow etc. > > 3) Have colours of the sky change, as the sun rises/sets etc > > > > Can anyone suggest any ideas/tips/tricks or links to help me in my quest? > > > > Your input would be very much appreciated. > > > > Cheers > > Zaf > |
From: Jim D. <jd...@ma...> - 2010-04-12 16:55:02
|
Hi, Since you are looking for links and ideas I'll drop my two cents (long time following the list, but this is my first post). 1) Cloud layer a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>: Old thread at gdnet but with some nice ideas. b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on Modern GPUs : A technique similar to the above thread, but the lighting is performed on the GPU (iirc). 2) 3D clouds a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>: Really nice looking clouds, but I don't remember any of the details. b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty lighting c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>: The above technique as it's used in Crysis. d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html>: Pretty old but still really good. Source code included <http://www.markmark.net/SkyWorks/>. I'm sure I had more of those but I unfortunately I haven't added them to my bookmark list. 3) Sky color a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's classic paper. The model is simple but it's quite difficult to configure in order to get nice colors. b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A way to implement the above paper using the GPU. c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>: What the title says :) d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>: Another classic paper by Nishita et al. The model might look a bit complex but it gives really nice results. e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>: IIRC this describes a way to implement Nishita's method using the GPU. Might worth a read. f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>: Really nice implementation of Nishita's method (iirc) on the GPU. Supports multiple scattering and the sun can be moved with no run-time overhead. A bit shader heavy though. Note that you can simplify Nishita's model (and all the derived implementations) a lot if you are not interested in planet rendering. I.e. for an FPS style game you can safely assume that the observer is always at (e.g.) (0, h, 0). That's it. You've probably already read/seen most of those, but you haven't mentioned anything so I tried. Hope the above help you get started. JD On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...>wrote: > Hi, > > I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D > game. > > > > These are the main requirements... > > > > 1) Have a high-cloud layer that can range from 0 to full coverage > > 2) Have lower clouds (sprites) that fade&roll in and out and move > around and are “lit by the Sun”, so the light can catch edges, and cause the > other side to appear in shadow etc. > > 3) Have colours of the sky change, as the sun rises/sets etc > > > > Can anyone suggest any ideas/tips/tricks or links to help me in my quest? > > > > Your input would be very much appreciated. > > > > Cheers > > Zaf > > > > > ********************************************************************************** > Disclaimer > > > The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. > > > Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. > > > Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. > > Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. > > This footnote also confirms that this email message has been swept by > SurfControl for the presence of computer viruses. > > ********************************************************************************** > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |
From: Tony A. <ton...@gm...> - 2010-04-12 23:47:22
|
I'd suggest you have a look at the paper "A Simple, Efficient Method for Realistic Animation of Clouds<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.4850>" (pdf <http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/sig00_cloud.pdf> and a video <http://video.google.com/videoplay?docid=3133893853954925559#> - the video is quite nice). It talks about modelling clouds with a cellular automata as well as how they render them. Additionally, vterrain has an extensive list of links on clouds - http://www.vterrain.org/Atmosphere/Clouds/ -Tony <http://www.vterrain.org/Atmosphere/Clouds/> |
From: Philip B. <phi...@gm...> - 2010-04-13 04:32:02
|
Thanks Jim! Really really informative. On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis < jd...@ma...> wrote: > Hi, > > Since you are looking for links and ideas I'll drop my two cents (long time > following the list, but this is my first post). > > 1) Cloud layer > a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>: Old thread at gdnet but with some nice ideas. > b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on > Modern GPUs : A technique similar to the above thread, but the lighting is > performed on the GPU (iirc). > > 2) 3D clouds > a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>: Really nice looking clouds, but I don't remember any of the details. > b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used > in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty > lighting > c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>: The above technique as it's used in Crysis. > d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html>: Pretty old but still really good. Source code > included <http://www.markmark.net/SkyWorks/>. > > I'm sure I had more of those but I unfortunately I haven't added them to my > bookmark list. > > 3) Sky color > a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's classic paper. The model is simple but it's quite difficult to > configure in order to get nice colors. > b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A way to implement the above paper using the GPU. > c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>: What the title says :) > d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>: Another classic paper by Nishita et al. The model might look a bit complex > but it gives really nice results. > e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>: IIRC this describes a way to implement Nishita's method using the GPU. > Might worth a read. > f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>: Really nice implementation of Nishita's method (iirc) on the GPU. Supports > multiple scattering and the sun can be moved with no run-time overhead. A > bit shader heavy though. > > Note that you can simplify Nishita's model (and all the derived > implementations) a lot if you are not interested in planet rendering. I.e. > for an FPS style game you can safely assume that the observer is always at > (e.g.) (0, h, 0). > > That's it. You've probably already read/seen most of those, but you haven't > mentioned anything so I tried. Hope the above help you get started. > > JD > > > > > > On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...>wrote: > >> Hi, >> >> I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D >> game. >> >> >> >> These are the main requirements... >> >> >> >> 1) Have a high-cloud layer that can range from 0 to full coverage >> >> 2) Have lower clouds (sprites) that fade&roll in and out and move >> around and are “lit by the Sun”, so the light can catch edges, and cause the >> other side to appear in shadow etc. >> >> 3) Have colours of the sky change, as the sun rises/sets etc >> >> >> >> Can anyone suggest any ideas/tips/tricks or links to help me in my quest? >> >> >> >> Your input would be very much appreciated. >> >> >> >> Cheers >> >> Zaf >> >> >> >> >> ********************************************************************************** >> Disclaimer >> >> >> The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. >> >> >> Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. >> >> >> Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. >> >> Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. >> >> This footnote also confirms that this email message has been swept by >> SurfControl for the presence of computer viruses. >> >> ********************************************************************************** >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list >> > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- Bai, Gang. Master student. State Key Lab. of Virtual Reality. Beihang University. Beijing, China. |
From: Zafar Q. <zaf...@co...> - 2010-04-13 10:42:39
|
I cannot thank you people enough. I really appreciate the time and energy you've all spent in collating and sharing all that info. Hope it helps others too. Very much appreciated. Zafar From: Philip Bai [mailto:phi...@gm...] Sent: 13 April 2010 05:32 To: Game Development Algorithms Subject: Re: [Algorithms] Cloud Rendering Thanks Jim! Really really informative. On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis <jd...@ma...<mailto:jd...@ma...>> wrote: Hi, Since you are looking for links and ideas I'll drop my two cents (long time following the list, but this is my first post). 1) Cloud layer a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024> : Old thread at gdnet but with some nice ideas. b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on Modern GPUs : A technique similar to the above thread, but the lighting is performed on the GPU (iirc). 2) 3D clouds a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf> : Really nice looking clouds, but I don't remember any of the details. b) Realistic and Fast Cloud Rendering<http://niniane.org/clouds/> : Used in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty lighting c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf> : The above technique as it's used in Crysis. d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html> : Pretty old but still really good. Source code included<http://www.markmark.net/SkyWorks/>. I'm sure I had more of those but I unfortunately I haven't added them to my bookmark list. 3) Sky color a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/> : Preetham's classic paper. The model is simple but it's quite difficult to configure in order to get nice colors. b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf> : A way to implement the above paper using the GPU. c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf> : What the title says :) d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf> : Another classic paper by Nishita et al. The model might look a bit complex but it gives really nice results. e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf> : IIRC this describes a way to implement Nishita's method using the GPU. Might worth a read. f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html> : Really nice implementation of Nishita's method (iirc) on the GPU. Supports multiple scattering and the sun can be moved with no run-time overhead. A bit shader heavy though. Note that you can simplify Nishita's model (and all the derived implementations) a lot if you are not interested in planet rendering. I.e. for an FPS style game you can safely assume that the observer is always at (e.g.) (0, h, 0). That's it. You've probably already read/seen most of those, but you haven't mentioned anything so I tried. Hope the above help you get started. JD On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...<mailto:zaf...@co...>> wrote: Hi, I'm trying to do some fairly realistic-looking cloud-rendering, in a 3D game. These are the main requirements... 1) Have a high-cloud layer that can range from 0 to full coverage 2) Have lower clouds (sprites) that fade&roll in and out and move around and are "lit by the Sun", so the light can catch edges, and cause the other side to appear in shadow etc. 3) Have colours of the sky change, as the sun rises/sets etc Can anyone suggest any ideas/tips/tricks or links to help me in my quest? Your input would be very much appreciated. Cheers Zaf ********************************************************************************** Disclaimer The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters' prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters' standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters' board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ 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_name=gdalgorithms-list ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ 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_name=gdalgorithms-list -- Bai, Gang. Master student. State Key Lab. of Virtual Reality. Beihang University. Beijing, China. Click here<https://www.mailcontrol.com/sr/N2LR9Q6ZTG3TndxI!oX7UiVrncwsDD+5W3P71cjD!twi!1jr58aCZwSNgu3Fc69w!O0FAbn57ZqFfmYpsSvVwQ==> to report this email as spam. ********************************************************************************** Disclaimer The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** |
From: yann le p. <lep...@gm...> - 2010-04-13 11:07:04
|
an other interesting paper : http://evasion.imag.fr/Publications/2008/BNMBC08/ (pdf : http://evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf ) ,yann On Tue, Apr 13, 2010 at 12:42 PM, Zafar Qamar <zaf...@co...>wrote: > I cannot thank you people enough. I really appreciate the time and energy > you’ve all spent in collating and sharing all that info. > > Hope it helps others too. > > > > Very much appreciated. > > Zafar > > > > > > > > *From:* Philip Bai [mailto:phi...@gm...] > *Sent:* 13 April 2010 05:32 > *To:* Game Development Algorithms > *Subject:* Re: [Algorithms] Cloud Rendering > > > > Thanks Jim! > > Really really informative. > > On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis < > jd...@ma...> wrote: > > Hi, > > Since you are looking for links and ideas I'll drop my two cents (long time > following the list, but this is my first post). > > 1) Cloud layer > a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>: Old thread at gdnet but with some nice ideas. > b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on > Modern GPUs : A technique similar to the above thread, but the lighting is > performed on the GPU (iirc). > > 2) 3D clouds > a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>: Really nice looking clouds, but I don't remember any of the details. > b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used > in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty > lighting > c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>: The above technique as it's used in Crysis. > d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html>: Pretty old but still really good. Source code > included <http://www.markmark.net/SkyWorks/>. > > I'm sure I had more of those but I unfortunately I haven't added them to my > bookmark list. > > 3) Sky color > a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's classic paper. The model is simple but it's quite difficult to > configure in order to get nice colors. > b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A way to implement the above paper using the GPU. > c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>: What the title says :) > d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>: Another classic paper by Nishita et al. The model might look a bit complex > but it gives really nice results. > e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>: IIRC this describes a way to implement Nishita's method using the GPU. > Might worth a read. > f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>: Really nice implementation of Nishita's method (iirc) on the GPU. Supports > multiple scattering and the sun can be moved with no run-time overhead. A > bit shader heavy though. > > Note that you can simplify Nishita's model (and all the derived > implementations) a lot if you are not interested in planet rendering. I.e. > for an FPS style game you can safely assume that the observer is always at > (e.g.) (0, h, 0). > > That's it. You've probably already read/seen most of those, but you haven't > mentioned anything so I tried. Hope the above help you get started. > > JD > > > > > On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar < > zaf...@co...> wrote: > > Hi, > > I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D > game. > > > > These are the main requirements... > > > > 1) Have a high-cloud layer that can range from 0 to full coverage > > 2) Have lower clouds (sprites) that fade&roll in and out and move > around and are “lit by the Sun”, so the light can catch edges, and cause the > other side to appear in shadow etc. > > 3) Have colours of the sky change, as the sun rises/sets etc > > > > Can anyone suggest any ideas/tips/tricks or links to help me in my quest? > > > > Your input would be very much appreciated. > > > > Cheers > > Zaf > > > > > > ********************************************************************************** > Disclaimer > > > The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. > > > Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. > > > Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. > > Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. > > This footnote also confirms that this email message has been swept by > SurfControl for the presence of computer viruses. > > ********************************************************************************** > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > -- > Bai, Gang. > Master student. > State Key Lab. of Virtual Reality. > Beihang University. > Beijing, China. > > > > Click here<https://www.mailcontrol.com/sr/N2LR9Q6ZTG3TndxI%21oX7UiVrncwsDD+5W3P71cjD%21twi%211jr58aCZwSNgu3Fc69w%21O0FAbn57ZqFfmYpsSvVwQ==>to report this email as spam. > > > > > ********************************************************************************** > Disclaimer > > > The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. > > > Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. > > > Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval. > > Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. > > This footnote also confirms that this email message has been swept by > SurfControl for the presence of computer viruses. > > ********************************************************************************** > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- Yann Le Paih Keraudrono 56150 BAUD FRANCE Portable: +33(0)610524356 lep...@gm... |