This topic is 3801 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.
Fij = cos(phi_i)*cos(phi_j) / (pi*r*r + shooter_area/m)


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]

##### Share on other sites
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.

Im 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", thats 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.

##### Share on other sites
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?

##### Share on other sites
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 youd 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 havent 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 ;)

##### Share on other sites
Quote:
 Original post by VladRStill, 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 havent 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 VladROr, if YannL,HellRaizer,Dee,davepermen, are reading this, they could share their knowledge ;)

That would by highly appreciated.

##### Share on other sites
"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

##### Share on other sites
Quote:
 Original post by The ScythemanA 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, Ive 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 youd 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 havent actually tried the method that I proposed 2 replies above, but I still think its 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.

##### Share on other sites
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

##### Share on other sites
Im not sure if I understand you exactly but do you mean that youd 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.

Quote:
 I pretty sure this is the special-case those "real-time radiosity" technologies are based on

I dont understand your point here. Why do you think that radiosity couldnt be real-time for game environments ?
Or maybe you mean that, what those demos show, isnt 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 thats 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, youd still be left with at least 1-3 idle cores for the game and thats 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.

##### Share on other sites
VladR: "Im not sure if I understand you exactly but do you mean that youd 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 couldnt 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]

##### Share on other sites
@The Scytheman: Thanks for your suggestions regarding spotlights. But my intention was to find a way to alter the form-factor equation. Because this way it should be possible to accommodate for many different light sources with more complicated light distribution patterns.

@VladR: I will try your suggestion with the volumes. I will have to compare the volumes of the intensity distribution of the light sources, since the halfsphere is the intensity distribution of the standard lambertian light. Is that right?

regarding real time radiosity, you may take a look at "realtime radiosity bugs". it was shown at the eurographics conference in vienna last year.

##### Share on other sites
Poons: "regarding real time radiosity, you may take a look at "realtime radiosity bugs". it was shown at the eurographics conference in vienna last year."

Yeah, I've seen that. As far as I can remember, the only thing dynamic in that demo is the light sources. The geometry is static, isn't it?

So, if the geometry is static, that is basically an example of the method I've been talking about.

Recently the Geomerics real-time radiosity technology "Enlighten" has been on the news (http://www.geomerics.com/enlighten-sdk.htm). Based on its documentation it's also, at heart, an example of the method. This is what it says in the SDK documentation:

"The core radiosity runtime component of Enlighten takes the __result of your direct illumination__ in the form of a texture, which represents something similar to a light map. It returns as output other textures representing all of the bounced light computed for that frame which can be sampled inside your shaders."

.. and the geometry is static:

"Enlighten currently requires a one-off geometry pre-compute stage, and stores the results of this for use as additional input to the runtime system. ... This allows you to re-texture and light your world in real time."

This is exactly what I was talking about. You can do all kinds of light sources as long as you're able to quickly compute the direct illumination caused by the sources and feed the lit areas as light sources to the radiosity solver.

Poons: Yeah, this is not equivalent to incorporating non-diffuse light sources to the radiosity algorithm, but for those interested in getting real-time global illumination effects it's something to think about.

-- Jani

##### Share on other sites
Quote:
 Original post by The Scytheman.. and the geometry is static:

You will notice, though, that there is a moving character also affected by the radiosity solver. Currently a pre-compute step is the most efficient method of generating your radiosity data for static geometry, as you'd expect. The website isn't really very clear on that point, I suppose.

##### Share on other sites
Indeed, but the question is how exactly is the character affected by the radiosity solver? Is the moving character part of the complete GI solution? I think not, as that implies radiosity with dynamic geometry. It's possible though, but unlikely.

The character is probably lit by an environment map computed after the radiosity solution has been computed sans the character and the shadows cast by the character are computed with standard shadow algorithms. This is not equivalent to a full radiosity solution taking into account the character's presence.

If somebody has more precise information please share it. Interesting stuff. :)

-- Jani

##### Share on other sites
No, you're absolutely right there. I was merely suggesting that perhaps Poons could mix and match methods, though I don't personally believe that he should do so. As you say, it would suddenly become a fractured GI solution, but it is a quick and dirty way of doing it.

Good luck Poons :)

##### Share on other sites
The moving characters can be lit by radiosity solution. We just calculate the shadows using some other shadowing algorithm. The difference wil be negligible, so its no use to loose precious cycles with calculation of character shadows through radiosity solver.

You just treat the vertices of your character as patches. Since characters can be reasonably detailed these days, its a nice trade-off compared to full tesselation of character mesh into patches. You might spot some differences on comparison screenshots, but surely not in a full game.

But the characte would be correctly lit taking into account all lights around him with all their specific distances/intensities/directions.

With some interpolation of form factors (i.e. calculating precise FFs only each character frame (not render frame)), results should be unrecognizable from full radiosity solver, provided decent resolution of original character mesh.

##### Share on other sites

This topic is 3801 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628663
• Total Posts
2984111

• 10
• 10
• 9
• 9
• 10