Radiosity method implementation on Radiance

radiance-general
1

Dear everyone,

I am thinking on implementing a hybrid methodology between Radiosity method
and Ray-tracing, for accelerating some calculations (by giving up accuracy,
maybe)

As everyone here knows, Radiance ray-tracing works awesome; however, I
could not find anything related to any Radiosity implementation.

I think I can make algorythms to subdivide polygons into meshes, however,
what I do not know how to do is:

*1.- Calculation of View (Form) Factors:* I guess a straitforward way is to
calculate them by randomly sending rays from one surface to the rest of
them, but I do not know how to do that (or use octrees). (k/N would be the
view factor Fij... where k is the number of rays that falled into j from i,
and N the total number of rays sent)

*2.- Render:* After I have the Radiosities of every polygon. How can I make
a render? I guess I can use *vwrays *somehow, but I am not sure how to
check which polygon am I "seeing", in order to use the calculated values.

Any information is useful,

THANKS

German

PS: I know people here might like Ray-tracing more than anything else, but
still... This implementation might help

2

Hi German!

I am thinking on implementing a hybrid methodology between Radiosity
method and Ray-tracing, for accelerating some calculations (by giving up
accuracy, maybe)

Did you think about in what use cases radiosity may be faster, and in
which it wouldn't? And are you aware of the "hybrid" rendering approach
used by Radiance? Especially the way that the ambient cache is working
as a means to accelerate the stochastic diffuse-indirect calculation
that a radiosity renderer aims at?

I think I can make algorythms to subdivide polygons into meshes,
however, what I do not know how to do is:

I think most of this is already happening when you are using the ambient
cache.

*1.- Calculation of View (Form) Factors:* I guess a straitforward way is
to calculate them by randomly sending rays from one surface to the rest
of them, but I do not know how to do that (or use octrees). (k/N would
be the view factor Fij... where k is the number of rays that falled into
j from i, and N the total number of rays sent)

If you want to do this using scripts and the available tools, you could
step through all surfaces in a scene file. There are tools to do the
sampling available.

*2.- Render:* After I have the Radiosities of every polygon. How can I
make a render? I guess I can use *vwrays *somehow, but I am not sure how
to check which polygon am I "seeing", in order to use the calculated values.

You can tell rtrace to output object names instead of radiance or
irradiance values. You can also get both the name of the object and its
radiance. This would even allow to add the radiance value of a scene
with -ab 0 and the precalculated "radiosity" value. Somehow what most
radiosity renderers do to achieve sharp shadows (they add a
raytracing-step for direct calculation).

Still I have doubts that this can be faster than the current
implementation.... :slight_smile:

Cheers, Lars.

3

Thanks for the answers Lars!

I am thinking on "one-zone" simple scenes, without furniture. I was
checking out Lightsolve
<http://www.phil-seaton.com/#/lightsolve>algorithms, and for them,
this approach seem to be working well. I am
thinking on something similar, but not the same.

Also, a friend of mine did some work on lighting simulations, and claimed
that Radiosity was actually much faster than Radiance for those
calculations.

Anyway, lets see what others can say about this... I was aware of the
hybrid-stochastic-deterministic capabilities of Radiance, but I am not sure
what that exactly means, so I cannot say if this would be faster or not.

THANKS!

German

···

2013/6/21 Lars O. Grobe <[email protected]>

Hi German!

> I am thinking on implementing a hybrid methodology between Radiosity
> method and Ray-tracing, for accelerating some calculations (by giving up
> accuracy, maybe)

Did you think about in what use cases radiosity may be faster, and in
which it wouldn't? And are you aware of the "hybrid" rendering approach
used by Radiance? Especially the way that the ambient cache is working
as a means to accelerate the stochastic diffuse-indirect calculation
that a radiosity renderer aims at?

> I think I can make algorythms to subdivide polygons into meshes,
> however, what I do not know how to do is:

I think most of this is already happening when you are using the ambient
cache.

> *1.- Calculation of View (Form) Factors:* I guess a straitforward way is
> to calculate them by randomly sending rays from one surface to the rest
> of them, but I do not know how to do that (or use octrees). (k/N would
> be the view factor Fij... where k is the number of rays that falled into
> j from i, and N the total number of rays sent)

If you want to do this using scripts and the available tools, you could
step through all surfaces in a scene file. There are tools to do the
sampling available.

> *2.- Render:* After I have the Radiosities of every polygon. How can I
> make a render? I guess I can use *vwrays *somehow, but I am not sure how
> to check which polygon am I "seeing", in order to use the calculated
values.

You can tell rtrace to output object names instead of radiance or
irradiance values. You can also get both the name of the object and its
radiance. This would even allow to add the radiance value of a scene
with -ab 0 and the precalculated "radiosity" value. Somehow what most
radiosity renderers do to achieve sharp shadows (they add a
raytracing-step for direct calculation).

Still I have doubts that this can be faster than the current
implementation.... :slight_smile:

Cheers, Lars.

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

4

As I've noted when asked this question in the past, radiosity is faster for simple spaces with many interior reflections. Complex spaces quickly become expensive to compute, and the meshing of them can be a nightmare.

If you need to compute the illumination of an empty box, then anything is going to be fast. If it's really, really important for you to compute empty boxes in a second or two, then radiosity is the way to go. If you can wait 30 seconds, Radiance works, too.

If you have a complex building to render with trees and sky, have fun doing it with radiosity!

Cheers,
-Greg

···

From: Germán Molina Larrain <[email protected]>
Date: June 21, 2013 8:42:14 AM PDT

Thanks for the answers Lars!

I am thinking on "one-zone" simple scenes, without furniture. I was checking out Lightsolve algorithms, and for them, this approach seem to be working well. I am thinking on something similar, but not the same.

Also, a friend of mine did some work on lighting simulations, and claimed that Radiosity was actually much faster than Radiance for those calculations.

Anyway, lets see what others can say about this... I was aware of the hybrid-stochastic-deterministic capabilities of Radiance, but I am not sure what that exactly means, so I cannot say if this would be faster or not.

THANKS!

German

2013/6/21 Lars O. Grobe <[email protected]>
Hi German!

> I am thinking on implementing a hybrid methodology between Radiosity
> method and Ray-tracing, for accelerating some calculations (by giving up
> accuracy, maybe)

Did you think about in what use cases radiosity may be faster, and in
which it wouldn't? And are you aware of the "hybrid" rendering approach
used by Radiance? Especially the way that the ambient cache is working
as a means to accelerate the stochastic diffuse-indirect calculation
that a radiosity renderer aims at?

> I think I can make algorythms to subdivide polygons into meshes,
> however, what I do not know how to do is:

I think most of this is already happening when you are using the ambient
cache.

> *1.- Calculation of View (Form) Factors:* I guess a straitforward way is
> to calculate them by randomly sending rays from one surface to the rest
> of them, but I do not know how to do that (or use octrees). (k/N would
> be the view factor Fij... where k is the number of rays that falled into
> j from i, and N the total number of rays sent)

If you want to do this using scripts and the available tools, you could
step through all surfaces in a scene file. There are tools to do the
sampling available.

> *2.- Render:* After I have the Radiosities of every polygon. How can I
> make a render? I guess I can use *vwrays *somehow, but I am not sure how
> to check which polygon am I "seeing", in order to use the calculated values.

You can tell rtrace to output object names instead of radiance or
irradiance values. You can also get both the name of the object and its
radiance. This would even allow to add the radiance value of a scene
with -ab 0 and the precalculated "radiosity" value. Somehow what most
radiosity renderers do to achieve sharp shadows (they add a
raytracing-step for direct calculation).

Still I have doubts that this can be faster than the current
implementation.... :slight_smile:

Cheers, Lars.

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

5

Germán, are you looking for a way to quickly estimate light levels for luminaire layout?

Randolph

···

On 2013-06-18 14:10:55 +0000, Germán Molina Larrain said:

I am thinking on implementing a hybrid methodology between Radiosity method and Ray-tracing, for accelerating some calculations (by giving up accuracy, maybe)

6

Ok, I will have all that in mind!

I cannot give so many details now, but our idea is to get fast solutions
(trying to achieve interactivity) for design of interior spaces.

THANKS EVERYONE

German

···

2013/6/21 Greg Ward <[email protected]>

As I've noted when asked this question in the past, radiosity is faster
for simple spaces with many interior reflections. Complex spaces quickly
become expensive to compute, and the meshing of them can be a nightmare.

If you need to compute the illumination of an empty box, then anything is
going to be fast. If it's really, really important for you to compute
empty boxes in a second or two, then radiosity is the way to go. If you
can wait 30 seconds, Radiance works, too.

If you have a complex building to render with trees and sky, have fun
doing it with radiosity!

Cheers,
-Greg

*From: *Germán Molina Larrain <[email protected]>

*Date: *June 21, 2013 8:42:14 AM PDT

*
*

Thanks for the answers Lars!

I am thinking on "one-zone" simple scenes, without furniture. I was
checking out Lightsolve <http://www.phil-seaton.com/#/lightsolve>algorithms, and for them, this approach seem to be working well. I am
thinking on something similar, but not the same.

Also, a friend of mine did some work on lighting simulations, and claimed
that Radiosity was actually much faster than Radiance for those
calculations.

Anyway, lets see what others can say about this... I was aware of the
hybrid-stochastic-deterministic capabilities of Radiance, but I am not sure
what that exactly means, so I cannot say if this would be faster or not.

THANKS!

German

2013/6/21 Lars O. Grobe <[email protected]>

Hi German!

> I am thinking on implementing a hybrid methodology between Radiosity
> method and Ray-tracing, for accelerating some calculations (by giving up
> accuracy, maybe)

Did you think about in what use cases radiosity may be faster, and in
which it wouldn't? And are you aware of the "hybrid" rendering approach
used by Radiance? Especially the way that the ambient cache is working
as a means to accelerate the stochastic diffuse-indirect calculation
that a radiosity renderer aims at?

> I think I can make algorythms to subdivide polygons into meshes,
> however, what I do not know how to do is:

I think most of this is already happening when you are using the ambient
cache.

> *1.- Calculation of View (Form) Factors:* I guess a straitforward way is
> to calculate them by randomly sending rays from one surface to the rest
> of them, but I do not know how to do that (or use octrees). (k/N would
> be the view factor Fij... where k is the number of rays that falled into
> j from i, and N the total number of rays sent)

If you want to do this using scripts and the available tools, you could
step through all surfaces in a scene file. There are tools to do the
sampling available.

> *2.- Render:* After I have the Radiosities of every polygon. How can I
> make a render? I guess I can use *vwrays *somehow, but I am not sure how
> to check which polygon am I "seeing", in order to use the calculated
values.

You can tell rtrace to output object names instead of radiance or
irradiance values. You can also get both the name of the object and its
radiance. This would even allow to add the radiance value of a scene
with -ab 0 and the precalculated "radiosity" value. Somehow what most
radiosity renderers do to achieve sharp shadows (they add a
raytracing-step for direct calculation).

Still I have doubts that this can be faster than the current
implementation.... :slight_smile:

Cheers, Lars.

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

7

Is the intention to check if speed improvements are possible? It could be a lot of work for potentially little gain. Maybe there are already validation/benchmark studies that could show it takes X minutes to get within 10% of a known solution with radiosity and Y minutes to get within 10% of the same solution with Radiance.

Or maybe radiosity is perceived to be faster, but you have a scenario that your favorite radiosity software doesn't handle well? Maybe Radiance only handles the scenario of interest well because it doesn't use radiosity.

I suppose since Radiance is open source, there is a potential path toward implementing radiosity into Radiance - whereas most radiosity software (AGI, Dialux, etc.) would not accommodate a homespun version implementing a Perez sky for example or outputting an HDR image for use in evalglare.

Keep in mind that adapting Radiance to a radiosity method probably requires to ignore (or otherwise account for) the specular reflection component defined as part of any material type. In many scenes this may be unimportant.

···

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

8

Hi Germán,

aeons ago I hacked up a primitive radiosity thingy for RADIANCE in an afternoon to compare with our measurements for validation of diffuse interreflection. It's actually embedded in the rendering engine and may not compile with the current release anymore, but it might be worth looking at to give you some ideas on how (not?) to do it. As I recall, it used a standard relaxation method and a fixed quadrilateral mesh, so nothing fancy.

Let me know if you're interested and I'll excavate that ancient artifact.

Regards,

--Roland

···

--
"END OF LINE" [MCP, 1982]

On 21/06/2013, at 2:57 PM, "Lars O. Grobe" <[email protected]> wrote:

Hi German!

I am thinking on implementing a hybrid methodology between Radiosity
method and Ray-tracing, for accelerating some calculations (by giving up
accuracy, maybe)

Did you think about in what use cases radiosity may be faster, and in
which it wouldn't? And are you aware of the "hybrid" rendering approach
used by Radiance? Especially the way that the ambient cache is working
as a means to accelerate the stochastic diffuse-indirect calculation
that a radiosity renderer aims at?

I think I can make algorythms to subdivide polygons into meshes,
however, what I do not know how to do is:

I think most of this is already happening when you are using the ambi
cache.

*1.- Calculation of View (Form) Factors:* I guess a straitforward way is
to calculate them by randomly sending rays from one surface to the rest
of them, but I do not know how to do that (or use octrees). (k/N would
be the view factor Fij... where k is the number of rays that falled into
j from i, and N the total number of rays sent)

If you want to do this using scripts and the available tools, you could
step through all surfaces in a scene file. There are tools to do the
sampling available.

*2.- Render:* After I have the Radiosities of every polygon. How can I
make a render? I guess I can use *vwrays *somehow, but I am not sure how
to check which polygon am I "seeing", in order to use the calculated values.

You can tell rtrace to output object names instead of radiance or
irradiance values. You can also get both the name of the object and its
radiance. This would even allow to add the radiance value of a scene
with -ab 0 and the precalculated "radiosity" value. Somehow what most
radiosity renderers do to achieve sharp shadows (they add a
raytracing-step for direct calculation).

Still I have doubts that this can be faster than the current
implementation.... :slight_smile:

Cheers, Lars.

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

9

Randolph,

No, that is not my plan... I actually do not know much about artificial
lighting, hahaha.

Christopher,

I have some ideas that I would like to evaluate both in accuracy and speed.
Is not that any other software does not handle well what I am trying to do,
but as you said, I need some procedures and programs that exist in
Radiance, such as evalglare and the Perez model... sacrificing the
specularity is what I meant by "giving up some accuracy".

The advantage that I see on Radiosity+ray-tracing is that the ambient
calculations can be done with radiosity, and the direct calculations can be
done with ray-tracing. By doing that, the ray-tracing parameters are
relaxed, and fast to compute.

When everything is done, it is possible to move and render images fast,
using the precalculated values. This might be important to choose where to
locate furniture, for example.

I am going to stick to what Greg said for now:

*"If you need to compute the illumination of an empty box, then anything is
going to be fast. If it's really, really important for you to compute
empty boxes in a second or two, then radiosity is the way to go. If you
can wait 30 seconds, Radiance works, too."*

···

*
*
If I have time in the future, I will try to test my ideas... whether they
do their job well or not, would you, guys, be interested on having some
radiosity modules here for research purposes?

THANKS FOR COMMENTING ALL OF YOU!

German

2013/6/21 Christopher Rush <[email protected]>

Is the intention to check if speed improvements are possible? It could be
a lot of work for potentially little gain. Maybe there are already
validation/benchmark studies that could show it takes X minutes to get
within 10% of a known solution with radiosity and Y minutes to get within
10% of the same solution with Radiance.

Or maybe radiosity is perceived to be faster, but you have a scenario that
your favorite radiosity software doesn't handle well? Maybe Radiance only
handles the scenario of interest well because it doesn't use radiosity.

I suppose since Radiance is open source, there is a potential path toward
implementing radiosity into Radiance - whereas most radiosity software
(AGI, Dialux, etc.) would not accommodate a homespun version implementing a
Perez sky for example or outputting an HDR image for use in evalglare.

Keep in mind that adapting Radiance to a radiosity method probably
requires to ignore (or otherwise account for) the specular reflection
component defined as part of any material type. In many scenes this may be
unimportant.
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

10

Hi Roland,

Thanks for the offering! Maybe in the (near, I hope) future I will ask you
for that! for now, I am working in some other stuff.

THANKS!

German

···

2013/6/21 Roland Schregle <[email protected]>

Hi Germán,

aeons ago I hacked up a primitive radiosity thingy for RADIANCE in an
afternoon to compare with our measurements for validation of diffuse
interreflection. It's actually embedded in the rendering engine and may not
compile with the current release anymore, but it might be worth looking at
to give you some ideas on how (not?) to do it. As I recall, it used a
standard relaxation method and a fixed quadrilateral mesh, so nothing fancy.

Let me know if you're interested and I'll excavate that ancient artifact.

Regards,

--Roland

--
"END OF LINE" [MCP, 1982]

On 21/06/2013, at 2:57 PM, "Lars O. Grobe" <[email protected]> wrote:

> Hi German!
>
>> I am thinking on implementing a hybrid methodology between Radiosity
>> method and Ray-tracing, for accelerating some calculations (by giving up
>> accuracy, maybe)
>
> Did you think about in what use cases radiosity may be faster, and in
> which it wouldn't? And are you aware of the "hybrid" rendering approach
> used by Radiance? Especially the way that the ambient cache is working
> as a means to accelerate the stochastic diffuse-indirect calculation
> that a radiosity renderer aims at?
>
>> I think I can make algorythms to subdivide polygons into meshes,
>> however, what I do not know how to do is:
>
> I think most of this is already happening when you are using the ambi
> cache.
>
>> *1.- Calculation of View (Form) Factors:* I guess a straitforward way is
>> to calculate them by randomly sending rays from one surface to the rest
>> of them, but I do not know how to do that (or use octrees). (k/N would
>> be the view factor Fij... where k is the number of rays that falled into
>> j from i, and N the total number of rays sent)
>
> If you want to do this using scripts and the available tools, you could
> step through all surfaces in a scene file. There are tools to do the
> sampling available.
>
>> *2.- Render:* After I have the Radiosities of every polygon. How can I
>> make a render? I guess I can use *vwrays *somehow, but I am not sure how
>> to check which polygon am I "seeing", in order to use the calculated
values.
>
> You can tell rtrace to output object names instead of radiance or
> irradiance values. You can also get both the name of the object and its
> radiance. This would even allow to add the radiance value of a scene
> with -ab 0 and the precalculated "radiosity" value. Somehow what most
> radiosity renderers do to achieve sharp shadows (they add a
> raytracing-step for direct calculation).
>
> Still I have doubts that this can be faster than the current
> implementation.... :slight_smile:
>
> Cheers, Lars.
>
> _______________________________________________
> Radiance-general mailing list
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general