Fij = cos(phi_i)*cos(phi_j) / (pi*r*r + shooter_area/m)
Radiosity - Form Factor
Author
Hello,
I'm currently working on a radiosity implementation of Coombe's paper "Radiosity on Graphics Hardware". Some of you may already know.
However, I have some troubles with the form factor. As far as I understood, the form factors should sum up to 1 in a row or a column of the form factor matrix.
Since in progressive radiosity we keep one patch fixed, this should correspond to calculating one row or column. Therefore the form factors should sum up to 1 for one shooting pass, if I am correct.
However, this seems not to be the case. If I place a light in a box the sum of the form factors equals, for example, ~38 for one shooting pass.
Here is the form factor equation I use.
where m is the number of patches of a face and r is the distance between patch i and patch j.
Maybe someone could clarify my problems. Thanks for your help!
Update:
If I take the classic form factor as defined by the Nusselt Analogon Fij = Aj*(cos(phi_i)*cos(phi_j))/(r*r*PI) (Aj beeing the area of the receiver) the form factors sum up two one. However, if the box is made up of triangles of different size, the intensity between these triangles changes.
[Edited by - Poons on July 10, 2007 7:01:59 AM]
Yes, with Progressive Refinement method, for each shooter, the sum of all form factors should sum up to 1.0f provided you shoot the light (from the shooter) to all receiving patches.
I`m not sure how far you already are with radiosity, but you definitely should make it work on simple cube first with rectangular patches and only then try to deal with triangle patches.
So, do something simple like this scene:
As for your first calculation of FF, where you divided "shooter_area" by "m", that`s absolutely physically incorrect and can surely be the cause of the error, especially if the triangles are irregular. Form Factor between two patches represents ratio - how much light travels between the patches. Therefore, for the simplification of the original radiosity equation to actually work, the shooting/receiving patches should be of same size.
I`m not sure how far you already are with radiosity, but you definitely should make it work on simple cube first with rectangular patches and only then try to deal with triangle patches.
So, do something simple like this scene:
As for your first calculation of FF, where you divided "shooter_area" by "m", that`s absolutely physically incorrect and can surely be the cause of the error, especially if the triangles are irregular. Form Factor between two patches represents ratio - how much light travels between the patches. Therefore, for the simplification of the original radiosity equation to actually work, the shooting/receiving patches should be of same size.
Author
Thanks VladR. I have now managed to get the form factors to sum up to 1 with the classic form factor equation. Somewhere in my calculation I have mixed up energy and intensity.
Do you know if it is possible to change the form factor so that light sources other than lambertian (cos(phi)) are supported? Say for example a spot light?
Do you know if it is possible to change the form factor so that light sources other than lambertian (cos(phi)) are supported? Say for example a spot light?
Not sure about actual equations, though you could manually check if the angle is within the cone. However, that would break the Fij = 1 assumption, so you`d have to somehow make the form-factors within the cone greater.
The only way to compensate for it seems to be calculating the volume of the cone in relation to the volume of the regular half-sphere and multiply each regular FF within the cone by this factor.
Still, there must be some other and simpler way - most probably a full equation is already available ? I am OK with regular area lights, so I haven`t researched any further, but I assume there must be plenty of papers describing the default FF for other types of light
F i,j = ((cosQ * cosR ) / (PI*r2 )) * H i,j * dA j
Or, if YannL,HellRaizer,Dee,davepermen, are reading this, they could share their knowledge ;)
The only way to compensate for it seems to be calculating the volume of the cone in relation to the volume of the regular half-sphere and multiply each regular FF within the cone by this factor.
Still, there must be some other and simpler way - most probably a full equation is already available ? I am OK with regular area lights, so I haven`t researched any further, but I assume there must be plenty of papers describing the default FF for other types of light
F i,j = ((cosQ * cosR ) / (PI*r2 )) * H i,j * dA j
Or, if YannL,HellRaizer,Dee,davepermen, are reading this, they could share their knowledge ;)
Author
Quote:Original post by VladR
Still, there must be some other and simpler way - most probably a full equation is already available ? I am OK with regular area lights, so I haven`t researched any further, but I assume there must be plenty of papers describing the default FF for other types of light
I have already googled around but did not find any information on that. Maybe I'm just searching for the wrong key words but it seems that there is no information on that available.
I have done some tests, the result is visually ok, however as you said the form factors to not sum to 1 any more. I thought of also replacing PI by the projected area of the new intensity distribution, because as far as I understand it the PI term comes from the projected area of the halfsphere. But I'm not sure how to get the intensity function from a given energy distribution.
However, thanks for your suggestion, I will give it a try.
Quote:Original post by VladR
Or, if YannL,HellRaizer,Dee,davepermen, are reading this, they could share their knowledge ;)
That would by highly appreciated.
"Do you know if it is possible to change the form factor so that light sources other than lambertian (cos(phi)) are supported? Say for example a spot light?"
A spot light is basically a diffuse emitter placed inside a black cone, so, it is not necessary to rework the radiosity equation for directional emitters. Just build one. :)
-- Jani
A spot light is basically a diffuse emitter placed inside a black cone, so, it is not necessary to rework the radiosity equation for directional emitters. Just build one. :)
-- Jani
Quote:Original post by The Scytheman
A spot light is basically a diffuse emitter placed inside a black cone, so, it is not necessary to rework the radiosity equation for directional emitters. Just build one. :)
Yeah, I`ve thought about it already, but immediatelly discarded this idea because then the actual size of the scene patch would have to be extremely small, otherwise you`d get obvious edges when the light source would be near the receiving objects.
And that would be a significant quality downgrade compared to absolutely smooth color transitions that the regular equation produces.
I haven`t actually tried the method that I proposed 2 replies above, but I still think it`s tweakable this way, and though it might not be physically correct, it still might produce usable results (and definitely without any edges from the tesselated black light cone). Everything is tweakable, though for a price.
Well, another option would be to compute the direct lighting, in other words, reflected radiosities, caused by the spotlight and use them as light sources during the actual radiosity solution. This way you can have dynamic spotlights for "cheap" as the form factors remain unchanged.
The downside is that the light source isn't modeled as a physical object contributing to the geometry of the scene, but I think you can live with that.
I pretty sure this is the special-case those "real-time radiosity" technologies are based on.
-- Jani
The downside is that the light source isn't modeled as a physical object contributing to the geometry of the scene, but I think you can live with that.
I pretty sure this is the special-case those "real-time radiosity" technologies are based on.
-- Jani
I`m not sure if I understand you exactly but do you mean that you`d create one circle "layer" of the light patches (at some distance from the light source) and each patch of this layer would be regarded as a light source ?
Because each of those patches would still emit the energy all around within its hemisphere, whereas the spotlight emits energy only within its volume.
I don`t understand your point here. Why do you think that radiosity couldn`t be real-time for game environments ?
Or maybe you mean that, what those demos show, isn`t the actual physical radiosity ?
It may not be suited well to all indoor environments, but lots of games still use just flat rectangular walls - like F.E.A.R. and that`s the kind of environment that the radiosity loves and gives best results in. Sure, the characters would have to cast shadows using some common shadowing algorithm, but the walls and corresponding static objects could be lit through radiosity. Form factors for first few passes could be either precalculated or simply calculated on the fly over the course of several frames. If you devoted one core to preparing radiosity data, you`d still be left with at least 1-3 idle cores for the game and that`s enough.
I really hope I find the time this autumn/winter to port my early real-time radiosity solver to Core2 Duo and SSE4. It gave fantastic results already on AMD XP2500 and was far from optimized.
Because each of those patches would still emit the energy all around within its hemisphere, whereas the spotlight emits energy only within its volume.
Quote:I pretty sure this is the special-case those "real-time radiosity" technologies are based on
I don`t understand your point here. Why do you think that radiosity couldn`t be real-time for game environments ?
Or maybe you mean that, what those demos show, isn`t the actual physical radiosity ?
It may not be suited well to all indoor environments, but lots of games still use just flat rectangular walls - like F.E.A.R. and that`s the kind of environment that the radiosity loves and gives best results in. Sure, the characters would have to cast shadows using some common shadowing algorithm, but the walls and corresponding static objects could be lit through radiosity. Form factors for first few passes could be either precalculated or simply calculated on the fly over the course of several frames. If you devoted one core to preparing radiosity data, you`d still be left with at least 1-3 idle cores for the game and that`s enough.
I really hope I find the time this autumn/winter to port my early real-time radiosity solver to Core2 Duo and SSE4. It gave fantastic results already on AMD XP2500 and was far from optimized.
VladR: "I`m not sure if I understand you exactly but do you mean that you`d create one circle "layer" of the light patches (at some distance from the light source) and each patch of this layer would be regarded as a light source ?"
Yes. That's what I mean, BUT the emittances of those patches are the reflected radiosities caused by an imaginary spotlight. In other words, this would involve a preprocessing step in which you intersect the cone of your spotlight with the world geometry (the patches) and compute the reflected radiosities for those patches caused by the spotlight. In short, the highlight caused by your spotlight will be an area light source fed to the radiosity solver. The final solution will contain the highlight and all the GI effects caused by it. Perfect.
The nice thing about this method is that you get all those groovy global illumination effects for a moving light. The "only" recomputation you need between frames would be the multiplication of the inverted radiosity matrix with the vector of emitted radiosities. Of course, this is all very simple for simple scenes and a lot of cleverness is needed to get it running for your average Unreal 3 level, but the basic idea is there.
"Why do you think that radiosity couldn`t be real-time for game environments ?"
Any algorithm can be real-time for arbitrary environments. Just throw silicon at the problem. That's not the point.
The problem with the term "real-time radiosity" is that it does not address the extent to which the radiosity algorithm is real-time. By this I mean how dynamic the input data (geometry, reflectances, emitted radiosities) is allowed to be.
With static geometry and static light sources you're certainly going to be achieving real-time performance. We've seen that in Quake etc. ages ago, but that's boring.
How about dynamic light sources (updates to the emitted radiosities vector). Looking at the radiosity equation it is clear that this is the next logical step now that we have the extra computing power. This is basically what I've been talking about, but with a twist to accommodate a virtual spotlight.
Radiosity with dynamic geometry on the other hand would be very hard to get running in real-time on today's PCs for anything but uninteresting test scenes. And the only problem isn't the recomputation of form factors alone as you might need to think about things like meshing etc. to avoid all the classic artifacts and problems of the radiosity algorithm.
UPDATE: Sorry, didn't read your whole post. So you're taking a shot at this dynamic geometry problem? Yeah, some kind of clever FF caching scheme with only local updates to the geometry allowed is the way to go. But it still is very hard to make it robust (and fast) for different scenes.
Interesting. :)
-- Jani
[Edited by - The Scytheman on July 18, 2007 2:47:51 AM]
Yes. That's what I mean, BUT the emittances of those patches are the reflected radiosities caused by an imaginary spotlight. In other words, this would involve a preprocessing step in which you intersect the cone of your spotlight with the world geometry (the patches) and compute the reflected radiosities for those patches caused by the spotlight. In short, the highlight caused by your spotlight will be an area light source fed to the radiosity solver. The final solution will contain the highlight and all the GI effects caused by it. Perfect.
The nice thing about this method is that you get all those groovy global illumination effects for a moving light. The "only" recomputation you need between frames would be the multiplication of the inverted radiosity matrix with the vector of emitted radiosities. Of course, this is all very simple for simple scenes and a lot of cleverness is needed to get it running for your average Unreal 3 level, but the basic idea is there.
"Why do you think that radiosity couldn`t be real-time for game environments ?"
Any algorithm can be real-time for arbitrary environments. Just throw silicon at the problem. That's not the point.
The problem with the term "real-time radiosity" is that it does not address the extent to which the radiosity algorithm is real-time. By this I mean how dynamic the input data (geometry, reflectances, emitted radiosities) is allowed to be.
With static geometry and static light sources you're certainly going to be achieving real-time performance. We've seen that in Quake etc. ages ago, but that's boring.
How about dynamic light sources (updates to the emitted radiosities vector). Looking at the radiosity equation it is clear that this is the next logical step now that we have the extra computing power. This is basically what I've been talking about, but with a twist to accommodate a virtual spotlight.
Radiosity with dynamic geometry on the other hand would be very hard to get running in real-time on today's PCs for anything but uninteresting test scenes. And the only problem isn't the recomputation of form factors alone as you might need to think about things like meshing etc. to avoid all the classic artifacts and problems of the radiosity algorithm.
UPDATE: Sorry, didn't read your whole post. So you're taking a shot at this dynamic geometry problem? Yeah, some kind of clever FF caching scheme with only local updates to the geometry allowed is the way to go. But it still is very hard to make it robust (and fast) for different scenes.
Interesting. :)
-- Jani
[Edited by - The Scytheman on July 18, 2007 2:47:51 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement