I recently wrote a program for computing light sources to accelerate image-based lighting for anyone who's working on that. You can get it in last night's HEAD, and the synopsis is below:
NAME
mksource - compute distant sources for RADIANCE image-based lighting
SYNOPSIS
mksource [ -d nsamps ][ -t thresh ][ -a maxang ] [ octree ]
DESCRIPTION
Mksource produces a RADIANCE scene description of distant illum sources
corresponding to bright, concentrated regions in the given ambient
environment. Any local geometry is ignored in the input octree, which
should be derived from a captured light probe. The output sources may
then be combined with this environment to produce a more efficient
scene for rendering, faster and less prone to sampling artifacts.
···
--------
I'd be interested in feedback if you give this a try.
-Greg
Hi Greg and all,
I`ve tried mksource a bit and it works wonderfully, it`s a great program
(and just what I needed)
I put a page with the first sample renders:
http://home.att.ne.jp/banana/tiago/radiance/mksource.htm
rpict was only with -ab 1, and all the rest defaults since I just wanted to
test the sources
first I tried mksource with the default settings but it seemed to produce
too few sources, and the render looked unnatural
(don`t think this could be fixed with rpict settings)
I tried changing the max angle to 0.5 (-a .5) but that was too small, and
the render took too long (at least for my laptop)
so I tried other three values (5 deg, 2 and 1, after moving to a faster
computer) and the differences are visible. The render with -a 1 took about
15 hours, so I don`t want to imagine what would happen with -ab 3 -ad 5000
etc...
I guess it`s a compromise, and maybe making the threshold higher would
reduce the number of sources and allow a smaller -a?
I will keep trying other settings and let you know how it goes.
Regards
Santiago
···
-----Original Message-----
From: radiance-general-bounces@radiance-online.org
[mailto:radiance-general-bounces@radiance-online.org]On Behalf Of
Gregory J.Ward
Sent: Wednesday, April 13, 2005 3:39 AM
To: Radiance general discussion
Subject: [Radiance-general] mksource program
I recently wrote a program for computing light sources to accelerate
image-based lighting for anyone who's working on that. You can get it
in last night's HEAD, and the synopsis is below:
NAME
mksource - compute distant sources for RADIANCE image-based
lighting
SYNOPSIS
mksource [ -d nsamps ][ -t thresh ][ -a maxang ] [ octree ]
DESCRIPTION
Mksource produces a RADIANCE scene description of distant illum
sources
corresponding to bright, concentrated regions in the given
ambient
environment. Any local geometry is ignored in the input
octree, which
should be derived from a captured light probe. The output
sources may
then be combined with this environment to produce a more
efficient
scene for rendering, faster and less prone to sampling artifacts.
--------
I'd be interested in feedback if you give this a try.
-Greg
_______________________________________________
Radiance-general mailing list
Radiance-general@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Santiago,
Thanks for giving mksource a try -- and for sharing your results.
You might try adding "-dj .6 -ps 1" to your rpict options (or setting PENUMBRA=True if you're using rad) to see if that helps with a smaller number of light sources. If it still looks wonky, maybe I'll reduce the maximum source angle default.
-Greg
···
From: "Santiago Torres" <tiago@tkh.att.ne.jp>
Date: April 20, 2005 1:12:14 AM PDT
Hi Greg and all,
I`ve tried mksource a bit and it works wonderfully, it`s a great program
(and just what I needed)
I put a page with the first sample renders:
http://home.att.ne.jp/banana/tiago/radiance/mksource.htm
rpict was only with -ab 1, and all the rest defaults since I just wanted to
test the sources
first I tried mksource with the default settings but it seemed to produce
too few sources, and the render looked unnatural
(don`t think this could be fixed with rpict settings)
I tried changing the max angle to 0.5 (-a .5) but that was too small, and
the render took too long (at least for my laptop)
so I tried other three values (5 deg, 2 and 1, after moving to a faster
computer) and the differences are visible. The render with -a 1 took about
15 hours, so I don`t want to imagine what would happen with -ab 3 -ad 5000
etc...
I guess it`s a compromise, and maybe making the threshold higher would
reduce the number of sources and allow a smaller -a?
I will keep trying other settings and let you know how it goes.
Regards
Santiago
Okay,
II'll be the guy sitting in the corner with the cone hat
What should the octree consist of exactly?
I tried a rnl box - projected with angmap.cal
Made an octree and used it with mkillum.
But it produced no output.
probably because geometry is ignored...
I don't get how it can derive anything from a probe without geometry - the
probe image has to be projected onto something - right?
I can't make an octree directly of a probe pic - can I?
Rob "another question" Fitz
···
-----Original Message-----
From: Santiago Torres
To: Radiance general discussion
Sent: 4/20/2005 1:12 AM
Subject: RE: [Radiance-general] mksource program
Hi Greg and all,
I`ve tried mksource a bit and it works wonderfully, it`s a great program
(and just what I needed)
I put a page with the first sample renders:
http://home.att.ne.jp/banana/tiago/radiance/mksource.htm
rpict was only with -ab 1, and all the rest defaults since I just wanted
to
test the sources
first I tried mksource with the default settings but it seemed to
produce
too few sources, and the render looked unnatural
(don`t think this could be fixed with rpict settings)
I tried changing the max angle to 0.5 (-a .5) but that was too small,
and
the render took too long (at least for my laptop)
so I tried other three values (5 deg, 2 and 1, after moving to a faster
computer) and the differences are visible. The render with -a 1 took
about
15 hours, so I don`t want to imagine what would happen with -ab 3 -ad
5000
etc...
I guess it`s a compromise, and maybe making the threshold higher would
reduce the number of sources and allow a smaller -a?
I will keep trying other settings and let you know how it goes.
Regards
Santiago
-----Original Message-----
From: radiance-general-bounces@radiance-online.org
[mailto:radiance-general-bounces@radiance-online.org]On Behalf Of
Gregory J.Ward
Sent: Wednesday, April 13, 2005 3:39 AM
To: Radiance general discussion
Subject: [Radiance-general] mksource program
I recently wrote a program for computing light sources to accelerate
image-based lighting for anyone who's working on that. You can get it
in last night's HEAD, and the synopsis is below:
NAME
mksource - compute distant sources for RADIANCE image-based
lighting
SYNOPSIS
mksource [ -d nsamps ][ -t thresh ][ -a maxang ] [ octree ]
DESCRIPTION
Mksource produces a RADIANCE scene description of distant
illum
sources
corresponding to bright, concentrated regions in the given
ambient
environment. Any local geometry is ignored in the input
octree, which
should be derived from a captured light probe. The output
sources may
then be combined with this environment to produce a more
efficient
scene for rendering, faster and less prone to sampling
artifacts.
--------
I'd be interested in feedback if you give this a try.
-Greg
_______________________________________________
Radiance-general mailing list
Radiance-general@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing list
Radiance-general@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
Fitzsimmons, Rob wrote:
Okay,
II'll be the guy sitting in the corner with the cone hat
What should the octree consist of exactly?
I tried a rnl box - projected with angmap.cal
Made an octree and used it with mkillum.
But it produced no output.
probably because geometry is ignored...
I don't get how it can derive anything from a probe without geometry - the
probe image has to be projected onto something - right?
I can't make an octree directly of a probe pic - can I?
Rob "another question" Fitz
Below is what I've always used, taken from the example given by Paul
Debevec. I haven't used a light probe with mkillum yet. I had noticed that
I needed at least -ab 1 (really INDIRECT=1 in the .rif file) to make a
light probe work. I suppose using mkillum would allow the use of -ab 0
while still lighting up the scene?
···
---
void colorpict hdr_probe_image
7 red green blue uffizi_probe.hdr angmap.cal u
v
0
0
hdr_probe_image glow light_probe
0
0
4 1 1 1 0
light_probe source ibl_environment
0
0
4 0 1 0 360
Aha
I've been using the genbox method - also from Debevec.
Thanks
···
-----Original Message-----
From: Ian Tester
To: Radiance general discussion
Sent: 4/20/2005 12:05 PM
Subject: Re: [Radiance-general] mksource program
Fitzsimmons, Rob wrote:
Okay,
II'll be the guy sitting in the corner with the cone hat
What should the octree consist of exactly?
I tried a rnl box - projected with angmap.cal
Made an octree and used it with mkillum.
But it produced no output.
probably because geometry is ignored...
I don't get how it can derive anything from a probe without geometry
- the
probe image has to be projected onto something - right?
I can't make an octree directly of a probe pic - can I?
Rob "another question" Fitz
Below is what I've always used, taken from the example given by Paul
Debevec. I haven't used a light probe with mkillum yet. I had noticed
that
I needed at least -ab 1 (really INDIRECT=1 in the .rif file) to make a
light probe work. I suppose using mkillum would allow the use of -ab 0
while still lighting up the scene?
---
void colorpict hdr_probe_image
7 red green blue uffizi_probe.hdr angmap.cal
u
v
0
0
hdr_probe_image glow light_probe
0
0
4 1 1 1 0
light_probe source ibl_environment
0
0
4 0 1 0 360
_______________________________________________
Radiance-general mailing list
Radiance-general@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
Yeah, local light probe mappings don't work with mksource. I suppose you could get mkillum to work for these, but in general there is no real advantage to using local geometry for light probes, anyway.
-G
···
From: "Fitzsimmons, Rob" <Rob.Fitzsimmons@Summit.Fiserv.com>
Date: April 20, 2005 12:13:52 PM PDT
Aha
I've been using the genbox method - also from Debevec.
Thanks
hello again,
I updated the page with one more image (No. 5) with -dj .6 -ps 1
the page address is again:
http://home.att.ne.jp/banana/tiago/radiance/mksource.htm
It looks much better but probably could improve. what do you think?
I`ll keep trying and reporting. Any suggestions are of course very welcome.
regards,
Santiago
···
-----Original Message-----
From: radiance-general-bounces@radiance-online.org
[mailto:radiance-general-bounces@radiance-online.org]On Behalf Of
Gregory J.Ward
Sent: Thursday, April 21, 2005 2:05 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] mksource program
Hi Santiago,
Thanks for giving mksource a try -- and for sharing your results.
You might try adding "-dj .6 -ps 1" to your rpict options (or setting
PENUMBRA=True if you're using rad) to see if that helps with a smaller
number of light sources. If it still looks wonky, maybe I'll reduce
the maximum source angle default.
-Greg