 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I'd like to use POV-Ray to evaluate light positioning and reflector design, and
thus would like to be able to map relative light intensities on a flat surface.
How might this be accomplished?
Thanks,
Colin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Colin" <nomail@nomail> wrote:
> I'd like to use POV-Ray to evaluate light positioning and reflector design, and
> thus would like to be able to map relative light intensities on a flat surface.
> How might this be accomplished?
I'm not quite sure whether I understand what you mean.
What comes to my mind is designing a car headlight, and an attempt to simulate
the pattern of light (a) created on a wall at a distance of whatsoever meters,
and/or (b) the pattern of light created on the road.
Does this come close to what you intend to do?
If that is what you're doing, I guess you're looking for is...
(1) PoV-ray's "ortographic camera", which allows you to render any surface
without perspective distortion;
(2) PoV-ray's "photon mapping" feature, which does forward raytracing (i.e.
shooting light rays from a light source) and is specially designed to simulate
lighting effects involving light being reflecting and/or refracted
("caustics").
Note that the so-called "fake caustics" will probably not get you anywhere for
your purpose.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "Colin" <nomail@nomail> wrote:
> > I'd like to use POV-Ray to evaluate light positioning and reflector design, and
> > thus would like to be able to map relative light intensities on a flat surface.
> > How might this be accomplished?
>
> I'm not quite sure whether I understand what you mean.
>
> What comes to my mind is designing a car headlight, and an attempt to simulate
> the pattern of light (a) created on a wall at a distance of whatsoever meters,
> and/or (b) the pattern of light created on the road.
>
> Does this come close to what you intend to do?
>
>
> If that is what you're doing, I guess you're looking for is...
>
> (1) PoV-ray's "ortographic camera", which allows you to render any surface
> without perspective distortion;
>
> (2) PoV-ray's "photon mapping" feature, which does forward raytracing (i.e.
> shooting light rays from a light source) and is specially designed to simulate
> lighting effects involving light being reflecting and/or refracted
> ("caustics").
So what I'm looking for is if you were tracing photons, how many per unit area
strikes a particular position on a surface. We usually measure this in things
like W/m2 or lux (lumens/m2).
So, say for example I put a point
light source above a flat surface. If I render it, I see that it's brightest
directly below the source. At a point some distance away from this centerline,
it is dimmer. What I would like is a metric for how much dimmer it is, as a
function of position. I assume this would be trivial from within the
ray-tracing algorithm; I'm just curious if it's possible from the user end.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote in message
news:web.494964e567084438abad780@news.povray.org...
> (2) PoV-ray's "photon mapping" feature, which does forward raytracing
> (i.e.
> shooting light rays from a light source) and is specially designed to
> simulate
> lighting effects involving light being reflecting and/or refracted
> ("caustics").
You should also have a look at the example scenes that came with the
distribution.
Your application install directory may vary ..... ~scenes/interior
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Colin wrote:
> So, say for example I put a point
> light source above a flat surface. If I render it, I see that it's brightest
> directly below the source. At a point some distance away from this centerline,
> it is dimmer. What I would like is a metric for how much dimmer it is, as a
> function of position. I assume this would be trivial from within the
> ray-tracing algorithm; I'm just curious if it's possible from the user end.
I think the only way from the user end is to go via the brightness.
You can position an orthographic camera to look top down on the
plane you are interested in. Using a homogenous texture and suitable
light intensity should yield a reasonable intensity image.
You need to make sure that the surface is lighted by photons only.
This should be the case if the light source is completely blocked
by some transparent object which is a photon target.
You will wish to adapt the gamma settings to get a linear
response curve, use 16-bit output for higher precision, and
possibly try HDR output (this is in MegaPOV, there is also
HDR support in 3.7b but I'm not sure its also for output?)
This should already give you the relative intensities.
Converting the pixel intensity to a physical unit may be
tricky. For reference, you'd probably need some test lens
which directs all photons onto the visible area.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Colin" <nomail@nomail> wrote:
> So what I'm looking for is if you were tracing photons, how many per unit area
> strikes a particular position on a surface. We usually measure this in things
> like W/m2 or lux (lumens/m2).
That's basically what an orthographic shot of the surface with photon mapping
will give you: A bitmap specifying how many photons have hit which point.
If you crank up the number of photons high enough, you can probably get any
precision you may need.
(At least if you make sure that gamma correction is turned off, and your light
brightness has a proper brightness to represented by the output image format
you choose.)
To my knowledge, the principle behind this is extremely simple: PoV will shoot
photons, remember where they hit, and increase the brightness of the object
accordingly.
The only problematic thing with this might be if the light source itself is
directly visible from your "test surface", as you want to eliminate the (most
likely not really exact) conventional lighting. I don't know by heart whether
you can turn off conventional lighting completely and just use photon mapping.
A more brute-force attempt would be to do the same thing with radiosity, which
basically does the very same thing "backwards" and should lead to the same
results given extremely high-quality settings), but is probably a waste of
computing power for this application.
If it cannot be helped otherwise, it would always be possible to do something
with the trace() function, but something built-in will most likely be a lot
faster.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> wrote:
> You will wish to adapt the gamma settings to get a linear
> response curve, use 16-bit output for higher precision, and
> possibly try HDR output (this is in MegaPOV, there is also
> HDR support in 3.7b but I'm not sure its also for output?)
HDR is supported in 3.7 beta (29) for both in- and output. I tested.
I had the impression that it behaves differently than MegaPov regarding gamma,
but that might be due to the general gamma handling change (or due to fixes - I
think the MegaPOV HDR implementation is buggy in this respect). I didn't
investigate any further, because the beta also lacks other things I needed from
MegaPOV.
(I think photon mapping is already multi-threaded and stable in the beta, and
should be a good deal faster on modern hardware, so in this case I'd recommend
it over MegaPOV.)
HDR will definitely be a good choice with this - better even than 16-bit output
I guess, as it can not only capture very subtle differences in dim areas, but
is also very robust against "overexposure".
The precision of HDR, by the way, is still limited though, especially when
dealing with colors; its resolution regarding hue and saturation of a color are
just the same as a classic 8-bit-per-color format; its high dynamic range is
only achieved by adding an 8-bit exponent to scale the total brightness of a
pixel.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Colin wrote:
>
> > So, say for example I put a point
> > light source above a flat surface. If I render it, I see that it's brightest
> > directly below the source. At a point some distance away from this centerline,
> > it is dimmer. What I would like is a metric for how much dimmer it is, as a
> > function of position. I assume this would be trivial from within the
> > ray-tracing algorithm; I'm just curious if it's possible from the user end.
>
> I think the only way from the user end is to go via the brightness.
>
> You can position an orthographic camera to look top down on the
> plane you are interested in. Using a homogenous texture and suitable
> light intensity should yield a reasonable intensity image.
>
> You need to make sure that the surface is lighted by photons only.
> This should be the case if the light source is completely blocked
> by some transparent object which is a photon target.
>
> You will wish to adapt the gamma settings to get a linear
> response curve, use 16-bit output for higher precision, and
> possibly try HDR output (this is in MegaPOV, there is also
> HDR support in 3.7b but I'm not sure its also for output?)
>
> This should already give you the relative intensities.
> Converting the pixel intensity to a physical unit may be
> tricky. For reference, you'd probably need some test lens
> which directs all photons onto the visible area.
I can work on referencing it easily using a known light source and photodiode
and calibrate accordingly (in the "real" world).
How do I read the brightness into a matrix of integer values corresponding to
the pixel locations?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Colin" <nomail@nomail> wrote:
> How do I read the brightness into a matrix of integer values corresponding to
> the pixel locations?
Ah, so having the values in a bitmap image doesn't help you, and you actually
need them as a 2-dimensional array instead?
Hm...
(a) Get POV-ray to render an orthographic image anyway. Use a second POV-ray
"render" to load that image as a pigment bitmap, use this pigment as a pigment
function, and voila - there you have that function you need. You can decide
yourself whether you want to make an array of it, or just use that function to
get the values at specific locations.
(b) This one gets a bit trickier: Build your own "photon tracer" from building
blocks provided by POV-ray. Do as follows:
- #declare a union of your reflector object and a plane where you want to
measure light intensity
- #declare a 2-dimensional array to count your photons
- think of an algorithm that gives you a (very large) series of
evenly-distributed directions to shoot photons from the light source (random
directions generated with vrand_on_sphere might do, but less noisy approaches
might yield more accurate results with less photons to shoot)
- loop through this series of diection, shooting a photon for each direction as
follows:
- remember the light source posotion and photon direction as the "current
location" and "current direction"
- repeat the following until... um, well, until you're done with this photon:
- call trace() with the current location & direction and your reflector/plane
union; this will trace a ray from the current location in the current direction
and get the nearest intersection point with the reflector or plane, plus the
surface normal at that point.
- if you do not get any intersection point, you're done.
- otherwise, if that intersection point is on your "measuring plane", compute
the array co-ordinates from the intersection point, and count up the
corresponding array entry. As you won't get exact hits, you may want to kind of
assign "fractions of a photon" to the nearest four array entries. You're done
for this photon.
- otherwise (i.e. if you do get an intersection point but it's not on the
measuring plane), take the intersection point as you new current location, and
mirror the current direction according to the surface normal you got from
trace(). (You may also want to reduce the photon "weight" depending on
reflector material). Note that you're *not* done in this case.
- make sure you add some iteration limit to this loop, or you may get stuck in
an endless one.
- When you're done with a photon, proceed with the next direction from your
series, starting at the light source again.
- When you're done with all directions, evaluate your results.
You may also want to count "lost" photons that escape your setup without hitting
the measurement plane, and "stuck" photons that never seem to make it out of the
reflector.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Colin nous illumina en ce 2008-12-17 20:20 -->
> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> Colin wrote:
>>
>>> So, say for example I put a point
>>> light source above a flat surface. If I render it, I see that it's brightest
>>> directly below the source. At a point some distance away from this centerline,
>>> it is dimmer. What I would like is a metric for how much dimmer it is, as a
>>> function of position. I assume this would be trivial from within the
>>> ray-tracing algorithm; I'm just curious if it's possible from the user end.
>> I think the only way from the user end is to go via the brightness.
>>
>> You can position an orthographic camera to look top down on the
>> plane you are interested in. Using a homogenous texture and suitable
>> light intensity should yield a reasonable intensity image.
>>
>> You need to make sure that the surface is lighted by photons only.
>> This should be the case if the light source is completely blocked
>> by some transparent object which is a photon target.
>>
>> You will wish to adapt the gamma settings to get a linear
>> response curve, use 16-bit output for higher precision, and
>> possibly try HDR output (this is in MegaPOV, there is also
>> HDR support in 3.7b but I'm not sure its also for output?)
>>
>> This should already give you the relative intensities.
>> Converting the pixel intensity to a physical unit may be
>> tricky. For reference, you'd probably need some test lens
>> which directs all photons onto the visible area.
>
> I can work on referencing it easily using a known light source and photodiode
> and calibrate accordingly (in the "real" world).
>
> How do I read the brightness into a matrix of integer values corresponding to
> the pixel locations?
>
>
>
How about using the image itself as the matrix? After all, any digital image is
in fact a matrix of values displayed as an image.
If you output as TGA, you get minimal overhead and can have up to 16 bit per
channel par pixel.
--
Alain
-------------------------------------------------
To compel a man to furnish funds for the propagation of ideas he disbelieves
and abhors is sinful and tyrannical.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
