Hello,
I am working on a star map for use with night renderings, and it seems like it should be decomposed into two layers: one is a high-resolution imagemap showing the stars themselves, the other is a low-resolution "light map" that should be used to actually illuminate the scene.
The problem is that I want the "light map" layer to do the illumination, but I don't want it to be visible. I want the image map to appear in the sky in the final rendering.
I know that I can use maxrad=-1 in the image map glow source to prevent it from contributing to scene illumination, and maxrad=0 to allow the light map to illuminate. But mixfunc must be placed between the colorpict and the glow source, forcing me to either allow both to illuminate, or neither. But when the imagemap contributes to illumination, the result is very noisy (obviously).
This wouldn't be a problem if I could use two sky-dome sized glow sources in the same scene: "skyglow source skydome 0 0 4 0 0 1 360". But Radiance only sees the last one to be defined.
And I can't make the light map into an "illum" because it then gets treated as a point source at the zenith of my "source" description (ignoring the 180-degree size of the source disc).
Do I need to add transparency to the imagemap before making it into a rad=-1 glow source, so that when a ray is traced between the stars, it hits the illuminating light map rad=0 glow source? I am reluctant to include another circa-gigabyte imagemap to the scene just for that.
Am I missing something else or is this impossible?
Mark
PS. Shouldn't the file size limit for colorpict images be raised? I get a warning for using even a 134MB picture file. I intend to go much larger.
Hi Mark,
Is your high-res image an hdr? If so would it be worth looking into mksource to recover broad areas of the sky (clusters of star) as illum sources? Then your high res image can be mapped onto a glow source with the lighting provided by a set of illum sources (multiple ones with varying solid angles), derived from the hdr.
-Jack de Valpine
Mark Stock wrote:
···
Hello,
I am working on a star map for use with night renderings, and it seems like it should be decomposed into two layers: one is a high-resolution imagemap showing the stars themselves, the other is a low-resolution "light map" that should be used to actually illuminate the scene.
The problem is that I want the "light map" layer to do the illumination, but I don't want it to be visible. I want the image map to appear in the sky in the final rendering.
I know that I can use maxrad=-1 in the image map glow source to prevent it from contributing to scene illumination, and maxrad=0 to allow the light map to illuminate. But mixfunc must be placed between the colorpict and the glow source, forcing me to either allow both to illuminate, or neither. But when the imagemap contributes to illumination, the result is very noisy (obviously).
This wouldn't be a problem if I could use two sky-dome sized glow sources in the same scene: "skyglow source skydome 0 0 4 0 0 1 360". But Radiance only sees the last one to be defined.
And I can't make the light map into an "illum" because it then gets treated as a point source at the zenith of my "source" description (ignoring the 180-degree size of the source disc).
Do I need to add transparency to the imagemap before making it into a rad=-1 glow source, so that when a ray is traced between the stars, it hits the illuminating light map rad=0 glow source? I am reluctant to include another circa-gigabyte imagemap to the scene just for that.
Am I missing something else or is this impossible?
Mark
PS. Shouldn't the file size limit for colorpict images be raised? I get a warning for using even a 134MB picture file. I intend to go much larger.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Jack is right -- try mksource to see if that will work. Otherwise, you can try creating several smaller illum sources and scatter them around your sky, with the glow behind.
-Greg
···
From: Jack de Valpine <[email protected]>
Date: September 14, 2009 1:51:14 PM PDT
Hi Mark,
Is your high-res image an hdr? If so would it be worth looking into mksource to recover broad areas of the sky (clusters of star) as illum sources? Then your high res image can be mapped onto a glow source with the lighting provided by a set of illum sources (multiple ones with varying solid angles), derived from the hdr.
-Jack de Valpine
Would a 5 sided inverted illum box encompassing your whole scene work?
I'm not sure if chamfering the edges would help shadow testing or
anything of the sort. It probably depends on how "low" the resolution of
your light map can be and if it's important to get the angles of the
dome image map to match up with the angles of the box light map.
Anyone think of a downside to this?
...Otherwise, you can try creating several smaller illum sources and
scatter them around your sky, with the glow behind...
···
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
The star map that I have now is LDR, but I intend to create a new HDR version using the raw star data from Tycho-2. Unfortunately, there are stars everywhere, so I'd need illums to cover pretty much the whole hemisphere. Since that'll wind up being 50-200 of them, it will cost a lot in render-time, and add some complexity to the preprocessing. This is disappointing because a single glow source would have sufficed, and accomplished almost the same thing.
Do "illum" surfaces respond to "rpict -ds" ? I'll want smooth penumbras. If so, I can get by with fewer illums.
Mark
···
On Mon, 14 Sep 2009, Jack de Valpine wrote:
Hi Mark,
Is your high-res image an hdr? If so would it be worth looking into mksource to recover broad areas of the sky (clusters of star) as illum sources? Then your high res image can be mapped onto a glow source with the lighting provided by a set of illum sources (multiple ones with varying solid angles), derived from the hdr.
-Jack de Valpine
Mark Stock wrote:
Hello,
I am working on a star map for use with night renderings, and it seems like it should be decomposed into two layers: one is a high-resolution imagemap showing the stars themselves, the other is a low-resolution "light map" that should be used to actually illuminate the scene.
The problem is that I want the "light map" layer to do the illumination, but I don't want it to be visible. I want the image map to appear in the sky in the final rendering.
I know that I can use maxrad=-1 in the image map glow source to prevent it from contributing to scene illumination, and maxrad=0 to allow the light map to illuminate. But mixfunc must be placed between the colorpict and the glow source, forcing me to either allow both to illuminate, or neither. But when the imagemap contributes to illumination, the result is very noisy (obviously).
This wouldn't be a problem if I could use two sky-dome sized glow sources in the same scene: "skyglow source skydome 0 0 4 0 0 1 360". But Radiance only sees the last one to be defined.
And I can't make the light map into an "illum" because it then gets treated as a point source at the zenith of my "source" description (ignoring the 180-degree size of the source disc).
Do I need to add transparency to the imagemap before making it into a rad=-1 glow source, so that when a ray is traced between the stars, it hits the illuminating light map rad=0 glow source? I am reluctant to include another circa-gigabyte imagemap to the scene just for that.
Am I missing something else or is this impossible?
Mark
PS. Shouldn't the file size limit for colorpict images be raised? I get a warning for using even a 134MB picture file. I intend to go much larger.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Mark,
I have never looked into night skies, but from what I observed, they show little angular variance, as finally you have starts everywhere over the dome. Maybe I am ignoring something important here, but can't you assume a gradient for the illuminance to be totally fine to light your scene? I would assume that towards the horizon you get much higher levels due to "light pollution", but I cannot imagine that for the illumination of an object under the sky different "densities" of stars under different angles really show up.
By the way, do you know the paper on night sky modeling by Henrik Wann Jensen and others "A Physically-Based Night Sky Model"?
Cheers Lars.
Lars,
Yes, I have that paper. I aim to include the atmospheric horizon glow in another step (mixfunc with the stars), and not even include the stars when their influence is negligible. The illumination from the stars will also only be effective when there is no moon (or a new moon).
Mark
···
On Tue, 15 Sep 2009, Lars O. Grobe wrote:
Hi Mark,
I have never looked into night skies, but from what I observed, they show little angular variance, as finally you have starts everywhere over the dome. Maybe I am ignoring something important here, but can't you assume a gradient for the illuminance to be totally fine to light your scene? I would assume that towards the horizon you get much higher levels due to "light pollution", but I cannot imagine that for the illumination of an object under the sky different "densities" of stars under different angles really show up.
By the way, do you know the paper on night sky modeling by Henrik Wann Jensen and others "A Physically-Based Night Sky Model"?
Cheers Lars.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Mark,
There are a few ways to run mksource in order to control the number of sources produced. I believe that there is a switch for a radiance threshold as well as the diameter of the resulting sources. With these you should be able to control how the hdr is sampled and thus the resulting number of sources produced, so perhaps you could sample things in order to end up with just a handful of sources covering the hemisphere.... which would be similar to using a low res version of the image to "smear" the light distribution.
I believe source sampling is affected by -ds (this is an issue relating to the geometry primitive such as source, polygon, ring rather than the material type such as light, illum or glow). You will also probably need to set -dj to something useful and perhaps most importantly use -u for uncorrelated monte carlo. This last will require greater sampling (eg larger image) in order to reduce noise in image by downsampling. Not sure but you might have a sampling related problem anyway if you were able to find a solution with simple glow source hemisphere.
I am trying to thing if there is some interesting trick with mixfunc/mixpict that could be applied, but nothing comes to mind at the moment.
-Jack
Mark Stock wrote:
···
The star map that I have now is LDR, but I intend to create a new HDR version using the raw star data from Tycho-2. Unfortunately, there are stars everywhere, so I'd need illums to cover pretty much the whole hemisphere. Since that'll wind up being 50-200 of them, it will cost a lot in render-time, and add some complexity to the preprocessing. This is disappointing because a single glow source would have sufficed, and accomplished almost the same thing.
Do "illum" surfaces respond to "rpict -ds" ? I'll want smooth penumbras. If so, I can get by with fewer illums.
Mark
On Mon, 14 Sep 2009, Jack de Valpine wrote:
Hi Mark,
Is your high-res image an hdr? If so would it be worth looking into mksource to recover broad areas of the sky (clusters of star) as illum sources? Then your high res image can be mapped onto a glow source with the lighting provided by a set of illum sources (multiple ones with varying solid angles), derived from the hdr.
-Jack de Valpine
Mark Stock wrote:
Hello,
I am working on a star map for use with night renderings, and it seems like it should be decomposed into two layers: one is a high-resolution imagemap showing the stars themselves, the other is a low-resolution "light map" that should be used to actually illuminate the scene.
The problem is that I want the "light map" layer to do the illumination, but I don't want it to be visible. I want the image map to appear in the sky in the final rendering.
I know that I can use maxrad=-1 in the image map glow source to prevent it from contributing to scene illumination, and maxrad=0 to allow the light map to illuminate. But mixfunc must be placed between the colorpict and the glow source, forcing me to either allow both to illuminate, or neither. But when the imagemap contributes to illumination, the result is very noisy (obviously).
This wouldn't be a problem if I could use two sky-dome sized glow sources in the same scene: "skyglow source skydome 0 0 4 0 0 1 360". But Radiance only sees the last one to be defined.
And I can't make the light map into an "illum" because it then gets treated as a point source at the zenith of my "source" description (ignoring the 180-degree size of the source disc).
Do I need to add transparency to the imagemap before making it into a rad=-1 glow source, so that when a ray is traced between the stars, it hits the illuminating light map rad=0 glow source? I am reluctant to include another circa-gigabyte imagemap to the scene just for that.
Am I missing something else or is this impossible?
Mark
PS. Shouldn't the file size limit for colorpict images be raised? I get a warning for using even a 134MB picture file. I intend to go much larger.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
_______________________________________________
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
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Mark!
Yes, I have that paper. I aim to include the atmospheric horizon glow in another step (mixfunc with the stars), and not even include the stars when their influence is negligible. The illumination from the stars will also only be effective when there is no moon (or a new moon).
So would you expect any difference when using stars clustered into groups by mksource and just averaging all the stars contribution over the whole hemisphere?
One way would be to use mkillum on a facetted hemisphere. The resolution of this hemisphere could be adjusted (use gensurf) until you see no further improvements by increasing the resolution. I guess running mksource would create more or less the same result, as there will not be very concentrated regions on the night sky that mksource could optimize for. Maybe you would use the 145-patch sky dome for mkillum.
One other way you could go (please do not beat me for this Greg, I know that I tend to do funny things with Radiance 
) is to create such a simplified but correct sky dome, and using the photon map extension create a global photon map for your scene that will account for the ambient calculation (the one which gets noisy with the high-res image map). Then you replace the simplified sky dome by the one showing all detail, but keeping the old global pmap render our image. This should give a good result, as for the direct calculation having the high-res image map does not cause problems. To help distributing the photons in the first step, creating a big photon-port box around the area that will be visible in your image would be very helpful of course.
I am not sure whether it is possible to force radiance to reuse an ambient file without doing further refinement on it (ok, no it gets evil...). I would guess that you could do the trick I tried with the photon map by rendering the image first with the simplified glow sky, filling up your ambient file (without the noise that you would get from the high-res light probe). If you would re-use this ambient file in a second step with the high-res map, even if new values are written to it there should be much less noise, and in my understanding the result should still be correct. But - I have not tried it... 
Any comments on this?
Cheers,
Lars.
Hi again...
I am not sure whether it is possible to force radiance to reuse an ambient file without doing further refinement on it (...)
Thinking about this again... the fool-proof way would be to use the simplified map for a first rendering run, derive ambient values from it and use these as -av values with -ab 0 and the high-res map in later runs. This should give you very fast and noise-free results...
Cheers, Lars.
Hi mark, maybe this trick -->>
Create a sphere (bubble) with the imagemap mapped to it but as a mixfunc with half transparency but double intensity (to compensate transparency)
void glow glw 0 0 4 1 1 0 -1
void mixfunc pepe 4 void glw .5 picture.cal 0 0
pepe bubble ball 0 0 4 0 0 0 1000
Create a source whith the light map
void glow pop 0 0 4 0 1 1 0
pop source pipo 0 0 4 0 0 1 180
An element to see the result
void plastic white 0 0 5 .5 .6 .8 0 0
white sphere ball 0 0 4 5 5 5 1
A view with an aft plane to discard the light map in view but not in calculation
rpict -va 3000 -vp 0 0 0 -vd 0 1 1 -vh 110 -vv 110
Rpict command
rpict -vf vi.vf -ab 1 pi.oct>pi.hdr
I dont know if i've miss something...
regards, ignacio
Mark Stock escribió:
···
Hello,
I am working on a star map for use with night renderings, and it seems like it should be decomposed into two layers: one is a high-resolution imagemap showing the stars themselves, the other is a low-resolution "light map" that should be used to actually illuminate the scene.
The problem is that I want the "light map" layer to do the illumination, but I don't want it to be visible. I want the image map to appear in the sky in the final rendering.
I know that I can use maxrad=-1 in the image map glow source to prevent it from contributing to scene illumination, and maxrad=0 to allow the light map to illuminate. But mixfunc must be placed between the colorpict and the glow source, forcing me to either allow both to illuminate, or neither. But when the imagemap contributes to illumination, the result is very noisy (obviously).
This wouldn't be a problem if I could use two sky-dome sized glow sources in the same scene: "skyglow source skydome 0 0 4 0 0 1 360". But Radiance only sees the last one to be defined.
And I can't make the light map into an "illum" because it then gets treated as a point source at the zenith of my "source" description (ignoring the 180-degree size of the source disc).
Do I need to add transparency to the imagemap before making it into a rad=-1 glow source, so that when a ray is traced between the stars, it hits the illuminating light map rad=0 glow source? I am reluctant to include another circa-gigabyte imagemap to the scene just for that.
Am I missing something else or is this impossible?
Mark
PS. Shouldn't the file size limit for colorpict images be raised? I get a warning for using even a 134MB picture file. I intend to go much larger.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi,
Lars - why not use the relevant pixels from the first run in the final
image?
Model 1 - low res radiance map
Model 2 - uniform white sky
Model 3 - high res star map
rpict -ab 5 mod1.oct > pic1.hdr //high quality rendering
rpict -ab 0 mod2.oct > mask.hdr //image mask - black and white pixels
rpict -ab 0 mod3.oct > pic3.hdr //direct only rendering, starry sky
Use the mask to replace sky pixels with pixels of the starry sky:
pcomb -e 'Ro=if(Ri(2),Ri(3),Ri(1) etc...' \
pic1.hdr mask.hdr pic3.hdr > final.hdr
This was my initial thought when I saw Mark's query, but I thought an all
encompassing model (ala Jack's mksource suggestion) would probably fit
better. I'm not sure how practical three images and pcomb is with M. Stock
sized pre-filtered renderings. But given the complexity of the subsequent
responses, maybe a dumber solution is more practical?
Andy
···
On 9/15/09 7:11 PM, "Lars O. Grobe" <[email protected]> wrote:
Hi again...
I am not sure whether it is possible to force radiance to reuse an
ambient file without doing further refinement on it (...)
Thinking about this again... the fool-proof way would be to use the
simplified map for a first rendering run, derive ambient values from it
and use these as -av values with -ab 0 and the high-res map in later
runs. This should give you very fast and noise-free results...
Cheers, Lars.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
Hi Mark,
One additional thought that occurred to me this weekend. To simplify processing your star map through mksource (if this is the way you go), it might make sense to downsample (significantly) the super large hdr image and then sample it back up to some manageable size. This should smear out the values. Feeding this to mksource might then be easier.
-Jack
Andrew McNeil wrote:
···
Hi,
Lars - why not use the relevant pixels from the first run in the final
image?
Model 1 - low res radiance map
Model 2 - uniform white sky
Model 3 - high res star map
rpict -ab 5 mod1.oct > pic1.hdr //high quality rendering
rpict -ab 0 mod2.oct > mask.hdr //image mask - black and white pixels
rpict -ab 0 mod3.oct > pic3.hdr //direct only rendering, starry sky
Use the mask to replace sky pixels with pixels of the starry sky:
pcomb -e 'Ro=if(Ri(2),Ri(3),Ri(1) etc...' \
pic1.hdr mask.hdr pic3.hdr > final.hdr
This was my initial thought when I saw Mark's query, but I thought an all
encompassing model (ala Jack's mksource suggestion) would probably fit
better. I'm not sure how practical three images and pcomb is with M. Stock
sized pre-filtered renderings. But given the complexity of the subsequent
responses, maybe a dumber solution is more practical?
Andy
On 9/15/09 7:11 PM, "Lars O. Grobe" <[email protected]> wrote:
Hi again...
I am not sure whether it is possible to force radiance to reuse an
ambient file without doing further refinement on it (...)
Thinking about this again... the fool-proof way would be to use the
simplified map for a first rendering run, derive ambient values from it
and use these as -av values with -ab 0 and the high-res map in later
runs. This should give you very fast and noise-free results...
Cheers, Lars.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
____________________________________________________________
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
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
) is to create such a simplified but correct sky dome, and using the photon map extension create a global photon map for your scene that will account for the ambient calculation (the one which gets noisy with the high-res image map). Then you replace the simplified sky dome by the one showing all detail, but keeping the old global pmap render our image. This should give a good result, as for the direct calculation having the high-res image map does not cause problems. To help distributing the photons in the first step, creating a big photon-port box around the area that will be visible in your image would be very helpful of course.
Any comments on this?