 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Spherical-harmonics for outdoor scenes. |
|
 |
pickups Member since: 6/17/2003 |
|||
 Posted - 8/3/2003 3:06:22 PM |
||||
| Hi. i have a question regarding SH. i noticed Yan_L always saying SH are good for terrain rendering. i dont understand why thi is so. can represent the material of mud and rock? or do you mean it looks good when combined with an appropriate BRDF? |
||||
|
||||
 |
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/3/2003 4:57:51 PM |
||||
| spherical harmonics are only good for lowfrequency lightenvironments.. and normally a sky is merely lowfrequently changing, means you can use a simple, small defined sh to represent the whole incomming light from the sky quite accurately.. "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/3/2003 5:22:50 PM |
||||
quote: SHs can't represent a surface, they just encode a lighting solution. As davepermen mentioned, skylight is very low frequency, and can be pretty well encoded into SH factors. Also important to note: you can rotate them. Means, that you can represent a moving sunglow and day/night cycles pretty well. |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/4/2003 3:10:34 AM |
||||
| uh, yeah, i forgot the rotation.. btw, you've done some tests with sh.. any visible results? you promised a lot of demos and papers and stuff wich we never seen yet (not only sh).. such a lot to do with the main business? "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/4/2003 9:26:36 AM |
||||
| Although time is a problem, it's not the main one. Actually, since I changed companies, I had to sign a very restrictive confidentiality agreement, that would cover anything related to our engine. I'll still be able to post algorithm descriptions, but new screenshots, demos or sources will be much more difficult, if not impossible. Our company has planned a couple of public demos for marketing purposes, but that's currently not a priority. Sorry about promising stuff, but I'm currently legally locked out. |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/4/2003 9:48:59 AM |
||||
| no problem. sad, but no problem.. i really hate stuff that is not open visible to evolve.. for example OpenML, wich was completely closed designed. rather stupid.. or OpenRT, wich gets completely closed defined, too.. i love to see stuff.. i don't normally steal it.. but, you can't do anything against that.. you should have a ghost-developer, who implements all your ideas directly :D too bad i'm the wrong dude for this.. "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/4/2003 10:44:56 AM |
||||
Yeah, I also don't really like that. I sold the exclusive distribution rights of the engine to VTales a couple of months ago. From a financial point of view, it was the only way to continue the development on the engine and later on, the game. I personally don't have the resources to do that on my own. I keep the copyrights, and I lead the development, but since they pay, they get the exclusive distribution and publishing rights for 5 years. After that, I'll probably GPL the whole thing. And honestly, it was also a personal financial decision, I get a lot of royalities that way (quite a shame for someone who generally is very pro-OpenSource and free software  ).Anyway, once I have a little more free time, I should write a new, free and open engine framework from scratch, albeit based on the current system structure. But this takes a lot of time, unfortunately. It is so much easier to run all those little tests and experiments (like the SH thing) on the existing engine. But then, I can easily run into legal problems when publishing the results. Wouldn't it be nice to be able to duplicate yourself multiple times to increase working efficiency ?  BTW, pickups, sorry for hijacking this thread. If you have further questions about spherical harmonics, feel free to force this back on topic ! |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/4/2003 11:14:23 AM |
||||
| YOU SOLD YOURSELF, YOU DIRTY BITCH!!! hehe:D sorry, that HAD to be written.. hm.. i know what you mean.. do you think sh could be useful for raytracing as well? dunno.. i'd bether would go with the proposed wavelet compressed cubemaps :D oh, and, for the original poster: spherical harmonics behave a bit like cubemaps, just very lowres ones.. and so you can have an environment map of the sky as sh, and do enlighten the whole landscape with it.. sh are simply lowres cubemaps where you can fast multiply and sum up all the corresponding values of two individual such cubemaps. about that at least.. "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/4/2003 11:23:37 AM |
||||
quote: *sniff*  *hides in a corner, just besides Gates and Bush* quote: Yeah, definitely go with wavelets. SH is currently acceptable in polygon based realtime rendering, because they are fast to implement on current pixel pipelines. Other than that, SH are a lousy approximation of incident light, mathematically speaking. The day better approximations are possible in hardware (eg. wavelets), SH will be obsolete. In your raytracer you don't have the limitations of a 3D hardware pipeline, so you should definitely consider a better incident light model. |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/4/2003 11:30:10 AM |
||||
| okaydo.. so i never have to touch that ugly piece of math:D (never liked it..).. its fun how much less of that funky math you need when you work on a raytracer.. but a lot of statistics for montecarlo/metropolis mess.. urgh.. hm.. i would love to "waveletize" my whole world.. would be quite useful for fast traces for glossy reflections for example.. hm.. :D "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
pickups Member since: 6/17/2003 |
|||
|
Posted - 8/4/2003 1:03:57 PM |
||||
| all right. i understand what you mean, but i still dont exactly get it. if, for example, i want to light my clouds with spherical harmonics, it wont be a wise idea, correct? what i mean is, this: if phong lighting makes objects look like plastic, and BRDFs makes them look metalic, what does SH make them look like? if i understand you correctly, it can make them look like both, or something else, dependd on the equation we store, right? |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/4/2003 1:18:30 PM |
||||
| you dont store an equation, you store a map. a map wich acts the same as a cubemap, and has for example this representation: per vertex/texel, a small cubemap storing in each direction, how much sky you see.. (for a flat land, that means the map has all 1 on the top hemisphere, and all 0 on the bottom side) in global: a skymap, storing the full sky-cubemap (one of those you can download for example..).. simple said, blue on the top hemisphere, and say.. black on the bottom hemisphere.. now you just multiply all the components of one of that skyvisibility maps with the actual skymap per vertex/texel/pixel (how ever you defined your skyvisiblitymap, hehe).. now after you multiplied all that together, you sum that all up, and divide trough the sum, and voilą, you got the average lighting on that vertex/texel/pixel!! the trick is now, that with sh, you can store such lowres cubemaps, and you can do that multiply-sum, all with a simple dotproduct (i think :D), very quick'n'dirty.. but sh are very lowres cubemaps, so only lowquality sky and lowquality skyvisibility can get stored => only very blurry shading in the end.. thats why its great for outdoor, wich big, fuzzy shadows "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/4/2003 2:47:21 PM |
||||
quote: This is a common source of misunderstanding. SH are a way to store a lighting solution, a little like lightmaps, for example. Unlike static storing methods, SH lighting can be somewhat dynamic. SH do not shade the surface. Phong shading, as well as BRDFs, both provide an approximation for light/surface interaction. They describe how light is supposed to act on a certain surface. SH, however, only provide the incoming light amount and colour, they do not describe surface properties. You can see them as a dynamic version of vertex lighting or lightmapping: if you replace your lightmaps with SH-maps, the surface shading aspect will be exactly the same. The lighting itself will be of much worse quality, but you'll get some interactivity in return. Just as standard lighting, SH lighting needs to be combined with a surface shader. Most of the time, that would be a Gouraud shader. You can also run it over Phong or Blinn (or even a BRDF, but that's wasted), but keep in mind that you will need to get the specular component from a different source. [edited by - Yann L on August 4, 2003 2:48:16 PM] |
||||
|
||||
|
Nik02 Member since: 12/18/2002 From: Lahti, Finland |
|||
 Posted - 8/4/2003 3:41:03 PM |
||||
quote: Therefore, SH, on it's own, makes the geometry look like soft diffusion rendered. Something like this, my old gift post: link This is not technically SH render, but the effect is the same. I'm writing my SH engine as we speak... |
||||
|
||||
|
pickups Member since: 6/17/2003 |
|||
|
Posted - 8/5/2003 12:56:06 PM |
||||
| so SH stores how much light hits a surface from every direction, so it should be used a parameter for a lighting equation? |
||||
|
||||
|
pickups Member since: 6/17/2003 |
|||
|
Posted - 8/5/2003 12:58:59 PM |
||||
| what do you think about the new wavelets method? it seems to address SH drawbacks. |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/5/2003 1:46:02 PM |
||||
| pickups, yes, it CAN store light incomming information, or outgoing information, or what ever information.. as i said.. look at it as a compressed cubemap.. yeah, the wavelets work much bether as it looks.. "take a look around" - limp bizkit www.google.com |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 8/5/2003 2:01:16 PM |
||||
quote: Small correction: SH store how much light hits a single point on a surface, from every direction. For basic SH lighting, those points are the polygon vertices. That's basically per-vertex lighting, interpolated over the polygon. For it to look good, you need a well tesselated 3D world. Or you can use SH-maps, where multiple points are defined per polygon, by using texture mapping. This is analogous to lightmapping. |
||||
|
||||
|
pickups Member since: 6/17/2003 |
|||
|
Posted - 8/5/2003 3:02:31 PM |
||||
| ok, i think i understnd now. so it wont work well with dynamic sky texture, right? not just rotated, i mean. but than, it is possibile to seperate the dynamic part from the sky. so if i light the terrain with a sky cube map (which is the light source) and SH, and combine it with a simple lighting model, the results would be an "area lit" terrain, lit with blue/orange light. right? |
||||
|
||||
|
davepermen GDNet+ Member since: 3/31/2000 From: Augst, Switzerland |
|||
|
Posted - 8/5/2003 3:05:23 PM |
||||
| yeah, about that.. well, if you can fast update your sh for the new skycubemap.. but, you could for example simulate your sky with several skylayers that just rotate around (well, for sky, that looks like moving:D), and modulate the different sh together to a final one, wich you use them.. remember, the sh is VERY lowres, so don't care much about accurate sky representations:D "take a look around" - limp bizkit www.google.com |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
