 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
an unrelated thread made me render the 'scenes/advanced/optics.pov' file. with
'povr' I get a strange "band" in the lower part of the image. attached.
regards, jr.
Post a reply to this message
Attachments:
Download 'povroptics.png' (210 KB)
Preview of image 'povroptics.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15/08/2020 à 17:21, jr a écrit :
> hi,
>
> an unrelated thread made me render the 'scenes/advanced/optics.pov' file. with
> 'povr' I get a strange "band" in the lower part of the image. attached.
>
>
> regards, jr.
>
Only for povr, at least hgpovray38 is clear of such noise, and so I
presume official master (3.8) too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Le_Forgeron <jgr### [at] free fr> wrote:
> Le 15/08/2020 à 17:21, jr a écrit :
> > an unrelated thread made me render the 'scenes/advanced/optics.pov' file. with
> > 'povr' I get a strange "band" in the lower part of the image. attached.
>
> Only for povr, at least hgpovray38 is clear of such noise, and so I
> presume official master (3.8) too.
yes, the alpha.10064268 output is ok. have not yet installed 'bigarade' on this
machine, so good to know, thanks.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/15/20 11:21 AM, jr wrote:
> hi,
>
> an unrelated thread made me render the 'scenes/advanced/optics.pov' file. with
> 'povr' I get a strange "band" in the lower part of the image. attached.
>
Thanks jr (and Jerome)!
I see it too in all my recent povr versions. It was OK in versions early
this year, so something I've done between then and early July.
I'll do a binary search - compile/run through my commits to find the
commit causing the problem. FYI. No photons required to see it.
(jr, If you are looking for a scene with a parabolic mirror I recall
Warp doing one some years ago which he posted. I thought had a copy
somewhere, but I cannot find it at the moment. He might have used a
polynomial for the shape.)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/15/20 11:21 AM, jr wrote:
> > an unrelated thread made me render the 'scenes/advanced/optics.pov' file. with
> > 'povr' I get a strange "band" in the lower part of the image. attached.
>
> Thanks jr (and Jerome)!
no sweat. :-)
> ...
> (jr, If you are looking for a scene with a parabolic mirror I recall
> Warp doing one some years ago which he posted. I thought had a copy
> somewhere, but I cannot find it at the moment. He might have used a
> polynomial for the shape.)
that should probably be addressed to 'ttyUSB0'. I was simply curious, following
Le Forgeron's reply to him/her.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/15/20 12:35 PM, William F Pokorny wrote:
> On 8/15/20 11:21 AM, jr wrote:
...
>
> I see it too in all my recent povr versions. It was OK in versions early
> this year, so something I've done between then and early July.
>
> I'll do a binary search - compile/run through my commits to find the
> commit causing the problem. FYI. No photons required to see it.
>
I broke the checker pattern on March 29th. ;-)
---
There has been a defined EPSILON value floating around in the code for a
long time. Over the years it sort of got used any time folks had the
thought, "I need an epsilon value." All to often it was (at 1e-10) a
non-optimal value to use.
I've been cleaning these up; mostly breaking them into two buckets after
determining what I thought good values numerically while doing my solver
work. A treat this as zero epsilon and a good supportable intersection
depth tolerance. The former I called gkDBL_epsilon which is a little
larger than the C++ DBL_epsilon macro value and the other is called
gkMinIsectDepthReturned(1).
When I updated EPSILON in the checker pattern, I used gkDBL_epsilon when
I should've used gkMinIsectDepthReturned. Yes, this is an intersection
with a plane, low order and more accurate - it was mostly working
anyway. The actual supportable value is certainly between the two values
I settled on. But, going with the standard gkMinIsectDepthReturned in
checker unless something 'else' breaks.
Aside: Yes, sometimes you really need somewhat unique 'epsilon' values.
When I was cleaning up the tiling patterns for isosurface use, I ran
across a collection of such values where someone had commented that a
C++ macro should perhaps be used. But in testing each, every one of
those needed to be what they were to the order of magnitude. Jerome had
done his homework! :-)
Anyway, thanks again for spotting this / testing.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I broke the checker pattern on March 29th. ;-)
> ...
> When I updated EPSILON ... it was mostly working anyway. ...
:-)
> ...
> Anyway, thanks again for spotting this / testing.
anytime. (while I can, 'povr' permitting. ;-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
