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

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: [email protected]
[mailto:[email protected]]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
[email protected]
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" <[email protected]>
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: [email protected]
[mailto:[email protected]]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
[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

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
[email protected]
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" <[email protected]>
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: [email protected]
[mailto:[email protected]]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