|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/13/19 1:56 PM, Norbert Kern wrote:
> "Jasper" <nomail@nomail> wrote:
...
>
> OK, this doesn't have anything to do with radiosity - so I agree on floating
> point precision issues as cause...
>
> Norbert
>
Is this still true for you with recent v38 releases?
I'd captured the case(s) you posted a couple years back - my notes say
in 2016. I wasn't able to run what you posted directly on my little
machine, but a cut down scene was fixed when I tested a v3.71 branch
March 17, of 2017.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19-05-15 à 10:11, William F Pokorny a écrit :
> On 5/13/19 1:56 PM, Norbert Kern wrote:
>> "Jasper" <nomail@nomail> wrote:
> ...
>>
>> OK, this doesn't have anything to do with radiosity - so I agree on
>> floating
>> point precision issues as cause...
>>
>> Norbert
>>
>
> Is this still true for you with recent v38 releases?
>
> I'd captured the case(s) you posted a couple years back - my notes say
> in 2016. I wasn't able to run what you posted directly on my little
> machine, but a cut down scene was fixed when I tested a v3.71 branch
> March 17, of 2017.
>
> Bill P.
The version don't matter when you hit the FPU's limits.
Don't forget that in computing the illumination, there are a few
squaring and square roots involved. This typically demand twice the
number of bits of the input value if you want to avoid loss of precision.
When you square a 64 bits floating point value, you need 128 bits to
accurately represent the result.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/15/19 3:36 PM, Alain wrote:
> Le 19-05-15 à 10:11, William F Pokorny a écrit :
>> On 5/13/19 1:56 PM, Norbert Kern wrote:
>>> "Jasper" <nomail@nomail> wrote:
>> ...
>>>
>>> OK, this doesn't have anything to do with radiosity - so I agree on
>>> floating
>>> point precision issues as cause...
>>>
>>> Norbert
>>>
>>
>> Is this still true for you with recent v38 releases?
>>
>> I'd captured the case(s) you posted a couple years back - my notes say
>> in 2016. I wasn't able to run what you posted directly on my little
>> machine, but a cut down scene was fixed when I tested a v3.71 branch
>> March 17, of 2017.
>>
>> Bill P.
>
> The version don't matter when you hit the FPU's limits.
...
True. However, the reason I was digging into Norbert's particular
radiosity normals issue is that I intended to open up a github issue for
it so we didn't lose track of it.
My view is that unlike other places in POV-Ray where we hit numerical
issues, really tiny normals should just be treated as zero normals / no
normals - or perhaps be normalized somehow so they don't cause issues.
Probably good too if 'bad' normal scalings can be detected and the user
warned before they get ignored - but that's probably hard to the point
of being practically impossible.
In any case I didn't think his situation should be causing artifacts
like we were seeing in the output image.
The scaled very tiny normals were causing issues with Norbert's original
renders in 2016. When I looked at the issue in 2017 to create a github
issue, it looked like the issue had been fixed. The complication was the
original scenes as posted - I think even one smaller one posted later -
were too costly for my little machine. So, I evaluated behavior on
something I thought similar hoping to use it as the scene for the issue.
I might have gotten something wrong. I might have done something which
caused the issue to be there in (v??? don't remember) and gone in the
3.71 version I was testing against.
If Norbert still sees black spots with his original scenes using a
current v3.8, the issue still exists and I think we should open a github
issue for it. It's on my list again to try and run one of his originally
posted scenes again with v38 - but I'm in the middle of several other
projects and that won't happen for some time.
Suppose I'm hoping for a quick - "Oh, it works OK now" - answer/status
from Norbert to save some time! :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Having a try at light distributions
Date: 23 May 2019 05:38:50
Message: <5ce66a2a@news.povray.org>
|
|
|
| |
| |
|
|
On 5/17/19 5:29 AM, William F Pokorny wrote:
...
>
> If Norbert still sees black spots with his original scenes using a
> current v3.8, the issue still exists and I think we should open a github
> issue for it. It's on my list again to try and run one of his originally
> posted scenes again with v38 - but I'm in the middle of several other
> projects and that won't happen for some time.
>
> Suppose I'm hoping for a quick - "Oh, it works OK now" - answer/status
> from Norbert to save some time! :-)
>
> Bill P.
I ran Norbert's cut down scene last night - it wasn't mine as I
remembered. It looks to me this morning, as my notes indicate it did to
me back in 2017, as if this particular radiosity normals issue is fixed.
If others see a radiosity issue I don't, please speak up.
Image is attached. Using heavy AA as the black speckles show worse in
v37 that way. Top is the current v37 result. The bottom the v38 result
at commit 74b3ebe.
Bill P.
Post a reply to this message
Attachments:
Download '02feb2016radiositynrmlsissue37to38.png' (1248 KB)
Preview of image '02feb2016radiositynrmlsissue37to38.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I ran Norbert's cut down scene last night - it wasn't mine as I
> remembered. It looks to me this morning, as my notes indicate it did to
> me back in 2017, as if this particular radiosity normals issue is fixed.
> If others see a radiosity issue I don't, please speak up.
>
> Image is attached. Using heavy AA as the black speckles show worse in
> v37 that way. Top is the current v37 result. The bottom the v38 result
> at commit 74b3ebe.
>
> Bill P.
Since you are asking directly - my problems were solved after this special IRTC
round by deleting small normals at the normal section - what else....
No, it wasn't that easy, but anyway...
Since then I deleted small normals, when black spots occured. Of course I'm
curious of the root cause, but my focus is more on the result...
But here I'm curious...
Norbert
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/23/19 2:30 PM, Norbert Kern wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
...
>
> Since you are asking directly - my problems were solved after this special IRTC
> round by deleting small normals at the normal section - what else....
> No, it wasn't that easy, but anyway...
>
> Since then I deleted small normals, when black spots occured. Of course I'm
> curious of the root cause, but my focus is more on the result...
> But here I'm curious...
>
If the normals are so small at the scene scale they cannot be seen, it
makes sense compute resource wise to remove them no matter. In a strange
way, seeing the black artifacts was an indication texture normals too
small existed and we no longer have this in v38.
Still, I think POV-Ray should handle/filter such normals as people
sometimes are using a texture/material others coded and it shouldn't
completely break when used at a different scale(1).
I don't myself know what changed in the code post v37. Maybe something
got fixed with the static code analysis Christoph runs and reviews now
and again. I don't remember a specific commit for such an issue, but my
memory is less good these days. I too might have been busy with real
life when the change happened.
It is possible to do a binary search of commit versions to localized the
commit(s) which fixed the issue for your scene. I've done this sort of
work especially for performance issues. However, it's a very time
consuming process always. A process worse on *nix systems like mine
where we must work around sequences of commits in the history which
don't compile. I have no plans to look for what got fixed - given it
looks to be fixed.
That said, if you see black spot artifacts due normals in a recent v38
release, a sample scene would be appreciated.
Bill P.
(1) Drifting... With published materials/textures I think it would be
helpful to later users to know the original scale where the texture was
developed and applied. "M_RustyIron12. Applied at 1x scale to objects in
a 100x,100y,100z range centered at the origin. Camera distance to object
with texture was roughly 350." Other stuff? Suppose most of us assume
development in a -1,1 box at the origin and normal-ish camera set up
after which we fish around for what looks good.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Having a try at light distributions
Date: 24 May 2019 09:48:12
Message: <5ce7f61c@news.povray.org>
|
|
|
| |
| |
|
|
On 5/15/19 10:04 AM, William F Pokorny wrote:
> On 5/13/19 7:29 AM, Jasper wrote:
...
>
> Hmm, I have to say I'm curious about the regularity of those black
> spots. The numerical issues I've hit are usually noisier - or completely
> black/invisible/something when a hard numerical limit is hit.
>
> Any chance I could get a smallish test case posted to one of the scene
> file groups? I'll stick it in my POVRay_Issues directory and at least
> take a quick look if not now a deep one.
>
I dug out some work I was doing early in 2018 where I was using a
user_defined functional pigment as the sphere's texture around the
light. At the time I was thinking it might be a good way to define
texture maps or even use use such 'noisy lights' in a scene instead of -
or in addition to - traditional materials. In particular I was thinking
about human skin. The set up is similar to yours except how the texture
is defined.
There was also recent discussion around user_defined cameras and
transforms and it hit me I'd never tested moving my user_defined pigment
around though I fully hoped that technique would work with simple
transforms. It appears it does not - see the attached image 1e5 column.
Not shown, but 1e3 results similarly corrupted and that movement well
away from numerical issues.
So, I got two issues for the price of trying to verify yours! Good news
is I now have a small test scene for both.
Bill P.
Post a reply to this message
Attachments:
Download 'lightinspheretran1e6story.png' (694 KB)
Preview of image 'lightinspheretran1e6story.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19-05-24 à 08:39, William F Pokorny a écrit :
> On 5/23/19 2:30 PM, Norbert Kern wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>
> ...
>>
>> Since you are asking directly - my problems were solved after this
>> special IRTC
>> round by deleting small normals at the normal section - what else....
>> No, it wasn't that easy, but anyway...
>>
>> Since then I deleted small normals, when black spots occured. Of
>> course I'm
>> curious of the root cause, but my focus is more on the result...
>> But here I'm curious...
>>
>
> If the normals are so small at the scene scale they cannot be seen, it
> makes sense compute resource wise to remove them no matter. In a strange
> way, seeing the black artifacts was an indication texture normals too
> small existed and we no longer have this in v38.
>
The normals can be very small intentionally. If you want some blurred
reflection, or refraction, one common way is to use normals deliberately
scaled very small and use anti-aliasing.
In this case, you really don't want to have them removed as your
object's appearance depends on those micro-normals.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/24/19 8:59 PM, Alain wrote:
> Le 19-05-24 à 08:39, William F Pokorny a écrit :
...
>>
>> If the normals are so small at the scene scale they cannot be seen, it
>> makes sense compute resource wise to remove them no matter. In a
>> strange way, seeing the black artifacts was an indication texture
>> normals too small existed and we no longer have this in v38.
>>
>
> The normals can be very small intentionally. If you want some blurred
> reflection, or refraction, one common way is to use normals deliberately
> scaled very small and use anti-aliasing.
>
> In this case, you really don't want to have them removed as your
> object's appearance depends on those micro-normals.
>
Good point. What is meaningful with respect to texture normals depends
on the textures involved. Radiosity has its own dependencies when
normals are on/respected. The situation as a whole is complex. Further,
I both do not understand significant portions of the normal handling
code and know too with respect to warps there is code which looks to be
unfinished.
Norbert's problem normals were tangled in turbulence of some kind as I
vaguely remember.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/24/19 9:48 AM, William F Pokorny wrote:
> On 5/15/19 10:04 AM, William F Pokorny wrote:
>> On 5/13/19 7:29 AM, Jasper wrote:
> ...
>
> So, I got two issues for the price of trying to verify yours! Good news
> is I now have a small test scene for both.
>
I looked more closely at the test case this morning and the issues for
me are all me... I suppose because you were lighting an x,y plane and
moving in x,y, I coded this in my scene:
//--- scene ---
#if (0)
//camera { Camera00 }
camera { Camera01y } // An orthographic camera.
object { LightFxtr01 }
#else
#declare ValTranslate = 1e6;
//camera { Camera00 translate <ValTranslate,ValTranslate,0> }
camera { Camera01y translate <ValTranslate,ValTranslate,0> }
object { LightFxtr01 translate <ValTranslate,ValTranslate,0> }
#end
when the bottom part, given my scene is lighting a plane in x,z from y+,
should have been:
//camera { Camera00 translate <ValTranslate,0,ValTranslate> }
camera { Camera01y translate <ValTranslate,0,ValTranslate> }
object { LightFxtr01 translate <ValTranslate,0,ValTranslate> }
With movement at a constant height above the plane, I get identical
images from the origin all the way up to 1e6,0,1e6 in magnitude. I was
curious and moved orthographic camera +y by 1e6 and it still works - in
other words the camera to plane rays at 1e6 length are OK.
The numeric issue is moving the LightFxtr01 (point light and enclosing
textured sphere) off the plane by 1e6. In this case there are very long
shadow rays from the plane 'up' to the sphere and these will be
numerically wobbly at the sphere's surface. My guess now is you might
have done what I did in accidentally moving the light fixture away from
the plane, but perhaps it's something else.
Instead of posting an updated image of my test case, I'll just say an
updated one would be the left column of the previous repeated three times.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|