1,360
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
Implementing new features for FlightGear (view source)
Revision as of 05:50, 18 May 2014
, 18 May 2014→Case study - when is rendering simple?
| Line 190: | Line 190: | ||
A fairly recurrent question is why, with all the rendering effects we have on models, we don't have something simple as a reflection in water. After all, the math to determine the varying colors of a cloud at sunrise dependent on whether the light shines through them or not is university level, one needs to solve two nested integrals for the correct answer, whereas everyone knows how to compute a reflection. | A fairly recurrent question is why, with all the rendering effects we have on models, we don't have something simple as a reflection in water. After all, the math to determine the varying colors of a cloud at sunrise dependent on whether the light shines through them or not is university level, one needs to solve two nested integrals for the correct answer, whereas everyone knows how to compute a reflection. | ||
The problem is that real-time rendering is not simple when the math is simple, but when it can be parallelized. Graphics cards are built to solve a particular problem very fast - when a ray from the eye (E) hits a surface (S) and then is tracked to the light (L). If at the pixel location the surface normal is known, all relevant vectors are knows without having to know anything else about the scene, the computation is purely local and can be parallelized. So whenever an effect uses | The problem is that real-time rendering is not simple when the math is simple, but when it can be parallelized. Graphics cards are built to solve a particular problem very fast - when a ray from the eye (E) hits a surface (S) and then is tracked to the light (L). If at the pixel location the surface normal is known, all relevant vectors are knows without having to know anything else about the scene, the computation is purely local and can be parallelized. So whenever an effect uses an ESL situation, it is simple to implement. | ||
Water reflection however needs to compute at minimum ESSL (follow the light from the eye to the water, then to whatever is reflected in the water, then to the light). Raytracing codes solve these problems just fine, they track a large number of test rays from the first surface hit to everywhere else in the scene to see where the reflected light comes from. However, that doesn't run real time - if you use 10.000 test rays, the computational effort goes a factor 10.000 up and the framerate down by the same factor. What's perfectly okay if you can take a minute to render a picture is not if you need 60 per second. | Water reflection however needs to compute at minimum ESSL (follow the light from the eye to the water, then to whatever is reflected in the water, then to the light). Raytracing codes solve these problems just fine, they track a large number of test rays from the first surface hit to everywhere else in the scene to see where the reflected light comes from. However, that doesn't run real time - if you use 10.000 test rays, the computational effort goes a factor 10.000 up and the framerate down by the same factor. What's perfectly okay if you can take a minute to render a picture is not if you need 60 per second. | ||