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