 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Recently I looked at old IRTC files - again.
One of my old favorites is "Verres1" made by Herve Martin back in 1997 for the
"Glass" IRTC round http://oz.irtc.org/ftp/pub/stills/1997-02-28/verres1.jpg .
I translated the given source from Luxart 2.0 to Pov-Ray 3.7, which wasn't that
difficult.
But when adding photons, I got a far from perfect image.
Since the settings generate a 16 GB photon file, reducing spacing isn't an
option.
Is there a way to get rid of the blotchy artifacts?
I included the source -
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5d8ba2e7aa028214839d843b0%40news.povray.org%3E/
Regards,
Norbert Kern
Post a reply to this message
Attachments:
Download 'verres1_.jpg' (753 KB)
Preview of image 'verres1_.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/25/19 1:38 PM, Norbert Kern wrote:
> Recently I looked at old IRTC files - again.
>
> One of my old favorites is "Verres1" made by Herve Martin back in 1997 for the
> "Glass" IRTC round http://oz.irtc.org/ftp/pub/stills/1997-02-28/verres1.jpg .
>
> I translated the given source from Luxart 2.0 to Pov-Ray 3.7, which wasn't that
> difficult.
> But when adding photons, I got a far from perfect image.
>
> Since the settings generate a 16 GB photon file, reducing spacing isn't an
> option.
> Is there a way to get rid of the blotchy artifacts?
>
> I included the source -
>
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5d8ba2e7aa028214839d843b0%40news.povray.org%3E/
>
> Regards,
> Norbert Kern
>
I'll not be able to reasonably play with this scene on my little
machine, but...
1) If you ran v3.7-stable, there are some photon fixes in the current
v3.8 master branch.
2) There are dozens of solver related fixes in my v3.8 master based
branch at:
https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy
which likely help some - but you'll need to build a custom version.
Secondary rays are more sensitive to solver accuracy issues. Your light
sources are relatively close to the objects so you are probably not
seeing the worst issues discussed at some length toward the bottom of
github issue:
https://github.com/POV-Ray/povray/pull/358
and exposed by shooting photons from afar.
3) I see polygon objects in the puz2 union. These won't have a well
defined inside / interior. I'm unsure what happens when an interior is
later defined for a collection of shapes including those. Maybe as a
union and not a merge it can kinda work? The sor objects are also open
so though those have defined interiors possible in some cases where
photon rays see the tops or bottoms photon directions won't quite be
right. Doubt this the reason for graininess though.
4) The size of some of the shapes in puz2 especially a bit small so
might be seeing some lost intersections. Scale scene up - a little (not
too much - see (2) pull #358 comments for why) ?
5) I've seen odd results where the light intensities are >1 with
photons, but never had time to run down what is going on - suspect maybe
the gather mechanism making bad choices / bad radius choices, but
guessing. You've got this >1 intensity set up, but no idea if your
tripping the same issue(s).
Otherwise, not sure. If you do play with any of the options above beware
it might be you end up suddenly with many more photons deposited at your
current spacing.
Aside: I've never played much with stored photon files. How many
deposited photons do you have with/in that 16GB photon file?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/25/19 3:24 PM, William F Pokorny wrote:
> On 9/25/19 1:38 PM, Norbert Kern wrote:
...
>>
...
>
> Otherwise, not sure. If you do play with any of the options above beware
> it might be you end up suddenly with many more photons deposited at your
> current spacing.
...
>
As the day passed a few other thoughts popped into my head.
a) Might be worth it to try "split_union off" in all your unions. It
sometimes makes for a significant difference though I find it hard
myself to align results and the documented behavior.
b) You are using spotlights so might be worth checking they are lined up
well on things you expect to "focus/disperse" light. If your photons
shot to photons deposited ratio >>1 sometimes an indication and that
might relate to (a) somewhat.
c) Quite a few photon scenes I've seen are relatively simple. Single
water surface, lens, etc . In your scene you have quite a few lights and
quite a few glassy / reflective objects. The more bounce/bend surfaces
the higher your photon density needs to be because a lot of it spreads.
Scenes like the one posted are also more sensitive max trace levels. The
greater that depth the more accurate results, but also you tend to need
to shoot more photons... Long winded way to say it might just be you
need a lot of photons...
Aside: Since you have multiple lights... Christoph added some
parallelism when shooting photons based upon each light source. Long
wondered how much we might speed up photon generation on a large
machines like yours by creating multiple, near duplicate light sources
where each light source sits today. My bet is it would speed up the
photon shooting step quite a bit if you have the cores - and slight
offsets in the near duplicates might help the deposited distribution
some. Would have to manage/adjust intensities for the multiples. If your
interested in some experimentation, I'd be interested in what you find.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Aside: Since you have multiple lights... Christoph added some
> parallelism when shooting photons based upon each light source. Long
> wondered how much we might speed up photon generation on a large
> machines like yours by creating multiple, near duplicate light sources
> where each light source sits today. My bet is it would speed up the
> photon shooting step quite a bit if you have the cores - and slight
> offsets in the near duplicates might help the deposited distribution
> some. Would have to manage/adjust intensities for the multiples. If your
> interested in some experimentation, I'd be interested in what you find.
>
> Bill P.
It's not a good idea to duplicate lights. It's even worst in a photons
scene as the photons from the duplicated lights will be shot in the same
pattern and end up in the same locations = more photons, but same end
result.
It would be better to use area_light and add photons{area_light} to it's
definition.
This also tend to make photons more fuzzy, which may help hide the
graininess.
Also, avoid using sor with the open option. This is particularly
important with any object with an ior.
When you encounter a single surface, light get bent once. If you
encounter two surfaces, it is like the object is solid thorough.
You need to actually model the inner side of your object by backtracking
to the start point and shift your points slightly inward.
The open option should never be used with any transparent object, no
matter what primitive is used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/25/19 7:03 PM, Alain Martel wrote:
>
>> Aside: Since you have multiple lights... Christoph added some
>> parallelism when shooting photons based upon each light source. Long
>> wondered how much we might speed up photon generation on a large
>> machines like yours by creating multiple, near duplicate light sources
>> where each light source sits today. My bet is it would speed up the
>> photon shooting step quite a bit if you have the cores - and slight
>> offsets in the near duplicates might help the deposited distribution
>> some. Would have to manage/adjust intensities for the multiples. If
>> your interested in some experimentation, I'd be interested in what you
>> find.
>>
>> Bill P.
>
> It's not a good idea to duplicate lights. It's even worst in a photons
> scene as the photons from the duplicated lights will be shot in the same
> pattern and end up in the same locations = more photons, but same end
> result.
>
> It would be better to use area_light and add photons{area_light} to it's
> definition.
>
> This also tend to make photons more fuzzy, which may help hide the
> graininess.
>
Thanks for bringing up area lights with photons! Something I forgot in
the moment was available with photon shooting. I've also got in my head
there are some limitations when used with photons and I do not believe
area lights will help much with photon shooting speed. The results as
you say though are perhaps better / more fuzzy.
I did a poor job describing my aside about creating more light sources.
Given how many photons are getting shot for a good result, my bet is
photon shooting dominates the render time. The parallelism added was
primarily by light source IIRC. To maximally use this photon shooting
parallelism you need more light sources up to the number of effective
cores you've got(1).
Yes, you must split lights smartly - which is what I was trying to hint
at with the 'near duplicate' / 'slight offsets' wording.
Part of what I think is driving the need for so many photons in
Norbert's scene is there are long vertical cylinders or cylinder-like
portions of sors(2). The spiral shooting pattern crosses those only
occasionally so it's likely going to generate bursts of deposited
photons at each crossing - this likely effect is a candidate contributor
for the graininess of the deposited photons.
So, my thinking for creating additional light sources would be say to
split each of the existing 4 light sources into 4 each for a total of 16
sources. Each set of 4 would be spaced vertically so the spiral patterns
of each are offset; the intensities/4; the global photon spacing/4. It
might make sense to do area lights on top of this - but there is already
jitter as we spiral and shoot.
Aside: Something else which can create fuzzier results is to override
the automatic gathering radius - make them larger. There are too some
sampling counts that can be adjusted but I don't remember details. I
think you can specify values for the target specification too other than
1.0 though never played with it.
> Also, avoid using sor with the open option. This is particularly
> important with any object with an ior.
> When you encounter a single surface, light get bent once. If you
> encounter two surfaces, it is like the object is solid thorough.
> You need to actually model the inner side of your object by backtracking
> to the start point and shift your points slightly inward.
>
> The open option should never be used with any transparent object, no
> matter what primitive is used.
I go along with what you've said up to this last 'never' rule. Never
using open with media containers is a good rule. If we are just talking
about transparency and want a visual effect and not physical accuracy, I
think using opens are OK. What matters is whether the shape supports an
inside-test/interior where the ior is tracked, and sors do.
You can use open objects with a defined inside / interior in csg and
that single surface can create refracted rays. Might not correspond to
any real world thing, but for effects, why not. You can also put such
single surfaces together to form other 'complete/closed surface'
transparent/ior/media supporting objects.
Lastly, if we want to go deeper, 'open' with sors is itself fuzzy. The
user with their point list can effectively close a specified 'open'
shape by taking the curve at one, or both, ends back to the origin. In
such cases any 'open' gets ignored though having it might help
performance as the cap tests can be avoided immediately. Further, rays
which intersect only with the sor's sides are effectively sor-closed no
matter the sor having actual ends or not.
Bill P.
(1) - Might there be a place for photon shooting only light sources.
Used only to deposit photons and not after..?
(2) - There are other ways to increase the photon shooting densities on
such shapes - breaking them more box or sphere like parts and not
turning off split_unions(3)
(3) - Spot lights / cylinder lights can still largely miss when doing
this kind of thing. Gets complicated to optimize. In the long term might
other photon shooting methods / patterns help? Something like the
user_defined camera / pigment capability but in a light source with
respect to shooting photons. Letting the user specify the shooting
patterns they want.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 9/25/19 7:03 PM, Alain Martel wrote:
>>
>>> Aside: Since you have multiple lights... Christoph added some
>>> parallelism when shooting photons based upon each light source. Long
>>> wondered how much we might speed up photon generation on a large
>>> machines like yours by creating multiple, near duplicate light
>>> sources where each light source sits today. My bet is it would speed
>>> up the photon shooting step quite a bit if you have the cores - and
>>> slight offsets in the near duplicates might help the deposited
>>> distribution some. Would have to manage/adjust intensities for the
>>> multiples. If your interested in some experimentation, I'd be
>>> interested in what you find.
>>>
>>> Bill P.
>>
>> It's not a good idea to duplicate lights. It's even worst in a photons
>> scene as the photons from the duplicated lights will be shot in the
>> same pattern and end up in the same locations = more photons, but same
>> end result.
>>
>> It would be better to use area_light and add photons{area_light} to
>> it's definition.
>>
>> This also tend to make photons more fuzzy, which may help hide the
>> graininess.
>>
>
> Thanks for bringing up area lights with photons! Something I forgot in
> the moment was available with photon shooting. I've also got in my head
> there are some limitations when used with photons and I do not believe
> area lights will help much with photon shooting speed. The results as
> you say though are perhaps better / more fuzzy.
>
> I did a poor job describing my aside about creating more light sources.
> Given how many photons are getting shot for a good result, my bet is
> photon shooting dominates the render time. The parallelism added was
> primarily by light source IIRC. To maximally use this photon shooting
> parallelism you need more light sources up to the number of effective
> cores you've got(1).
The parallelism come in effect every time you have more than a single
target or light sources.
The potential threads count is (NumberOfLight * NumberOfTargets)
Two light and four targets mean that you can use up to 8 threads.
>
> Yes, you must split lights smartly - which is what I was trying to hint
> at with the 'near duplicate' / 'slight offsets' wording.
>
> Part of what I think is driving the need for so many photons in
> Norbert's scene is there are long vertical cylinders or cylinder-like
> portions of sors(2). The spiral shooting pattern crosses those only
> occasionally so it's likely going to generate bursts of deposited
> photons at each crossing - this likely effect is a candidate contributor
> for the graininess of the deposited photons.
In that case, it may be interesting to split those long objects into a
string of shorter cylinders, or avoid shooting any photons at them.
>
> So, my thinking for creating additional light sources would be say to
> split each of the existing 4 light sources into 4 each for a total of 16
> sources. Each set of 4 would be spaced vertically so the spiral patterns
> of each are offset; the intensities/4; the global photon spacing/4. It
> might make sense to do area lights on top of this - but there is already
> jitter as we spiral and shoot.
An area_ligh of 1 by 4 would be better as you'll benefit from area_light
optimisation.
>
> Aside: Something else which can create fuzzier results is to override
> the automatic gathering radius - make them larger. There are too some
> sampling counts that can be adjusted but I don't remember details. I
> think you can specify values for the target specification too other than
> 1.0 though never played with it.
>
> > Also, avoid using sor with the open option. This is particularly
> > important with any object with an ior.
> > When you encounter a single surface, light get bent once. If you
> > encounter two surfaces, it is like the object is solid thorough.
> > You need to actually model the inner side of your object by backtracking
> > to the start point and shift your points slightly inward.
> >
> > The open option should never be used with any transparent object, no
> > matter what primitive is used.
>
> I go along with what you've said up to this last 'never' rule. Never
> using open with media containers is a good rule. If we are just talking
> about transparency and want a visual effect and not physical accuracy, I
> think using opens are OK. What matters is whether the shape supports an
> inside-test/interior where the ior is tracked, and sors do.
Ok. Never UNLESs you actually want to create some special effect.
Insert a comment in your code if you do that to explitely tel your intent.
>
> You can use open objects with a defined inside / interior in csg and
> that single surface can create refracted rays. Might not correspond to
> any real world thing, but for effects, why not. You can also put such
> single surfaces together to form other 'complete/closed surface'
> transparent/ior/media supporting objects.
You can have a single polygon or triangle that is transparent and have
an ior. It will refract light.
>
> Lastly, if we want to go deeper, 'open' with sors is itself fuzzy. The
> user with their point list can effectively close a specified 'open'
> shape by taking the curve at one, or both, ends back to the origin. In
> such cases any 'open' gets ignored though having it might help
> performance as the cap tests can be avoided immediately. Further, rays
> which intersect only with the sor's sides are effectively sor-closed no
> matter the sor having actual ends or not.
>
> Bill P.
>
> (1) - Might there be a place for photon shooting only light sources.
> Used only to deposit photons and not after..?
>
> (2) - There are other ways to increase the photon shooting densities on
> such shapes - breaking them more box or sphere like parts and not
> turning off split_unions(3)
>
> (3) - Spot lights / cylinder lights can still largely miss when doing
> this kind of thing. Gets complicated to optimize. In the long term might
> other photon shooting methods / patterns help? Something like the
> user_defined camera / pigment capability but in a light source with
> respect to shooting photons. Letting the user specify the shooting
> patterns they want.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/27/19 11:46 AM, Alain Martel wrote:
...
Thanks for the clarification on how the photon shooting parallelism works.
>
> You can have a single polygon or triangle that is transparent and have
> an ior. It will refract light.
>
...
I was aware the disc had a defined inside and would support an interior,
but wasn't aware single polygons or triangles were like this too. My
original polygon concern was then not warranted.
...
>>
>> (3) - Spot lights / cylinder lights can still largely miss when doing
>> this kind of thing. Gets complicated to optimize.
...
>>
>
OK... Some thinking aloud where I'm not completely sure what POV-Ray is
doing today.
On splitting the cylinders (and perhaps tori too) into chunks. My
footnote 2 & 3 sort of hinted at the issues I believe we might have with
that approach. Norbert has spotlights and those, like cylinder lights, I
believe define the spiral pattern with respect to the light source
definition not to the target shape's bounding box. Meaning breaking
those shapes up will increase the number of light-shape pairings during
photon shooting without changing the end result.
In other words, my current understanding is if we changed spots to point
lights we'd change to always centering the shooting spiral on each
shape's bounding box. The splitting then would perhaps help more in that
situation. Does my current understanding match what you (or others)
think happens?
Also if right we could probably improve photon shooting performance
quite a bit with a split_union off for that grille then splitting it
into multiple unions where for some the whole sub-union might be outside
the spot spirals.
Anyway, as an experiment I took the scene and changed back grille so it
was not involved in the photon shooting to test the idea its mostly
causing the graininess. Also changed photon spacing from 0.004 to 0.02.
Attached is the result which took about 13 minutes (8 of it photon
shooting) on my little 2 core i3.
The result I think lines up OK with how I think spot light photon
shooting works and my suspicion the bursts of photons from the spirals
crossing that back grille are involved in the graininess. There is still
a little, but I suspect its coming mostly from the stem of that left sor.
Aside: Yep, a comparison to a render with the grille as a photon target
would be ideal, but that render is still shooting photons after two
hours and not sure I have the patience to let it finish...
Bill P.
Post a reply to this message
Attachments:
Download 'verres1_nophotogrill.png' (759 KB)
Preview of image 'verres1_nophotogrill.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/28/19 9:40 AM, William F Pokorny wrote:
> On 9/27/19 11:46 AM, Alain Martel wrote:
...
>
> Aside: Yep, a comparison to a render with the grille as a photon target
> would be ideal, but that render is still shooting photons after two
> hours and not sure I have the patience to let it finish...
>
Got it. See attached. Almost 3 hours elapsed to do the photon shooting
with the back grille as a target vs 8 minutes if not... There are some
jitter and multi-thread differences too - ignore them. It's the grille.
Bill P.
Post a reply to this message
Attachments:
Download 'verres1_wphotogrill_to_verres1_nophotogrill.jpg' (277 KB)
Preview of image 'verres1_wphotogrill_to_verres1_nophotogrill.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
