 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Documenting long standing exposures with the sor tutorial example.
Ref:
https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Index_Entry_sor_tutorial
---
The cocktail outline has a flattish portions which are difficult for the
solvers to handle. Similar to the lathe, the sor likes curvature in the
spline used (excepting linear splines with the lathe).
In the attached image, the blue results come from v3.8 beta 2, the
yellow from R20 of yuqk. No AA to better see the issues.
The two columns for each version of POV-Ray represent the non-sturmian
solver and then the sturmian solver.
The bottom two rows put the camera into the cocktail. The very bottom
row adds caps and the results 'should be' completely black.
Notes:
a) The non-sturmian solver has difficultly in both v3.8 beta 2 and
yuqk(R20) given certain ray approaches.
b) The sturmian solver has trouble too in v3.8 b2 - in the shadow
regions of the top row, for example.
c) The sturmian solver in yuqk returns clean results for all the
examples run.
d) The yellow pixels at the very top of the yuqk results in the lower
right are due the intersections hitting deep in the crevice between the
lip of the cocktail form and the cap.
When the intersection is closer to the cap plane than the internal
shadow tolerance value (1e-3) shadow rays see through to lights. The
artifacts exist in both v3.8 and yuqk at larger image sizes.
The yuqk fork has the 'shadow_tolerance' global setting which allows the
default 1e-3 value to be reduced - greatly reducing the likelihood
shadow rays will see through the cap due the shadow tolerance value. The
exposure never goes completely away in situations like this. AA often
helps hide these issues when they come up.
Bill P.
Post a reply to this message
Attachments:
Download 'tutorialsorissues.png' (75 KB)
Preview of image 'tutorialsorissues.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
> Documenting long standing exposures with the sor tutorial example.
>
> Ref:
>
>
https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Index_Entry_sor_tutorial
>
[running v3.7.0 and 3.8 beta 1-- the results are essentially the same]
Windows 10
I ran a lot of animation tests, moving the scene elements around in relation to
one another, and this is how the situation appears to me when using 'sturm':
1) For the OUTSIDE surface of the SOR that *faces* the light source (whether or
not 'open' is also used):
sturm OFF: lots of noise and artifacts
sturm ON: no noise that I can see
2) For the 'open' INSIDE surface, in the *shadow* areas:
sturm OFF: no noise that I can see
sturm ON: lots of noise etc.
So I wonder if the problem is just shadow artifacts: sturm on/off has the
opposite effect on the inside and outside-- and on the lighted surface vs.
shadowed surface(!)
The appearance of the noise and the artifacts on the *outside* depends on the
the camera position, its look_at point, the position of the light(s) and the
orientation of the SOR-- all of which interact, unfortunately. It looks the
worst to me when the y-positions of all three are the same (and not just when
the camera is looking straight into +z).
Since the SOR when 'open' is really just an infinitely thin shell, it seems to
me that using it this way is not a good idea anyway, as the walls have no
thickness at all and look unrealistic. (The docs also mention that it shouldn't
be used in CSG this way.)
(BTW: I tried using 'inverse' in the SOR, just to see if it made any difference
at all. It does not.)
I'll follow up here with a few of the test animations I made.
Post a reply to this message
Attachments:
Download 'sor_sturm_tests_1_kw.jpg' (190 KB)
Preview of image 'sor_sturm_tests_1_kw.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> It looks the
> worst to me when the y-positions of all three are the same (and not just when
> the camera is looking straight into +z).
>
That was not clear, sorry: the y-positions of the camera location, its look_at
point, and the light.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I'll follow up here with a few of the test animations I made.
Animation #1
Post a reply to this message
Attachments:
Download 'sor_docs_example_1_kw.mp4.dat' (4009 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Animation #2
Post a reply to this message
Attachments:
Download 'sor_docs_example_2_kw.mp4.dat' (4026 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Animation #3
Post a reply to this message
Attachments:
Download 'sor_docs_example_3_kw.mp4.dat' (1567 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Animation #4
Post a reply to this message
Attachments:
Download 'sor_docs_example_4_inside_surface_kw.mp4.dat' (2609 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/2/25 14:08, Kenneth wrote:
Thanks for confirming on windows.
> So I wonder if the problem is just shadow artifacts: sturm on/off has the
> opposite effect on the inside and outside-- and on the lighted surface vs.
> shadowed surface(!)
>
I agree. The bad sturm results for official are shadow related.
However, I believe this due the sturm results, sometimes, not being that
accurate - by position. Specifically, I'd bet here on a 'quicker exit'
bug in the regula-falsi code - fixed in yuqk - which finishes off the
root calculation once an interval with a single root has been found by
the sturmian portion of 'sturm'(*).
> The appearance of the noise and the artifacts on the*outside* depends on the
> the camera position, its look_at point, the position of the light(s) and the
> orientation of the SOR-- all of which interact, unfortunately. It looks the
> worst to me when the y-positions of all three are the same (and not just when
> the camera is looking straight into +z).
>
> Since the SOR when 'open' is really just an infinitely thin shell, it seems to
> me that using it this way is not a good idea anyway, as the walls have no
> thickness at all and look unrealistic. (The docs also mention that it shouldn't
> be used in CSG this way.)
No... :-) The sor{}s are more like cylinders/cones in having well
defined inside regions always with two surfaces when using caps and,
potentially, only a single surface - with the same, well defined, inside
region - depending on the ray path when not using caps.
In playing more with the sor{} shape recently, I've come to think it
more useful due potential use in CSG! The sor{} doesn't have the fuzzy
issues with defining an inside regions which Cousin Ricky highlighted
recently for the lathe{} at fold-backs, for example.
Bill P.
(*) - I have more sturmian solver work years now on the todo list;
Including replacing the regula-falsi code with a dedicated
newton-raphson solver I wrote from scratch that always resolves to the
root once given an interval known to have a root. That work though is
tangled in also wanting to remove a re-ordering of coefficients into the
sturmian part of 'sturm' that I suspect was long ago done for
convenience, but which burns time.
I have too another solver approach which, for accuracy is much better
than 'sturm'. However, it requires even more re-working of code because
it merges the per shape polynomial generation and solver into one
method. Maybe someday...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
