Thread: [Algorithms] HDR and MSAA
Brought to you by:
vexxed72
From: Matt J <mjo...@gm...> - 2007-06-27 02:13:30
|
The half-life lost coast is said to work on all DX9 class hardware with MSAA. However the demo I've seen HDRFormats and another that is said to work with RGBE formats doesn't seem to support any sort of antialiasing .Obviously you can't expect the expontential E to scale well since its expotential not linear, but in any of the cases I'd expect to see some sort of smoothing, but it still appears jagged. Anyone know what HL does differently? I developed a really nice planet shader but am unhappy with the saturation near part of a specular glow I gave it, so I'm eager to use postprocessing to give it a nice bloom effect that I think will look good (as well as the automatic contrast adjustment), but I don't want to sacrifice MSAA. The odd thing is the RT's (render targets) for RGBE in the demo is using a 6x antialiasing (with a StretchRect over to the back buffer) yet I don't see any antialiasing effect. My development machine is a Mobile Radeon 9700. Anyone have any experience with this? Matthew |
From: Marco S. <mar...@gm...> - 2007-06-27 02:54:05
|
AFAIK HL simply performs tone mapping in its color pass as final step in every pixel shader, so it nevers output a HDR color, but only tone mapped LDR pixels, that's why they can have MSAA + HDR on RGBA8 render targets. IIRC they use a linear tone mapping operator and exposure is computed from LDR data as they try to compensate overtime for too dark or to bright images. Marco On 6/26/07, Matt J <mjo...@gm...> wrote: > > The half-life lost coast is said to work on all DX9 class hardware > with MSAA. However the demo I've seen HDRFormats and another that is > said to work with RGBE formats doesn't seem to support any sort of > antialiasing .Obviously you can't expect the expontential E to scale > well since its expotential not linear, but in any of the cases I'd > expect to see some sort of smoothing, but it still appears jagged. > Anyone know what HL does differently? > > I developed a really nice planet shader but am unhappy with the > saturation near part of a specular glow I gave it, so I'm eager to use > postprocessing to give it a nice bloom effect that I think will look > good (as well as the automatic contrast adjustment), but I don't want > to sacrifice MSAA. The odd thing is the RT's (render targets) for > RGBE in the demo is using a 6x antialiasing (with a StretchRect over > to the back buffer) yet I don't see any antialiasing effect. > > My development machine is a Mobile Radeon 9700. Anyone have any > experience with this? > > Matthew > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Aras P. <ne...@gm...> - 2007-06-27 05:26:08
|
> The half-life lost coast is said to work on all DX9 class hardware > with MSAA. However the demo I've seen HDRFormats and another that is > said to work with RGBE formats doesn't seem to support any sort of > antialiasing .Obviously you can't expect the expontential E to scale > well since its expotential not linear, but in any of the cases I'd > expect to see some sort of smoothing, but it still appears jagged. There was a presentation on Valve's HDR somewhere. Basically it looks like they are not using RGBE; they are using plain RGBA, with tone mapping performed at the end of any shader. So they do not output HDR colors anywhere. The reason they can do this is that all their shaders seem to be single-pass (i.e. lighting is not accumulated in multiple passes anywhere). > The odd thing is the RT's (render targets) for > RGBE in the demo is using a 6x antialiasing (with a StretchRect over > to the back buffer) yet I don't see any antialiasing effect. I tried this a couple of years ago, and while it worked on NVIDIA hardware, it did not work on ATI hardware (at least then). In a sense that color channels were multisampled, but alpha channel was not. I think someone said to me that ATI hardware does not resolve alpha channel when doing MSAA'd render target to non-AA surface blit, or it does not multisample alpha channels at all. -- Aras Pranckevicius work: www.unity3d.com home: nesnausk.org/nearaz |
From: Aras P. <ne...@gm...> - 2007-06-27 05:28:31
|
> There was a presentation on Valve's HDR somewhere. Basically it looks > like they are not using RGBE; ... Ah, here it is: http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf -- Aras Pranckevicius work: www.unity3d.com home: nesnausk.org/nearaz |
From: Matt J <mjo...@gm...> - 2007-06-27 17:00:28
|
Single pass shaders .. ahh, that explains it. Thanks for the paper, I didn't see it. Google failed me :) > There was a presentation on Valve's HDR somewhere. Basically it looks > like they are not using RGBE; they are using plain RGBA, with tone > mapping performed at the end of any shader. So they do not output HDR > colors anywhere. The reason they can do this is that all their shaders > seem to be single-pass (i.e. lighting is not accumulated in multiple > passes anywhere). > Yeah, the alpha channel isn't resolved at all in older hardware :( Sucks for video export too. > I tried this a couple of years ago, and while it worked on NVIDIA > hardware, it did not work on ATI hardware (at least then). In a sense > that color channels were multisampled, but alpha channel was not. I > think someone said to me that ATI hardware does not resolve alpha > channel when doing MSAA'd render target to non-AA surface blit, or it > does not multisample alpha channels at all. |
From: Paul at H. <pa...@ru...> - 2007-06-28 20:30:16
|
I'm trying to come up with a way to do some sort of global illumination system that will be used purely as lightmaps - I'm not interested in the slightest in any real-time stuff. I don't even want true radiosity effects tbh, just something convincing that will go in fairly low-resolution lightmaps akin to those seen in Quake 3 et al. I've read enough withering descriptions of form factors and other stuff but with my non-mathhead background I can't help but think that it's all overkill for games tbh. Reflected ambient occlusion is kinda what I'm after I guess. How feasible is it just do something like this. (Per lumel across the whole scene, one at a time) Put camera on lumel facing "out" along its normal Render the scene into a cubemap taking direct lighting onto "black" textures Blur all 5 faces down to a 1x1 (All of the top face and the top half of the surrounding four) Avg those 5 pixels for my result. Poke pixel into a double-buffered new lightmap Repeat for every single lumel Repeat entire process several times to bounce the light around. All but the first pass use the previous stage of lightmaps and don't do any direct lighting at all. All new calculations are additve to the previous ones Given how low detail this is, it might even be feasible to eschew the cubemap and use one very wide angle render ? I could attenuate the lighting over distance in the shader easily enough and futher mul it by some sort of material based "matt reflection" haxx0r. This sounds like it should produce something decent but I'd like to ask the panel for a sanity check before I dive in as it's gonna be a shitload of code done mostly in my spare time. I don't want to get a month in and find the results are going to be crap! Any comments/advice gratefully received. Regards, Paul Johnson. www.rubicondev.com |
From: Stefan S. <kef...@gm...> - 2007-06-28 20:51:45
|
By far the easiest you can do is to use max, maya, blender, turtle and bake it in there. Also, if you can, use the atlas+PRT stuff from the DX sdk, and just rasterise it in lightmapspace, which will produce static lightmaps with excellent quality. It's fairly slow though, and you can get off much cheaper than that. Doing a radiosity processor is fairly straight forward, but it get's difficult to get just right/efficient. I've done my share of this stuff, and one of my hobby projects at the moment is exactly this, but with the rendering-algorithm expressed entirely in lua, backed by very efficient structures on the C side. My goal is to make something that's extremely flexible, meaning you can whip together your own bizarre lighting stuff, and not have to bother writing all the heavy stuff. Lemme know if you're interested, would be nice to have someone to test it on, when it gets a bit more mature. :) Paul at Home wrote: > I'm trying to come up with a way to do some sort of global illumination > system that will be used purely as lightmaps - I'm not interested in the > slightest in any real-time stuff. > > I don't even want true radiosity effects tbh, just something convincing that > will go in fairly low-resolution lightmaps akin to those seen in Quake 3 et > al. I've read enough withering descriptions of form factors and other stuff > but with my non-mathhead background I can't help but think that it's all > overkill for games tbh. Reflected ambient occlusion is kinda what I'm after > I guess. > > How feasible is it just do something like this. (Per lumel across the whole > scene, one at a time) > > Put camera on lumel facing "out" along its normal > Render the scene into a cubemap taking direct lighting onto "black" textures > Blur all 5 faces down to a 1x1 (All of the top face and the top half of the > surrounding four) > Avg those 5 pixels for my result. Poke pixel into a double-buffered new > lightmap > Repeat for every single lumel > > Repeat entire process several times to bounce the light around. All but the > first pass use the previous stage of lightmaps and don't do any direct > lighting at all. All new calculations are additve to the previous ones > > Given how low detail this is, it might even be feasible to eschew the > cubemap and use one very wide angle render ? > > I could attenuate the lighting over distance in the shader easily enough and > futher mul it by some sort of material based "matt reflection" haxx0r. > > This sounds like it should produce something decent but I'd like to ask the > panel for a sanity check before I dive in as it's gonna be a shitload of > code done mostly in my spare time. I don't want to get a month in and find > the results are going to be crap! > > Any comments/advice gratefully received. > > > Regards, > Paul Johnson. > www.rubicondev.com > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Jeff R. <je...@gm...> - 2007-06-28 21:06:41
|
Paul, I've done pretty much exactly this in our project, took around a day to see interesting results and a couple more days to polish it up. It's great and fast and a much better option than using a 3rd party baker because it can exactly match your game's lighting model. One thing to note that I didn't see in your description: when you're rendering your hemicube you need to modulate the results by the dot product of your surface normal with each pixel direction. Pixels on the 'horizon' of your hemicube are barely lighting your sample point at all, but only 'grazing' it - light varying with the dot product of the angle and all that. This can be easily done by multiply-blending a sphere or something with the gradient you want onto the cube GPU side after you've rendered the scene. Jeff Russell 8Monkey Labs On 6/28/07, Paul at Home <pa...@ru...> wrote: > > I'm trying to come up with a way to do some sort of global illumination > system that will be used purely as lightmaps - I'm not interested in the > slightest in any real-time stuff. > > I don't even want true radiosity effects tbh, just something convincing > that > will go in fairly low-resolution lightmaps akin to those seen in Quake 3 > et > al. I've read enough withering descriptions of form factors and other > stuff > but with my non-mathhead background I can't help but think that it's all > overkill for games tbh. Reflected ambient occlusion is kinda what I'm > after > I guess. > > How feasible is it just do something like this. (Per lumel across the > whole > scene, one at a time) > > Put camera on lumel facing "out" along its normal > Render the scene into a cubemap taking direct lighting onto "black" > textures > Blur all 5 faces down to a 1x1 (All of the top face and the top half of > the > surrounding four) > Avg those 5 pixels for my result. Poke pixel into a double-buffered new > lightmap > Repeat for every single lumel > > Repeat entire process several times to bounce the light around. All but > the > first pass use the previous stage of lightmaps and don't do any direct > lighting at all. All new calculations are additve to the previous ones > > Given how low detail this is, it might even be feasible to eschew the > cubemap and use one very wide angle render ? > > I could attenuate the lighting over distance in the shader easily enough > and > futher mul it by some sort of material based "matt reflection" haxx0r. > > This sounds like it should produce something decent but I'd like to ask > the > panel for a sanity check before I dive in as it's gonna be a shitload of > code done mostly in my spare time. I don't want to get a month in and find > the results are going to be crap! > > Any comments/advice gratefully received. > > > Regards, > Paul Johnson. > www.rubicondev.com > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Jon W. <hp...@mi...> - 2007-06-29 19:45:19
|
Paul at Home wrote: > Render the scene into a cubemap taking direct lighting onto "black" textures > Blur all 5 faces down to a 1x1 (All of the top face and the top half of the > surrounding four) > > You probably want to blend the 5 faces down to 1 using the surface direction response (which typically is approximated as the cosine term). Also, with this method, you'll get perfectly diffuse surfaces only, because the emitted light is the same no matter what your viewing direction is. Turning the cube maps into spherical harmonics, and texturing with those spherical harmonics is likely to give a significantly higher degree of quality. Cheers, / h+ -- -- Revenge is the most pointless and damaging of human desires. |
From: Stefan S. <kef...@gm...> - 2007-06-29 21:40:58
|
Anything other than purely diffuse would be redundant when you store it in a lightmap. Jon Watte wrote: > Paul at Home wrote: > >> Render the scene into a cubemap taking direct lighting onto "black" textures >> Blur all 5 faces down to a 1x1 (All of the top face and the top half of the >> surrounding four) >> >> >> > > You probably want to blend the 5 faces down to 1 using the surface > direction response (which typically is approximated as the cosine term). > > Also, with this method, you'll get perfectly diffuse surfaces only, > because the emitted light is the same no matter what your viewing > direction is. Turning the cube maps into spherical harmonics, and > texturing with those spherical harmonics is likely to give a > significantly higher degree of quality. > > Cheers, > > / h+ > > > > |
From: Jon W. <hp...@mi...> - 2007-07-02 17:48:21
|
Stefan Sandberg wrote: > Anything other than purely diffuse would be redundant when you store it > in a lightmap. > > Not if you store a SH light map, which is what I'm suggesting to do. Cheers, / h+ -- -- Revenge is the most pointless and damaging of human desires. |
From: Jesus de S. G. <ic...@bi...> - 2007-07-03 13:17:00
|
At least to me, it is more intuitive the way Half Life 2 and Unreal do this. Around each normal you have a 3 vector basis. You generate 3 radiosity calculations for each vector. With this information you can get an approximation of the illumination received by any point in any direction. This can be used to apply the normal map to the low-res lightmaps or to simulate a specular behaviour using the reflected vector. More information, in this Siggraph presentation: http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf On 7/2/07, Jon Watte <hp...@mi...> wrote: > > > > Stefan Sandberg wrote: > > Anything other than purely diffuse would be redundant when you store it > > in a lightmap. > > > > > > Not if you store a SH light map, which is what I'm suggesting to do. > > Cheers, > > / h+ > > > -- > -- Revenge is the most pointless and damaging of human desires. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Stefan S. <kef...@gm...> - 2007-07-03 19:29:01
|
hm,, it seems my point was lost, but I was probably a bit vague, so I'll try to clarify what I meant. A 'lightmap' is just a (parameterized) texture of precomputed intensities/colors, like Quake, everyone is clear on that, but it becomes complicated when you start bringing in non-diffuse things. You can't just 'store' specular lighting in a texture, because it's not static, it involves the camera, ie, it's a function, not a value.. You can mitigate this by storing something that will let you "solve for 'angle'", for example spherical harmonics (or more appropriately, hemispherical-harmonics). SH is not "lighting", it's just math, and has as much to do with lighting as a dot product has, so I just find it quite confusing to call that a "lightmap".. (Btw, I believe the 3 vector basis in hl2's shading has nothing to do with it's specular shading) Jesus de Santos Garcia wrote: > At least to me, it is more intuitive the way Half Life 2 and Unreal do > this. > > Around each normal you have a 3 vector basis. You generate 3 radiosity > calculations for each vector. > > With this information you can get an approximation of the illumination > received by any point in any direction. This can be used to apply the > normal map to the low-res lightmaps or to simulate a specular > behaviour using the reflected vector. > > More information, in this Siggraph presentation: > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > <http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf> > > On 7/2/07, *Jon Watte* <hp...@mi... > <mailto:hp...@mi...>> wrote: > > > > Stefan Sandberg wrote: > > Anything other than purely diffuse would be redundant when you > store it > > in a lightmap. > > > > > > Not if you store a SH light map, which is what I'm suggesting to do. > > Cheers, > > / h+ > > > -- > -- Revenge is the most pointless and damaging of human desires. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > <http://sourceforge.net/powerbar/db2/> > _______________________________________________ > 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 > <http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > 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: Jesus de S. G. <ic...@bi...> - 2007-07-03 20:01:59
|
Hi, yes, i understand you perfectly. The idea is a generalization of the classic lightmap. Instead of gather illumination from the normal, you gather information from 3 vectors in a basis. Now, with this information you can extrapolate the illumination to whatever normal. So for example, the normals from a normal map can be used. And, although not used in Half Life, you could extrapolate the information from the reflection vector to get an approximation of a specular approximation. Obviously it is a bad approximation (don't have enough information) but it is an effect that is view dependent. What I said, probably this is equivalent mathematically to SH, but to me is a lot more intuitive. On 7/3/07, Stefan Sandberg <kef...@gm...> wrote: > > hm,, it seems my point was lost, but I was probably a bit vague, so I'll > try to clarify what I meant. > > A 'lightmap' is just a (parameterized) texture of precomputed > intensities/colors, like Quake, everyone is clear on that, but it > becomes complicated when you start bringing in non-diffuse things. You > can't just 'store' specular lighting in a texture, because it's not > static, it involves the camera, ie, it's a function, not a value.. You > can mitigate this by storing something that will let you "solve for > 'angle'", for example spherical harmonics (or more appropriately, > hemispherical-harmonics). SH is not "lighting", it's just math, and has > as much to do with lighting as a dot product has, so I just find it > quite confusing to call that a "lightmap".. > > (Btw, I believe the 3 vector basis in hl2's shading has nothing to do > with it's specular shading) > > Jesus de Santos Garcia wrote: > > At least to me, it is more intuitive the way Half Life 2 and Unreal do > > this. > > > > Around each normal you have a 3 vector basis. You generate 3 radiosity > > calculations for each vector. > > > > With this information you can get an approximation of the illumination > > received by any point in any direction. This can be used to apply the > > normal map to the low-res lightmaps or to simulate a specular > > behaviour using the reflected vector. > > > > More information, in this Siggraph presentation: > > > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > < > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > > > > > On 7/2/07, *Jon Watte* <hp...@mi... > > <mailto:hp...@mi...>> wrote: > > > > > > > > Stefan Sandberg wrote: > > > Anything other than purely diffuse would be redundant when you > > store it > > > in a lightmap. > > > > > > > > > > Not if you store a SH light map, which is what I'm suggesting to do. > > > > Cheers, > > > > / h+ > > > > > > -- > > -- Revenge is the most pointless and damaging of human desires. > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > <http://sourceforge.net/powerbar/db2/> > > _______________________________________________ > > 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 > > < > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list> > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Stefan S. <kef...@gm...> - 2007-07-03 20:13:35
|
Um I can't see how that would be equivalent to SH.. Like, you know you can break down a complex signal into it's base sine-waves? That's what SH is, but on the surface of a unit sphere. Jesus de Santos Garcia wrote: > Hi, > > yes, i understand you perfectly. The idea is a generalization of the > classic lightmap. Instead of gather illumination from the normal, you > gather information from 3 vectors in a basis. Now, with this > information you can extrapolate the illumination to whatever normal. > So for example, the normals from a normal map can be used. > > And, although not used in Half Life, you could extrapolate the > information from the reflection vector to get an approximation of a > specular approximation. Obviously it is a bad approximation (don't > have enough information) but it is an effect that is view dependent. > > What I said, probably this is equivalent mathematically to SH, but to > me is a lot more intuitive. > > On 7/3/07, *Stefan Sandberg* < kef...@gm... > <mailto:kef...@gm...>> wrote: > > hm,, it seems my point was lost, but I was probably a bit vague, > so I'll > try to clarify what I meant. > > A 'lightmap' is just a (parameterized) texture of precomputed > intensities/colors, like Quake, everyone is clear on that, but it > becomes complicated when you start bringing in non-diffuse things. > You > can't just 'store' specular lighting in a texture, because it's not > static, it involves the camera, ie, it's a function, not a value.. You > can mitigate this by storing something that will let you "solve for > 'angle'", for example spherical harmonics (or more appropriately, > hemispherical-harmonics). SH is not "lighting", it's just math, > and has > as much to do with lighting as a dot product has, so I just find it > quite confusing to call that a "lightmap".. > > (Btw, I believe the 3 vector basis in hl2's shading has nothing to do > with it's specular shading) > > Jesus de Santos Garcia wrote: > > At least to me, it is more intuitive the way Half Life 2 and > Unreal do > > this. > > > > Around each normal you have a 3 vector basis. You generate 3 > radiosity > > calculations for each vector. > > > > With this information you can get an approximation of the > illumination > > received by any point in any direction. This can be used to > apply the > > normal map to the low-res lightmaps or to simulate a specular > > behaviour using the reflected vector. > > > > More information, in this Siggraph presentation: > > > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > < > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf> > > > > On 7/2/07, *Jon Watte* <hp...@mi... > <mailto:hp...@mi...> > > <mailto: hp...@mi... <mailto:hp...@mi...>>> > wrote: > > > > > > > > Stefan Sandberg wrote: > > > Anything other than purely diffuse would be redundant when you > > store it > > > in a lightmap. > > > > > > > > > > Not if you store a SH light map, which is what I'm > suggesting to do. > > > > Cheers, > > > > / h+ > > > > > > -- > > -- Revenge is the most pointless and damaging of human desires. > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and > take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > <http://sourceforge.net/powerbar/db2/> > > <http://sourceforge.net/powerbar/db2/> > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > <mailto:GDA...@li...> > > <mailto:GDA...@li... > <mailto:GDA...@li...> > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > <http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > <http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list>> > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > <http://sourceforge.net/powerbar/db2/> > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > <mailto:GDA...@li...> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > <https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list> > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > 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: Darren G. <dg...@ke...> - 2007-07-04 04:00:21
|
"SH" and "SH Lighting" are often confused. SH Lighting exploits numeric properties of spherical (zonal?) harmonics and some limited gpu wisdom to produce more correct inter-reflection effects in less time than its cube counterparts. I think that's all, correct me if I'm wrong. Pros: Better approximation of rendering solutions with less data, efficient enough to make scaling up to dynamic scenes feasible without sacrificing much correctness. Con: Complex theory involved in configuring geometry distracts from the goal. (I'm a game programmer, not a math major! ;) There was talk about specular shading (presumably factoring into the global illumination solution was the thought), but this does require geometry to carry an order of magnitude more data whether you are using SH or not. But I would think that the bar hasn't been raised so far yet that anyone would expect direct reflection to be a bad solution. As the HL2 slides show, some pragmatism now is worth a lot more than a possible solution later. At 01:12 PM 7/3/2007, you wrote: >Um I can't see how that would be equivalent to SH.. Like, you know you >can break down a complex signal into it's base sine-waves? That's what >SH is, but on the surface of a unit sphere. > >Jesus de Santos Garcia wrote: > > Hi, > > > > yes, i understand you perfectly. The idea is a generalization of the > > classic lightmap. Instead of gather illumination from the normal, you > > gather information from 3 vectors in a basis. Now, with this > > information you can extrapolate the illumination to whatever normal. > > So for example, the normals from a normal map can be used. > > > > And, although not used in Half Life, you could extrapolate the > > information from the reflection vector to get an approximation of a > > specular approximation. Obviously it is a bad approximation (don't > > have enough information) but it is an effect that is view dependent. > > > > What I said, probably this is equivalent mathematically to SH, but to > > me is a lot more intuitive. > > > > On 7/3/07, *Stefan Sandberg* < kef...@gm... > > <mailto:kef...@gm...>> wrote: > > > > hm,, it seems my point was lost, but I was probably a bit vague, > > so I'll > > try to clarify what I meant. > > > > A 'lightmap' is just a (parameterized) texture of precomputed > > intensities/colors, like Quake, everyone is clear on that, but it > > becomes complicated when you start bringing in non-diffuse things. > > You > > can't just 'store' specular lighting in a texture, because it's not > > static, it involves the camera, ie, it's a function, not a value.. You > > can mitigate this by storing something that will let you "solve for > > 'angle'", for example spherical harmonics (or more appropriately, > > hemispherical-harmonics). SH is not "lighting", it's just math, > > and has > > as much to do with lighting as a dot product has, so I just find it > > quite confusing to call that a "lightmap".. > > > > (Btw, I believe the 3 vector basis in hl2's shading has nothing to do > > with it's specular shading) > > > > Jesus de Santos Garcia wrote: > > > At least to me, it is more intuitive the way Half Life 2 and > > Unreal do > > > this. > > > > > > Around each normal you have a 3 vector basis. You generate 3 > > radiosity > > > calculations for each vector. > > > > > > With this information you can get an approximation of the > > illumination > > > received by any point in any direction. This can be used to > > apply the > > > normal map to the low-res lightmaps or to simulate a specular > > > behaviour using the reflected vector. > > > > > > More information, in this Siggraph presentation: > > > > > > > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > > < > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf> > > > > > > On 7/2/07, *Jon Watte* <hp...@mi... > > <mailto:hp...@mi...> > > > <mailto: hp...@mi... <mailto:hp...@mi...>>> > > wrote: > > > > > > > > > > > > Stefan Sandberg wrote: > > > > Anything other than purely diffuse would be redundant when you > > > store it > > > > in a lightmap. > > > > > > > > > > > > > > Not if you store a SH light map, which is what I'm > > suggesting to do. > > > > > > Cheers, > > > > > > / h+ > > > > > > > > > -- > > > -- Revenge is the most pointless and damaging of human desires. > > > ---- Darren Grant Lead Programmer http://www.kerberos-productions.com/ http://www.swordofthestars.com/ |
From: Pal-Kristian E. <pal...@na...> - 2007-07-04 05:10:57
|
Hi all, SH is actually not that hard to grasp. SH simply encodes a function on a sphere, in the same way that the two numers [a = 1.0, b = -1.0], encodes a line on the interval [0..1], by the function: f(x) = a*x + b. So, the big-picture is that the SH represents a function f(w), where w are points on the sphere (or simply unit normals) by having a set of coefficients. As a matter of fact, if you use first order SH representation, then the function encodes: f(x, y, z) = A + B*x + C*y + C*z, The second order SH representation just adds second order variables over x, y and z. Of course, we usually want to encode a color, so instead of 4 coefficients, we'll have 12 coefficents, 4 coefficients for each color (R, G, B). It turns out that this representation (at least with second or third order coefficients) can often be good enough to represent diffuse lighting, simply because diffuse lighting is quite "soft" (low-frequency). Of course, I've glossed over details such as how to calculate the coefficients and other rules pertaining to SH, but this should give you a small insight into what SH is. PKE. Darren Grant wrote: > "SH" and "SH Lighting" are often confused. SH Lighting exploits > numeric properties of spherical (zonal?) harmonics and some limited > gpu wisdom to produce more correct inter-reflection effects in less > time than its cube counterparts. I think that's all, correct me if > I'm wrong. Pros: Better approximation of rendering solutions with > less data, efficient enough to make scaling up to dynamic scenes > feasible without sacrificing much correctness. Con: Complex theory > involved in configuring geometry distracts from the goal. (I'm a game > programmer, not a math major! ;) > > There was talk about specular shading (presumably factoring into the > global illumination solution was the thought), but this does require > geometry to carry an order of magnitude more data whether you are > using SH or not. But I would think that the bar hasn't been raised > so far yet that anyone would expect direct reflection to be a bad > solution. As the HL2 slides show, some pragmatism now is worth a lot > more than a possible solution later. > > > > At 01:12 PM 7/3/2007, you wrote: > >> Um I can't see how that would be equivalent to SH.. Like, you know you >> can break down a complex signal into it's base sine-waves? That's what >> SH is, but on the surface of a unit sphere. >> >> Jesus de Santos Garcia wrote: >> >>> Hi, >>> >>> yes, i understand you perfectly. The idea is a generalization of the >>> classic lightmap. Instead of gather illumination from the normal, you >>> gather information from 3 vectors in a basis. Now, with this >>> information you can extrapolate the illumination to whatever normal. >>> So for example, the normals from a normal map can be used. >>> >>> And, although not used in Half Life, you could extrapolate the >>> information from the reflection vector to get an approximation of a >>> specular approximation. Obviously it is a bad approximation (don't >>> have enough information) but it is an effect that is view dependent. >>> >>> What I said, probably this is equivalent mathematically to SH, but to >>> me is a lot more intuitive. >>> >>> On 7/3/07, *Stefan Sandberg* < kef...@gm... >>> <mailto:kef...@gm...>> wrote: >>> >>> hm,, it seems my point was lost, but I was probably a bit vague, >>> so I'll >>> try to clarify what I meant. >>> >>> A 'lightmap' is just a (parameterized) texture of precomputed >>> intensities/colors, like Quake, everyone is clear on that, but it >>> becomes complicated when you start bringing in non-diffuse things. >>> You >>> can't just 'store' specular lighting in a texture, because it's not >>> static, it involves the camera, ie, it's a function, not a value.. You >>> can mitigate this by storing something that will let you "solve for >>> 'angle'", for example spherical harmonics (or more appropriately, >>> hemispherical-harmonics). SH is not "lighting", it's just math, >>> and has >>> as much to do with lighting as a dot product has, so I just find it >>> quite confusing to call that a "lightmap".. >>> >>> (Btw, I believe the 3 vector basis in hl2's shading has nothing to do >>> with it's specular shading) >>> >>> Jesus de Santos Garcia wrote: >>> > At least to me, it is more intuitive the way Half Life 2 and >>> Unreal do >>> > this. >>> > >>> > Around each normal you have a 3 vector basis. You generate 3 >>> radiosity >>> > calculations for each vector. >>> > >>> > With this information you can get an approximation of the >>> illumination >>> > received by any point in any direction. This can be used to >>> apply the >>> > normal map to the low-res lightmaps or to simulate a specular >>> > behaviour using the reflected vector. >>> > >>> > More information, in this Siggraph presentation: >>> > >>> > >>> >>> >> http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf >> >>> > < >>> >>> >> http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf> >> >>> > >>> > On 7/2/07, *Jon Watte* <hp...@mi... >>> <mailto:hp...@mi...> >>> > <mailto: hp...@mi... <mailto:hp...@mi...>>> >>> wrote: >>> > >>> > >>> > >>> > Stefan Sandberg wrote: >>> > > Anything other than purely diffuse would be redundant when you >>> > store it >>> > > in a lightmap. >>> > > >>> > > >>> > >>> > Not if you store a SH light map, which is what I'm >>> suggesting to do. >>> > >>> > Cheers, >>> > >>> > / h+ >>> > >>> > >>> > -- >>> > -- Revenge is the most pointless and damaging of human desires. >>> > >>> > > > ---- > Darren Grant > Lead Programmer > http://www.kerberos-productions.com/ > http://www.swordofthestars.com/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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 > > -- Pål-Kristian Engstad (en...@na...), Lead Graphics & Engine Programmer, "Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North, Santa Monica, CA 90404, USA. Ph.: (310) 633-9112. "Most of us would do well to remember that there is a reason Carmack is Carmack, and we are not Carmack.", Jonathan Blow, 2/1/2006, GD Algo Mailing List |
From: Jon W. <hp...@mi...> - 2007-07-06 07:47:35
|
Darren Grant wrote: > "SH" and "SH Lighting" are often confused. SH Lighting exploits > numeric properties of spherical (zonal?) harmonics and some limited > gpu wisdom to produce more correct inter-reflection effects in less > time than its cube counterparts. That's not true. You can pre-compute the radiance transfer of a surface, with direction sensitivity, into a SH that you store per texel/lumel/coefficient-set over the mesh, similar to how a light map stores a single brightness/color value. With cube maps, you can't store a cube map per lumel :-) This is what we've been discussing. Similarly, you can also calculate the general directional lighting environment of an area into a SH. In that matter, they are more similar to cube-map (image) based lighting. However, that's a second, different, use of SHs. I believe this is what you're referring to. The cool thing is you can combine them. When you do so, you get a pretty nice lighting solution for not very much GPU math. > feasible without sacrificing much correctness. Con: Complex theory > involved in configuring geometry distracts from the goal. (I'm a game > programmer, not a math major! ;) > > Once the shader is right, computing the per-lumel spherical harmonic radiance transfer function is automatic in a pre-processor, just like, say, a radiosity light-mapper. And, for the lighting environment, there are functions that let you take N "distant" lights and calculate a single SH that approximate their effect. However, saying you're not a math major is probably doing yourself a dis-service. Modern AAA games (graphics, collision testing, fluid forces, AI, physics, ...) requires significant amounts of applied math, and there's no way around it. Except perhaps making web-based collection or match-three games, which actually has a larger total audience than AAA games anyway :-) If you have a static lighting environment (such that you can pre-bake lighting), you probably can bake "distant" specular response into the SH, with the draw-back that the specular power can't be terribly strong (the directivity localization is too diffuse). Cheers, / h+ -- -- Revenge is the most pointless and damaging of human desires. |
From: Stefan S. <kef...@gm...> - 2007-07-06 08:53:46
|
Eh, no, that IS true. Spherical harmonics is NOT a lighting technique, even if you can use it for that.. I'm fairly sure you use matrices for all sorts of things, and it would be just as incorrect to call something "matrix lighting" etc.. SH is simply a method to change an integral over a spherical surface to a sequence of add & mul operations, which are rotationally invariant and also very quick to eval on a gpu, which is the sole reason why people use them FOR lighting. Hemispherical harmonics thusly perform better, since the signal that the basis expresses is limited to a hemisphere positioned on a surface. It's not diffucult to explain how it works, just harder without images to emphasize it. Sloan used SH to encode a signal over the surface of a sphere, and the signal was aquired by sampling the environment for each point in question using monte-carlo tracing and converting it to SH basis. The more coefficients are used, the more accurately the signal can be reproduced. Other basises work too, non linear wavelets are both faster and more accurate than spherical harmonics for lighting.. (and again, hemispherical harmonics just makes more sense, but it's still the same deal). Jon Watte wrote: > Darren Grant wrote: > >> "SH" and "SH Lighting" are often confused. SH Lighting exploits >> numeric properties of spherical (zonal?) harmonics and some limited >> gpu wisdom to produce more correct inter-reflection effects in less >> time than its cube counterparts. >> > > That's not true. You can pre-compute the radiance transfer of a surface, > with direction sensitivity, into a SH that you store per > texel/lumel/coefficient-set over the mesh, similar to how a light map > stores a single brightness/color value. With cube maps, you can't store > a cube map per lumel :-) This is what we've been discussing. > > Similarly, you can also calculate the general directional lighting > environment of an area into a SH. In that matter, they are more similar > to cube-map (image) based lighting. However, that's a second, different, > use of SHs. I believe this is what you're referring to. > > The cool thing is you can combine them. When you do so, you get a pretty > nice lighting solution for not very much GPU math. > > >> feasible without sacrificing much correctness. Con: Complex theory >> involved in configuring geometry distracts from the goal. (I'm a game >> programmer, not a math major! ;) >> >> >> > > Once the shader is right, computing the per-lumel spherical harmonic > radiance transfer function is automatic in a pre-processor, just like, > say, a radiosity light-mapper. And, for the lighting environment, there > are functions that let you take N "distant" lights and calculate a > single SH that approximate their effect. > > However, saying you're not a math major is probably doing yourself a > dis-service. Modern AAA games (graphics, collision testing, fluid > forces, AI, physics, ...) requires significant amounts of applied math, > and there's no way around it. Except perhaps making web-based collection > or match-three games, which actually has a larger total audience than > AAA games anyway :-) > > If you have a static lighting environment (such that you can pre-bake > lighting), you probably can bake "distant" specular response into the > SH, with the draw-back that the specular power can't be terribly strong > (the directivity localization is too diffuse). > > Cheers, > > / h+ > > > |
From: Erwin de V. <er...@vo...> - 2007-07-06 14:17:29
|
Hi, I've been trying to pack a float into 24 bits of an RGBA32 texture using a ps2.0 shader, and after some experimenting have come up with a method which works great on Nvidia ps3.0 hardware, which as far as i know use full 32 bits precision in the pixel pipe, but i'm not seeing accurate results on ATI 2.0 hardware, which seem to have only 24 bits of precision. I would like to store the depth value of the current pixel in a texture using as much precision as possible, and would like to do it in a 32 bits texture, because i'm using MRT, which forces all my rendertargets into the same format. Is there any 'official', or commonly used conversion for this, which also gives high precision (~24bits) on older ATI hardware? I need to pack and unpack the value in a shader, but i think the actual packing is the problem in my current implementation. Regards, Erwin |
From: Aras P. <ne...@gm...> - 2007-07-06 14:25:08
|
> I've been trying to pack a float into 24 bits of an RGBA32 texture using a > ps2.0 shader, and after some experimenting have come up with a method which > works great on Nvidia ps3.0 hardware, which as far as i know use full 32 > bits precision in the pixel pipe, but i'm not seeing accurate results on ATI > 2.0 hardware, which seem to have only 24 bits of precision. What I came up using recently: http://nesnausk.org/nearaz/blog/2007/06/29/encoding-floats-to-rgba-redux - and yes, on NVIDIA and Intel I use one path and on ATI I have to use another one (well, not "path", but a bit different constants for packing). -- Aras Pranckevicius work: www.unity3d.com home: nesnausk.org/nearaz |
From: Jon W. <hp...@mi...> - 2007-07-07 07:32:16
|
The problem is that you simply don't have 24 bits of mantissa on ATI SM 2.0 hardware. That's the whole reason ATI could get the big upswing when DX9 rolled around: they shipped well performance 24-bit FP hardware, whereas NVIDIA shipped hardware with selectable 16- or 32-bit modes, where 16 bits was too little, and 32 bits was too slow. Cheers, / h+ Erwin de Vries wrote: > Hi, > > I've been trying to pack a float into 24 bits of an RGBA32 texture using a > ps2.0 shader, and after some experimenting have come up with a method which > works great on Nvidia ps3.0 hardware, which as far as i know use full 32 > bits precision in the pixel pipe, but i'm not seeing accurate results on ATI > 2.0 hardware, which seem to have only 24 bits of precision. > > I would like to store the depth value of the current pixel in a texture > using as much precision as possible, and would like to do it in a 32 bits > texture, because i'm using MRT, which forces all my rendertargets into the > same format. Is there any 'official', or commonly used conversion for this, > which also gives high precision (~24bits) on older ATI hardware? I need to > pack and unpack the value in a shader, but i think the actual packing is the > problem in my current implementation. > > Regards, > Erwin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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 > > > -- -- Revenge is the most pointless and damaging of human desires. |
From: J. K. <jak...@te...> - 2007-07-07 16:12:44
|
Hello Erwin, > I would like to store the depth value of the current pixel in a texture > using as much precision as possible, and would like to do it in a 32 bits > texture, because i'm using MRT, which forces all my rendertargets into the > same format. As far as I remember all current PC hardware forces the same bit depth for MRT render targets but the format can be anything that is supported by the GPU. So you can freely mix A8R8G8B8 with R32F and forget about the packing magic :) Regards, J. Klarowicz |
From: Tibor K. <tib...@gm...> - 2007-07-07 20:19:44
|
But be careful, as older hardware or driver revision might break things. Using Geforce 8 series, all is fine and dandy when mixing formats of same bit depth. On Geforce 7 series we had huge problems though, as it would absolutely kill the performance when mixed formats were used. I'm not sure if it was the hardware or the updated drivers when moving from GF7 to GF8 that fixed the problem. In the end we went with all RGBA 32-bit targets at that time and still use it. Make sure you test it thoroughly on a couple of card before going with a certain MRT setup. - Tibor J. Klarowicz wrote: > Hello Erwin, > > >> I would like to store the depth value of the current pixel in a texture >> using as much precision as possible, and would like to do it in a 32 bits >> texture, because i'm using MRT, which forces all my rendertargets into the >> same format. >> > > As far as I remember all current PC hardware forces the same bit depth > for MRT render targets but the format can be anything that is supported > by the GPU. So you can freely mix A8R8G8B8 with R32F and forget about > the packing magic :) > > Regards, > J. Klarowicz > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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: Jesus de S. G. <ic...@bi...> - 2007-07-04 16:24:22
|
I like to think in SH as a compression method of a function over a unit sphere. Instead of compress using SH, you could take n samples over that sphere and the rest could be inteporlated. At the end, you are taking different basis, but the concept is the same: I want to compress this values I have over this sphere. On 7/3/07, Stefan Sandberg <kef...@gm...> wrote: > > Um I can't see how that would be equivalent to SH.. Like, you know you > can break down a complex signal into it's base sine-waves? That's what > SH is, but on the surface of a unit sphere. > > Jesus de Santos Garcia wrote: > > Hi, > > > > yes, i understand you perfectly. The idea is a generalization of the > > classic lightmap. Instead of gather illumination from the normal, you > > gather information from 3 vectors in a basis. Now, with this > > information you can extrapolate the illumination to whatever normal. > > So for example, the normals from a normal map can be used. > > > > And, although not used in Half Life, you could extrapolate the > > information from the reflection vector to get an approximation of a > > specular approximation. Obviously it is a bad approximation (don't > > have enough information) but it is an effect that is view dependent. > > > > What I said, probably this is equivalent mathematically to SH, but to > > me is a lot more intuitive. > > > > On 7/3/07, *Stefan Sandberg* < kef...@gm... > > <mailto:kef...@gm...>> wrote: > > > > hm,, it seems my point was lost, but I was probably a bit vague, > > so I'll > > try to clarify what I meant. > > > > A 'lightmap' is just a (parameterized) texture of precomputed > > intensities/colors, like Quake, everyone is clear on that, but it > > becomes complicated when you start bringing in non-diffuse things. > > You > > can't just 'store' specular lighting in a texture, because it's not > > static, it involves the camera, ie, it's a function, not a value.. > You > > can mitigate this by storing something that will let you "solve for > > 'angle'", for example spherical harmonics (or more appropriately, > > hemispherical-harmonics). SH is not "lighting", it's just math, > > and has > > as much to do with lighting as a dot product has, so I just find it > > quite confusing to call that a "lightmap".. > > > > (Btw, I believe the 3 vector basis in hl2's shading has nothing to > do > > with it's specular shading) > > > > Jesus de Santos Garcia wrote: > > > At least to me, it is more intuitive the way Half Life 2 and > > Unreal do > > > this. > > > > > > Around each normal you have a 3 vector basis. You generate 3 > > radiosity > > > calculations for each vector. > > > > > > With this information you can get an approximation of the > > illumination > > > received by any point in any direction. This can be used to > > apply the > > > normal map to the low-res lightmaps or to simulate a specular > > > behaviour using the reflected vector. > > > > > > More information, in this Siggraph presentation: > > > > > > > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > > < > > > http://ati.amd.com/developer/siggraph06/Mitchell-ShadingInValvesSourceEngine.pdf > > > > > > > > On 7/2/07, *Jon Watte* <hp...@mi... > > <mailto:hp...@mi...> > > > <mailto: hp...@mi... <mailto:hp...@mi...>>> > > wrote: > > > > > > > > > > > > Stefan Sandberg wrote: > > > > Anything other than purely diffuse would be redundant when > you > > > store it > > > > in a lightmap. > > > > > > > > > > > > > > Not if you store a SH light map, which is what I'm > > suggesting to do. > > > > > > Cheers, > > > > > > / h+ > > > > > > > > > -- > > > -- Revenge is the most pointless and damaging of human > desires. > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and > > take > > > control of your XML. No limits. Just data. Click to get it > now. > > > http://sourceforge.net/powerbar/db2/ > > <http://sourceforge.net/powerbar/db2/> > > > <http://sourceforge.net/powerbar/db2/> > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDA...@li... > > <mailto:GDA...@li...> > > > <mailto:GDA...@li... > > <mailto:GDA...@li...> > > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > < > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > < > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > >> > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > <http://sourceforge.net/powerbar/db2/> > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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 > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > <mailto:GDA...@li...> > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > <https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list> > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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 > |