At 05:09 AM 11/29/2004, Bob Aman wrote:
> It *should be* painfully obvious to any student of computer graphics
technology
> that the claim is false.
>
> Why?
> [snip]
Unfortunately, you make one big assumption that is flawed because you
failed to take into account the possibility that Valve isn't worried
about modelling radiosity completely accurately.
This statement would seem to demonstrate that you are somewhat ill-informed
in this matter.
"Radiosity" is a particular methodology for modelling diffuse (scattered)
illumination in a scene. It is a methodology for modelling the phenomenon,
not something that is itself modelled.
The general procedure involves dividing up all the surfaces present in the
scene into thousands of small patches and assigning initial radiance values
to each of these patches. Only actual light-emitting surfaces have non-zero
initial radiance.
For each iteration of the radiosity solver, every single patch that has a
line-of-sight to another patch, receives radiance from and contributes
radiance to the other visible patch. So this radiance energy gets distributed
from light sources to surfaces. Any patch with non-zero "radiosity" becomes
a new source of illumination for the next iteration and the process is repeated
over the entire scene again as many times as one desires to achieve a
"good" distribution of the available illumination for that image frame.
The only variables that govern the accuracy of the radiosity solution are two:
(1) the size (and therefore quantity) of the subdivision patches and (2) the
number of iterations of distributing the illumination through the scene for
a particular rendering frame.
The only available speed ups involve precomputing patch-to-patch visibility,
which does not work for any dynamic objects and light sources in the
scene.
The less patches used, the more pronounced become the visual artifacts as
the shadowed areas develop "jaggies". The less iterations used, the more
areas of the map remain un-naturally dark, as the illumination was not allowed
to scatter far enough. These unwanted effects can be plainly seen in any
Quake and Half-Life 1 maps that for with QRAD was run with very low detail
settings (in order to reduce the time required to compute the lighting).
The algorithm is *exponential* in terms of time consumption as the number
of patches is increased and linear with the number of iterations. At a minimum
level of accuracy, such that the players would not notice the artifacts, the
amount of computation required per frame is astronomical and well beyond
the range of any available consumer hardware for a *real-time* radiosity
solution, as I stated before.
If some other methodology were chosen to model the diffuse illumination element
in a scene in *real-time*, it would be SOME OTHER ALGORITHM and not
"Radiosity", therefore Source engine does not have "real-time radiosity" as
claimed
on their web site.
Q.E.D.
You'd probably be
100% correct if Valve was claiming to have fully accurate realtime
radiosity support. However, they do not make this claim, and it seems
to me that given that there are articles out there on doing inaccurate
realtime radiosity, you're probably overreacting.
It would be more truthful to state that there are articles out there by
amateur
persons (Gamedev.Net) who are incorrectly calling their inaccurate diffuse
illumination solutions "radiosity". The actual Radiosity algorithm is well
defined and well documented in academic publications, though perhaps
these amateur persons have failed to study them sufficiently thoroughly.
Amusingly enough, I found an article on ACM about doing realtime
radiosity as well, but it basically consisted of "throw lots of
hardware at the problem".
--
Bob Aman
http://www.rapidcanvas.com
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
