• Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

# Radiosity Calculations => Lightmaps (???)

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

9 replies to this topic

### #1hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 18 April 2003 - 05:30 AM

### #2Yann L  Moderators   -  Reputation: 1754

Like
Likes
Like

Posted 18 April 2003 - 02:02 PM

For the most simple approach, a patch simply equals a lightmap texel. So, first create lightmaps for your scene, just as you did before. Try to keep them isotropic, ie. the texels should be more or less quadratic. This does not mean that the lightmap can't be rectangular, only the worldspace size of a mapped texel should be roughly a quad. That's for radiosity accuracy.

Then, you consider each lightmap texel to be a patch. Once your radiosity solution is computed, you have the radiance values for every patch (= for every lightmap texel). Note, that your patch radiosity will probably not be in the 0-255 range, so you'll have to remap it. Linear remapping gives pretty dull results, and will kill much of the 'radiosity touch'. You should use an exponential exposure funtion instead. This one, for example. Histogram based HDR remapping is even better, but a little more complex.

At this point, you simply assign the exposure corrected radiosity values to the lightmap texel colours. Done.

More advanced radiosity algorithms can combine several texels into a single patch (to shoot from, you get better speed from that) or subdivide texels into several patches while recieving (creating better visual quality). Adaptive subdivision is also possible, where you refine the resolution of your lightmaps according to the radiosity gradients on the object.

[edited by - Yann L on April 18, 2003 9:04:15 PM]

### #3hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 19 April 2003 - 12:58 AM

Thanks a lot Yann!!!!

I did what you said about lumels. Every lumel is a patch, so i hold a world position for every lumel (patch''s center), and i calculate patch''s area. Those two values seams to be enough. Also which byte in image data, a specific lumel represents, was usefull, because i didn''t want to mess up with recalculating pixel position, after radiosity calculations.

I realized that there is a problem with linear remapping, and i tried to solve it with restricting radiosity values to 255. But the results weren''t good. So now i''ll try exposure function!!!

Thanks again!!!

HellRaiZer

### #4hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 19 April 2003 - 04:08 AM

Hello again...

I think i''m in a good path. But, speed is veeeeeeeery low. Turtle speed... I''ll try to fix this.

I would like to know how fast must it be. I mean, with a good radiosity renderer, what is the time for an average (from polygon count point of view) scene, with full shadows, and RGB lightmaps??

So far, my calculator can generate 44 RGB lightmaps, for 44 polygons, with all of them casting and recieving shadows, in about 20 min!!!!!!!!! Total patches in scene are 4760!! Lightmaps have variable width and height, depending on polygon''s width and height, with constant lumel density. The smallest lightmap is 2x2 and the largest is 40x16, with DensityX = 2.0f and DensityY = 2.0f. I thought some ways for speeding things up, like in depth backface culling, lumel in polygon test (for sources not for recievers) etc. I don''t know the improvements on speed, but i think they won''t do much!!

Any suggestions accepted. Except hemicubes, unless you suggest a way of rendering hemicube''s faces, without having to resize the window!!!!

Thanks again.

HellRaiZer

PS. Exposure function did a good job. I have a little problem with adjacent polygons that aren''t co-planar, but it isn''t easy to see it... You have to look closely to understand the difference. I think, by finding same position lumels in the scene, and averanging there color can be an improvement. But... i don''t have time for this!!!

PS2. Is there any way to upload a screenshot, so you can tell me your opinion???

HellRaiZer

### #5Yann L  Moderators   -  Reputation: 1754

Like
Likes
Like

Posted 20 April 2003 - 02:06 AM

Well, speed is very hard to compare with radiosity systems, as different approaches can greatly differ. Even if you don''t like it, hemicubes are a good way to speed up formfactor calculations. Other methods include progressive refinement (which greatly minimizes the number of shooting patches required). Adaptive patch subdivision is also very important for speed: start with few large patches, and subdivide them only if needed.

About that viewport rescaling: well, yes, if you want a lower resolution hemicube view, you''ll need to rescale the viewport (in OpenGL, for example, that''s a simple glViewport() command). But you don''t have to resize the window, where did you get that idea ?

quote:

PS2. Is there any way to upload a screenshot, so you can tell me your opinion???

You''ll need to upload it on your own webspace (or some free webspace provider), and link it here in the forums. GDNet does not offer direct image hosting, though.

### #6hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 20 April 2003 - 02:13 AM

I think i''ll go with hemicubes!!!!

Do you have anything detailed on hemicubes, to suggest??? I searched at Google.com and i didn''t found something like a tutorial. Only papers, with a lot bla bla...

HellRaiZer

### #7hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 20 April 2003 - 02:19 AM

And...

If you can''t tell something about the speed of a radiosity renderer, what about patch count??? I mean for real-life sized levels, what''s the averange patch count for an average scene???

Thanks again.

HellRaiZer

### #8Yann L  Moderators   -  Reputation: 1754

Like
Likes
Like

Posted 20 April 2003 - 03:40 AM

quote:

Do you have anything detailed on hemicubes, to suggest??? I searched at Google.com and i didn't found something like a tutorial. Only papers, with a lot bla bla...

Heh Have a look at Huge Elias' radiosity tutorial. There are few more links in the forum FAQ.

quote:

If you can't tell something about the speed of a radiosity renderer, what about patch count??? I mean for real-life sized levels, what's the averange patch count for an average scene???

Define 'average real-life scene'. I depends on the size, and especially on the resolution of your lightmaps. But as I mentioned before, if you want a speedy radiosity solver, you should use adaptive subdivision. You start with very few patches, and subdivide them as needed, during the radiosity process. That, combined with hemicubes and progressive refinement, will already yield significant performance improvements.

[edited by - Yann L on April 20, 2003 10:42:00 AM]

### #9hellraizer  Members   -  Reputation: 582

Like
Likes
Like

Posted 20 April 2003 - 07:14 AM

I'm trying to understand how patch subdivision works.
I read an article titled "Radiosity Methods" that refers to Hierarchical Radiosity, so i'm trying to prove it in action. The author suggests, if i understood right, using a quad tree for holding the patches of a polygon. So i started by calculating, using planar mapping, 4 initial patches for every polygon. But i have a problem with further subdivisions. What i mean is, for the 4 initial patches its easy to calculate positions in 3D space. But, how can i calculate new positions, for a patch's children?? I can't think of a way, i can do it, without recalculating patches from the beginning, for a specified polygon!!! And if i do that there is no need for adaptive subdivision!!!

Also, he suggests, a way refinement can be done. With a recursive way using this function:

void Refine(Patch *p, Patch *q, double Fe, double Ae)
{
double Fpq, Fqp;

Fpq = FormFactor(p, q);
Fqp = FormFactor(q, p);

if (Fpq < Fe && Fqp < Fe)
else {
if (Fpq > Fqp) {
if (Subdivide(q, Ae)) {
Refine(p, q->ne, Fe, Ae);
Refine(p, q->nw, Fe, Ae);
Refine(p, q->se, Fe, Ae);
Refine(p, q->sw, Fe, Ae);
} else {
if (Subdivide(p, Ae)) {
Refine(q, p->ne, Fe, Ae);
Refine(q, p->ne, Fe, Ae);
Refine(q, p->ne, Fe, Ae);
Refine(q, p->ne, Fe, Ae);
}
}
}

The problem is, what will the initial values must be?? Do i have to call Refine in a way like :

vector PatchList;

/* PatchList have been filled when generating initial Patches.*/
int numPatches = PatchList.size();
for(int i=0;i{
for(int j=i+1; j {
Refine(PatchList, PatchList[j],FormFactorEpsilon, AreaEpsilon);
}
}

and must i push_back() every new patch generated by Subdivide(), or the initial patches are enough???

So, resuming.

Problem 1) Any suggestions on Subdivide() function. How must it be??? My RadPatch struct is:

{
float Area; // Area of the patch
float Reflect; // Reflectivity
GEVector3D Pos; // 3D Position
RadPatch* Child[4]; // Children generated after subdivision
vector Interactions; // Patches visible from current patch
GETexCoord UV; // Lightmap coords of current patch. This is the problem with subdivision. How can i calculate childred UVs???
};

Problem 2) Calling Refine()!!!!! Initial values.

HellRaiZer

[edited by - HellRaiZer on April 20, 2003 2:17:47 PM]

[edited by - HellRaiZer on April 20, 2003 2:18:50 PM]

### #10shahinkey  Members   -  Reputation: 100

Like
Likes
Like

Posted 05 April 2012 - 05:34 AM

Dear All,
I really need to implement Radiosity. Who can help me for implementation. Is there any open source code radiosity? I read more paper about it. I know wat it is but I cannot implement it.
Thank you
Hoshang

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS