Here's the images associated with a similarly named post in p.g ...

I'll try to pare down the scene to get a repro file for the dev team.

Post a reply to this message

Attachments:
Download 'oj-rad.jpg' (21 KB) Download 'oj-norad.jpg' (22 KB)

Preview of image 'oj-rad.jpg'

Preview of image 'oj-norad.jpg'

"Michael Raiford" <mra### [at] hotmailcom> wrote in message
news:40cbd61b@news.povray.org...
> Here's the images associated with a similarly named post in p.g ...
>
> I'll try to pare down the scene to get a repro file for the dev team.

The scene file is on p.t.s-f, now ...

Post a reply to this message

Hmmmmm. Wish I knew the real reason for the change but it manifests itself
somehow in the position of the lights and adaptive value of the area lights.

To see what I mean, try dividing the first light's position vector by 1.1,
which will be <-15, 45, -35>/1.1. Also give it adaptive 2 instead of 0.
Change the three under-cabinet spotlight positions so that they are at y=9
and z=4, x remaining same.
Make the second area light adaptive 2, as well.

In your posted scene script you had put a max_trace_level 200 at the top, it
belongs in the global_settings block but I found it wasn't needed to see the
supposed solution.

Looks like the second box in the union of the CounterBody object ends up
with its lowest side where those three under-counter lights were (are), so
you'll need to watch out for those kinds of alignments. The coincident
surfaces phenomenon tends to include lights and camera at object surfaces.

Bob H.

Post a reply to this message

"Hughes, B." <omn### [at] charternet> wrote in message
news:40cc2431$1@news.povray.org...
> Hmmmmm. Wish I knew the real reason for the change but it manifests itself
> somehow in the position of the lights and adaptive value of the area
lights.
>
> To see what I mean, try dividing the first light's position vector by 1.1,
> which will be <-15, 45, -35>/1.1. Also give it adaptive 2 instead of 0.
> Change the three under-cabinet spotlight positions so that they are at y=9
> and z=4, x remaining same.
> Make the second area light adaptive 2, as well.

That works, but why?

> In your posted scene script you had put a max_trace_level 200 at the top,
it
> belongs in the global_settings block but I found it wasn't needed to see
the
> supposed solution.

Yeah, part of it is this scene is an old scene that was revised for 3.5/3.6

> Looks like the second box in the union of the CounterBody object ends up
> with its lowest side where those three under-counter lights were (are), so
> you'll need to watch out for those kinds of alignments. The coincident
> surfaces phenomenon tends to include lights and camera at object surfaces.
>
> Bob H.

From what I have seen the coincident surfaces problem usually manifests
itself as a random speckling of the object and/or light source. In reality,
the spotlight should not affect the cabinet above them. I am a bit suprised
I didn't see the usual coincident surfaces issue before in this scene.

All in all, this has the hallmarks of an accuracy problem. (i.e. really far
away objects viewed with a really narrow camera angle seem to have drop-out
like this). But in my case, the values are within practical limits..

Hmmm...

Post a reply to this message

"Michael Raiford" <mra### [at] hotmailcom> wrote in message
news:40cc619e@news.povray.org...
>
> From what I have seen the coincident surfaces problem usually manifests
> itself as a random speckling of the object and/or light source. In
reality,
> the spotlight should not affect the cabinet above them. I am a bit
suprised
> I didn't see the usual coincident surfaces issue before in this scene.

Yeah, well, I wouldn't place any light at a surface even if it is a
spotlight pointing away from it. Just asking for trouble.
:-)

> All in all, this has the hallmarks of an accuracy problem. (i.e. really
far
> away objects viewed with a really narrow camera angle seem to have
drop-out
> like this). But in my case, the values are within practical limits..

It definitely merits looking into, I believe. What I thought was fixed by
moving the light sources actually remains artifact-prone when changing
resolutions. Very peculiar. Has me baffled since the scene file isn't what
I'd call extreme, so worries me a little. A couple area lights, three spot
lights, some primitives like box, plane, cylinder, sphere... I checked using
a simple pigment {color rgb 1} in place of the textures, and the blanking
out parts stayed so I figured it couldn't be related to max_trace_level.

Just now, I found out the 'media on' in radiosity will cause the blanking.
Commenting it out I can render the scene okay even though all lights are in
their original positions. I should have tried that before. In fact, there's
a relation with 'count' too, because count 50 clears it up while media is
on.

It's times like this I wish I had done more beta testing.

Bob H.

Post a reply to this message

"Hughes, B." <omn### [at] charternet> wrote in message
news:40cc79f2$1@news.povray.org...
> "Michael Raiford" <mra### [at] hotmailcom> wrote in message
> news:40cc619e@news.povray.org...
> Yeah, well, I wouldn't place any light at a surface even if it is a
> spotlight pointing away from it. Just asking for trouble.
> :-)

Agreed... But I think my point was more along the lines of the light
wouldn't have much effect, still, I wish I had cought that problem earlier,
though... The actual scene is years old anyway, so it's not suprising that
something like that was in it ;)

> It definitely merits looking into, I believe. What I thought was fixed by
> moving the light sources actually remains artifact-prone when changing
> resolutions. Very peculiar. Has me baffled since the scene file isn't what
> I'd call extreme, so worries me a little. A couple area lights, three spot
> lights, some primitives like box, plane, cylinder, sphere... I checked
using
> a simple pigment {color rgb 1} in place of the textures, and the blanking
> out parts stayed so I figured it couldn't be related to max_trace_level.

Hmm.. I left the textures in because I thought there was a relationship...
Guess that's unrelated as well.

> Just now, I found out the 'media on' in radiosity will cause the blanking.
> Commenting it out I can render the scene okay even though all lights are
in
> their original positions. I should have tried that before. In fact,
there's
> a relation with 'count' too, because count 50 clears it up while media is
> on.

Hm... I knew the media and media on were affecting this. (this is primarily
why it had media in the repro scene in the first place...)... I'm wondering
where the bug was introduced exactly. It seems to be in the code that
handles the interaction between radiosity and scattering media.

> It's times like this I wish I had done more beta testing.

Heh, same here. But when the betas were available, I'd play around a bit,
but most of my scene work was done in 3.5, simply to keep things stable.
Next beta I think I'll force myself to work with the beta more frequently.

Post a reply to this message

I'm back again.

A real puzzle to me. I've tried a test scene that refuses to do the same
kind of thing even after adding in your orange juice object macros and
radiosity. It has one area light and one spotlight, with the spotlight being
located on the surface of a plane. Nothing... all okay.

So then I added your lights and the problem appears. Commented the three
spotlights out and it was okay again, then let only one spotlight exist and
still was okay. When two or three were used the problem reappeared. But
that's not the end of the story. I tried my own three spotlights, only
located closer spaced in the x axis and placed on the z axis but kept at
y=10 where the y plane also exists. Nothing wrong again. Really strange.
They all have the same radius falloff and tightness, no different from each
other in that regard, only their vectors (location and point_at) are
different.

Needless to say, I don't know what to tell you beyond that.

Bob H.

Post a reply to this message