 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 »» |
Last Thread Next Thread |
| Terrain -> Fog -> Sky |
|
 |
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
 Posted - 12/20/2002 2:40:03 AM |
||||
| How do you create smooth transitions from terrain (with distance fog) to sky/background. I did a bit of research and found 2 methods used all over the place. I implemented them but they both have some troube. 1) make sky same color as fog at horizon and just draw terrainwith fog as normal. This is extremly easy to implement but it looks like crap. 2) the second idea is from one of c. bloom's papers and it invoves first rendering scene to z buffer only (no color writes) then rendering agian with depth test set to equal and with alpha blending enabled, using fog factor as alpha. This looks *great* but the trouble is there is twice as much stuff to draw now. So my question. Is there a 3rd way. You know, better/faster/nicer.... any ideas would be welcome. You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 12/20/2002 5:45:50 AM |
||||
| Basically, for it to look right, the terrain has to blend to whatever color the sky is at the point behind the terrain. If the sky is yellowing towards the horizon, then the terrain must get progressively more the color of the sky (in this case, yellow) as it recedes. But if the sky is less yellow higher up, then a high mountain will be less yellow, and blend to the color of the sky behind the mountain. This is a simplistic explanation, but it will work. One way is to render the sky first. Then render the terrain in a depth sorted order, close to far. All terrain is rendered semi-transparent, blending to more transparent the further away it is. Thus, further terrain is progressively more transparent, blending to the color of the sky behind it. Another way is to render the sky first. Then, compute what section of the sky's texture is projected on to the terrain face currently being rendered. Then, depending on the terrain face's distance, blend the terrain face accordingly with the projected sky section. |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 12/20/2002 7:20:02 AM |
||||
| That's like my second method. But sorting all the tiangles is bad. It totaly kills your framerate since most of data is in AGP or video memory. The alternative is like I mentiond drawing to depth first and then the color in 2nd pass. >>Another way is to render the sky first. Then, compute what section of the sky's texture is projected on to the terrain face currently being rendered. Then, depending on the terrain face's distance, blend the terrain face accordingly with the projected sky section.<< This one I don't get. I understand how this would work with rendring water but not terrain. I don't think trrain shuld "reflect" sky color. Or am I totly off here? You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 12/20/2002 2:36:56 PM |
||||
| It's not reflecting the sky color. It's achieving the exact same thing as the first method. Determine the tx coords of the sky exactly from the viewer through each vertex of the terrain's face to the sky. Now you know the exact 'piece' of sky (in tex coords) that is behind the terrain face as viewed from the viwer. Use those tex coords to blend with the terrain face modulated by the distance of each terrain vertex from the viewer. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 12/20/2002 2:38:25 PM |
||||
| Another thing: if your terrain is based on a grid or quadtree, you should be able to scan the grid or quadtree in order without having to do a sort. |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 12/21/2002 9:05:18 AM |
||||
| I've tried this one. Looks nice but it's even slower then my second method. Also much more work to implement to work with any kind of scene... I guess I'll have to stick with one of "my" methods... You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 12/21/2002 10:36:02 AM |
||||
| You have to keep in mind, that the terrain colour is not directly influenced by the sky colour. It is influenced by the lighting of the atmosphere, and so is the sky. In reality, the colour of a distant object is determined by complex physical processes. But we can approximate those by some simple concepts: the colour of an object is determined by it's local lighting, and this lighting is scattered by the atmospherical particles between the object an the viewer. In addition to this light, the skylight is also scattered into the viewing ray. As in most realistic volume effects, the classical scattering intgral can be used. Now, the result of that equation does not only change the fogfactor, but also the fogcolour. The colour is not uniform, it depends on your viewing direction, and distance. So, the first thing you need in order to get good and fast atmospherical haze simulation, is a fogfunction that let's you specify the fogcolour per-vertex and the fogfactor as a combination of a per-vertex and per-pixel function. This can be achieved by a simple pixelshader or regcom setup. Ie, the final fog is computed using those equations: fog_colour = interpolated vertex fog colour (secondary colour) fog_factor = interpolated vertex fog factor + per-pixel exponential distance fog. In normal operation, you would set the interpolated vertex fog factor to zero, so that only the perpixel distance term is active. But you will need this factor to increase the fog density around the sun-halo (see below). If we use the classical blending equation for fog application onto the geometry (colour = (1-fog_factor)*object_colour + fog_factor*fog_colour), then fog_factor represents the result of the scattering density integral, and fog_colour the result of the colour scattering integral. Since we want the fog_factor to be automatically computed perpixel as the distance, we assume that the density along the scattering path is always constant and exponential with distance. This assumption holds, if more light gets scattered into the viewray from the object, compared to the skylight. It gives pretty good results in all cases, except if you look into the sun. In this case, the approximation breaks down, and this is why we need the per-vertex fog_factor addition. OK, now you are ready to compute the fog parameters per vertex. The per-vertex fog_factor is pretty simple: it is always zero, except in the range of the sun halo, where it fades to one. This will make the fog density go up in the direction of the sun (due to increased backscatter), and create a kind of haze-halo on the sun near geometry. Consider this screenshot, you'll notice how the rocks near the sun seem to glow:  Next, you need to compute the colour. That's a bit trickier, as you will have to approximate the scattering integral for each vertex. There are several methods to accelerate that process, the easiest is by using a sky-environment map. Basically, you combine the colour of the haze itself (from white to blueish, or any other colour for alien-planet like effects) with the suncolour (depending on the dotproduct between sunlight direction and the vertex's normal) and the skycolour at the direction of the vertex's normal (ie: imagine the vertex normal pointing out into a sky-environment cubemap. Pretty much like a reflection vector, but view-independent). There are more complex and realistic models (using cloud cover parameters, and direct integration of the scattering function through a voxel 3DDDA), but those are significantly more complex. You should first try the simple method, it will already yield good results on most scenes. Now, the last point to consider, is the effect of the atmosphere onto the sky itself. This one highly depends on how your rendere your sky (skydome, procedural sky, skybox, etc). The idea is to project low-altitude viewing rays for the sky near the horizon, and approximate their scattering integrals. Just as done with the objects above. To be accurate, you would have to do that for the entire skydome, but it's a good approximation to only compute them at a low altitude, since it's here that the scattering rays will traverse the most atmospherical particles. You can find some good reference papers about all this at vterrain.org. Esp. the paper "A Practical Analytic Model for Daylight" by Preetham, Shirley & Smits explains the concepts I outlined above in greater detail. / Yann |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/28/2003 2:03:38 PM |
||||
| after (finaly) implementing that paper my sky/terrain looks like this http://www2.arnes.si/~ssdmtera/pic/U2E_00.jpg http://www2.arnes.si/~ssdmtera/pic/U2E_01.jpg http://www2.arnes.si/~ssdmtera/pic/U2E_02.jpg You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
python_regious Member since: 2/28/2001 From: Bath, United Kingdom |
|||
|
Posted - 1/28/2003 2:12:20 PM |
||||
| Cool, thats some nice terrain you got there. I like. Death of one is a tragedy, death of a million is just a statistic.  |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/28/2003 2:15:49 PM |
||||
| So what was the final methodology that you settled on using? |
||||
|
||||
|
stodge Member since: 6/22/2001 |
|||
|
Posted - 1/28/2003 3:08:14 PM |
||||
| Wow, that last screenshot is just beautiful! |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/28/2003 3:49:19 PM |
||||
I used some most from "A Practical Analytic Model for Daylight" and a few other papers (and sky thread) and a few of my own.. Wierd mix but it works (for now  ) You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/28/2003 3:52:40 PM |
||||
| That doesn't answer my question though. It's not the sky color that I'm intertested in. What I'm interested in is what methodology did you settle on with regard to the original question you were asking in this thread. |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/28/2003 5:19:05 PM |
||||
| Drawing terrain twice. First only to depth buffer then once again in color with blending. Blending factor is calculated in vertex program as exponention or linear (depends on switch) function of distance from eye. You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/28/2003 5:29:22 PM |
||||
| Ok, so let me get this straight. The first pass is to determine which polygons of the scene are actually visible, so you are only rendering to the depth buffer. We can assume the sky has already been rendered, with color at this point. The second pass sets your depth function to EQUAL, so that no overdraw occurs, which would mess up our blend with the sky. Am I correct? |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 1/28/2003 5:47:10 PM |
||||
| DarkWIng: looks very nice. Seems like a good implementation of the analytic daylight paper. Good work. Did you also implement the aerial perspective part ? Oh, and btw, out of curiosity: which way did you choose to convert Yxy to RGB ? Direct conversion, or going through a spectral power distribution ? If direct, did you use the standard rec.709 conversion matrix, or a different one ? Pretty much everyone i know who implemented this algorithm, ended up using a different matrix here... |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/29/2003 3:49:53 AM |
||||
| bishop_pass : yep! you're right. I was thinking of posibility of including nv_occlusion_test on second pass. just set query in 1st pass and when coming back the second time ask if patch was even visible (not occlued by some hill). this could be virtualy free. [edit] Ouch! Was I wrong. I tested the nv occlusion thing and the results were bad. just bad. there was about 10% increase in framerate on lowpoly scenes but when I increase polycount it worked actualy sower then whitout occlusion. Yann L: Thanks! I haven't implemented aerial perspective yet. I will when I get some more free time. Convertion looks like this (straight copy&paste from my code)
inline UColor UColor::ConvertXYZtoRGB() {
UColor result;
result.cR = 3.240479f * cX - 1.537150f * cY - 0.498535f * cZ;
result.cG = -0.969256f * cX + 1.875992f * cY + 0.041556f * cZ;
result.cB = 0.055648f * cX - 0.204043f * cY + 1.057311f * cZ;
return result;
}
I didn't know there are more ways to do it? Can you give me some other examples. You should never let your fears become the boundaries of your dreams. [edited by - _DarkWIng_ on January 29, 2003 5:11:10 AM] |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 1/29/2003 10:35:55 AM |
||||
quote: Well, there are various different conversion matrices floating around. You used the standard rec.709 matrix, with D65 whitepoint. That's a modern conversion matrix, specifically created for newer monitor/TV phosphors. I can recall that someone (I think it was greeneggs ?) got some pretty funny results on the sky colours, when he used a conversion matrix for 1958 TV's... Another possibility is to convert the tristimulus values to an SPD (spectral power distribution), as described in the appendix of the paper. And later on, reintegrate into RGB. For just rendering sky colours, that's pretty useless, and your method is the most efficient. But it can be useful, eg. if you want to do some high dynamic range lighting (HDRI) or radiosity from the skylight onto the geometry beneath./ Yann |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/29/2003 11:45:45 AM |
||||
| I've got some question about this paper. How do you handle sun under horizon. There should still be some kind of glow at the sky but with code from this paper you get just black(or some very unrealistic color). For now I hacked the thing so it clamps vertices on skydome to y=0 when calculating colors. Another thing is color of (sun)light. I use it to shade it terrain. I get it by geting color from vertex in sun direction. Is there a better aproach? >>> I can recall that someone (I think it was greeneggs ?) got some pretty funny results on the sky colours, when he used a conversion matrix for 1958 TV's... <<< Where can I get some diferent matrices? You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/29/2003 2:46:38 PM |
||||
quote: The terrain, and clouds, are not necessarily the recipient of the color of the sun as viewed by your viewer. Let's assume that the viewer is lower in altitude than some other object. Once the sun is visible to the viewer, the viewer will receive a warmer color temperature from the sun than the higher altitude object, due to the sunlight being scattered by more atmosphere and denser atmosphere. However, before the viewer is receiving light from the sun (before sunrise) or after the viewer is able to receive light from the sun (after sunset) the higher altitude objects are receiving light from the sun. And this light can (and will) be of a warmer nature than could possibly be received by the viewer, because the higher altitude objects can receive the light through a longer stretch of atmosphere. Therefore, the color of light received by objects is a function of the object's altitude. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/29/2003 4:38:42 PM |
||||
The overall distance that light can travel through the atmosphere for high altitude objects is greater than what light can travel throught the atmosphere for low altitude objects. Look at the diagram below, where the sun has already set for a viewer standing at the base of the mountain, but it has not yet set for the mountain peak. The viewer will see a very warm light on the mountain peak. So, high altitude objects can receive light of greater absolute warmth (cooler light temperature) than low altitude objects. However, when both high altitude objects and low altitude objects are illuminated simultaneously, the low altitude object is (relatively) receiving a warmner light than the high altitude object, because the light is traveling through more atmosphere and denser atmosphere at that particular time. Look at the diagram below to see this:  The two photographs that you see below I took within the space of about forty-five minutes and within a hundred feet of each other. They illustrate exactly what I am describing above. The first photograph is long after the sun has set for me, but it is still illuminating the high altitude clouds above. They are receiving warm light, and, depending on the altitude of the clouds, they have the potential to receive light of greater warmth than is ever possible for low altitude objects.  In the photograph below, it was taken at about sunset time for me. Technically, the sun already set for me, but only minutes ago, and it is illuminating the hill in front of me. Note the warmth of the light on the hill as compared to the warmth of the light on the clouds. This is a case of simultaneous illumination of both low and high altitude objects by sunlight. This corresponds to the second diagram I presented, where the low altitude object receives light through a greater quantity of atmosphere than the higher altitude object. There is one other thing to note in the picture below. Although the hill is considered the low altitude object, it still benefits from being at an altitude of 5,000 feet, meaning that overall, it has the potential to receive a nice quality warm tone, as you see in the image, moreso than an object at sealevel.  [edited by - bishop_pass on January 29, 2003 4:39:58 PM] |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/29/2003 4:43:54 PM |
||||
| Thanks for GREAT explanation. Now I only have to find some smart way to implement this You should never let your fears become the boundaries of your dreams. |
||||
|
||||
|
bishop_pass GDNet+ Member since: 6/3/2000 From: California, USA |
|||
Posted - 1/29/2003 4:53:30 PM |
||||
| You replied shortly after I made some edits and additions. I hope you caught my revised explanations. I think you did, but I'm not sure, and we're on a new page now, so I don't want my hard work to be missed. |
||||
|
||||
|
greeneggs Member since: 4/9/2002 |
|||
|
Posted - 1/30/2003 8:01:06 PM |
||||
| Thanks for pointing out this alpenglow effect. It seems to be extremely important for things like sunsets lighting clouds. Previously I'd just seen hand-lit clouds at sunset, but you should be able to physically calculate the correct lighting when you take into account altitude and sun angle. |
||||
|
||||
|
_DarkWIng_ Member since: 1/11/2001 From: Duplje, Slovenia |
|||
|
Posted - 1/31/2003 11:38:01 AM |
||||
| bishop_pass : I've been thinking a bit about this and came up with idea that might work. I was thinking more in the lines of maing it run fast and look somehow nice than making it correct. I don't know how to implement it (yet) but anyways... Each frame(of when sun moves) you create 1D texture what stores sun color for diferent altitutes of terrain based on curent sun position. Then use vertex height as texture coordinat to this texture. And in register combiners(or fragment program) use this color as base color to lit terrain. So at noon this texture would be almost totaly white, while at sunrise/sunset it would be a gradient something like yellow...red...dark blue...black. So high moantains would still be lit by sun while lower parts would be already in the dark. The problem is I don't know how to calculate this texture. The only idea I have have is to create a point at different altitutes and integrate air density along the ray to the sun (or something like that). Any comments on the whole idea? Is it worth trying to implement? [edit] typos... You should never let your fears become the boundaries of your dreams. [edited by - _DarkWIng_ on January 31, 2003 11:39:27 AM] |
||||
|
||||
|
Page: 1 2 »» All times are ET (US) |
Last Thread Next Thread |
|
