 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/23/22 15:48, Chris R wrote:
> I took my main scene and eliminated everything but the transparent box, and even
> added media to it and everything looked fine. I added one scene element at a
> time back and it was all fine until I added in the drip of water I had modeled
> falling from the downspout. As soon as I added that object back into the scene,
> the transparent box with media became a reflective mirror instead!
>
> The drip of water is modeled as a quartic. It had a material to look like
> water, (so transparent, ior 1.33, reflective, etc.). When I changed the
> material to just a simple gray pigment, the media box was no longer visible or
> reflective, but the media also disappeared.
Unsure...
What version of POV-Ray is being used?
Are the shapes involved part of the same union or merge?
The only obvious thing I can think of would be if the water material was
defined by name and happened to have the same name as the one used for
the media box - and the water material definition was seen last.
If you can get a simpler scene showing the issues I'll add it to my
collection for debug, though no promises as to when I'd dig. I've been
busy with other than POV-Ray of late.
--- Deeper and less likely possibility...
With some older shape types - due ill advised automatic polynomial order
reduction code combined with the lack of tight automatic / manual
bounding for some shapes - we sometimes end up with an additional root
(and so another surface) being introduced(a) by the auto-order reduction
itself.
Maybe something like this is going on but, that surface by order
reduction would have to have a very particular position to see the
results you posted.
A test for this fail would be to change your quartic to a simple sphere
or similar and see if the apparent reflection propagation to the box
problem persists?
(a) - One of the shipped scenes long has had a vertical line in the
result due the auto-order reduction changing two roots (4th order eqn)
to three roots (third order eqn) for one or more of the scene's shapes.
I cannot remember which it is for sure - primitiv.pov maybe? The povr
branch fixed this particular exposure(b) by ripping out the automatic
order reduction code.
(b) - Order reduction introduces slight root/surface shifts in the
intended roots even when it mostly works in a consistent way. The
reduction code also sometimes flips 'sturm on' to fixed solvers, without
notice due the order reduction, on a per ray->surface equation basis.
The sturm vs fixed solver results for identical equations are often not
themselves identical and this occasionally introduce at same surface,
subtle, consistency issues - which are sometimes visible. And there's
more 'solver noise' possible due the order reduction I won't detail -
partly because I no longer remember all the possible implications!
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2022-06-23 à 13:46, Chris R a écrit :
> The attached image shows two renderings of the same scene. The right image is
> the same as the left, except that I added a completely transparent box, whose
> purpose was to support media with some ground fog:
>
> box {
> -size/2, size/2
> texture { pigment { color rgbt 1 } }
> translate <0, size.y/2, 0>
> }
>
> As you can see, the box shows up as a mirror instead of being transparent.
>
> The scene is fairly complex, but here are a few details that might help point
> out to the experts what the problem might be:
>
> 1. The whole scene is inside of a mesh-based sky sphere, but I verified that
> the problem shows up even if that is turned off.
> 2. I have enabled radiosity, but I verified that the problem shows up without
> it as well.
> 3. The light source is a sun emulator using a parallel area_light at a far
> distance from the scene
>
> I also tried using rgbf 1.0 as the pigment for the box, but I get the same
> problem.
>
> Any ideas? It's driving me crazy
>
> -- Chris R.
That looks like it could be a coincident surface issue.
Try placing the box slightly lower so that it's bottom face is just
under the ground or slightly higher so that it don't touch the ground.
Some options :
box {
-size/2-0.1*y, size/2 // lower
texture { pigment { color rgbt 1 } }
translate <0, size.y/2, 0>
}
box {
-size/2+0.1*y, size/2 //higher
texture { pigment { color rgbt 1 } }
translate <0, size.y/2, 0>
}
box {
-size/2, size/2
texture { pigment { color rgbt 1 } }
translate <0, size.y/2-0.1, 0> // lower
}
box {
-size/2, size/2
texture { pigment { color rgbt 1 } }
translate <0, size.y/2+0.1, 0> //higher
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotron ca> wrote:
> > The attached image shows two renderings of the same scene. The right image is
> > the same as the left, except that I added a completely transparent box, whose
> > purpose was to support media with some ground fog:
> >
> > box {
> > -size/2, size/2
> > texture { pigment { color rgbt 1 } }
> > translate <0, size.y/2, 0>
> > }
> >
> > As you can see, the box shows up as a mirror instead of being transparent.
> >
> > The scene is fairly complex, but here are a few details that might help point
> > out to the experts what the problem might be:
> >
> > 1. The whole scene is inside of a mesh-based sky sphere, but I verified that
> > the problem shows up even if that is turned off.
> > 2. I have enabled radiosity, but I verified that the problem shows up without
> > it as well.
> > 3. The light source is a sun emulator using a parallel area_light at a far
> > distance from the scene
> >
> > I also tried using rgbf 1.0 as the pigment for the box, but I get the same
> > problem.
> >
> > Any ideas? It's driving me crazy
> >
> > -- Chris R.
>
> That looks like it could be a coincident surface issue.
> Try placing the box slightly lower so that it's bottom face is just
> under the ground or slightly higher so that it don't touch the ground.
> Some options :
> box {
> -size/2-0.1*y, size/2 // lower
> texture { pigment { color rgbt 1 } }
> translate <0, size.y/2, 0>
> }
>
> box {
> -size/2+0.1*y, size/2 //higher
> texture { pigment { color rgbt 1 } }
> translate <0, size.y/2, 0>
> }
>
> box {
> -size/2, size/2
> texture { pigment { color rgbt 1 } }
> translate <0, size.y/2-0.1, 0> // lower
> }
>
> box {
> -size/2, size/2
> texture { pigment { color rgbt 1 } }
> translate <0, size.y/2+0.1, 0> //higher
> }
Thanks, I thought about that too, but I simplified the scene to the point where
there were no more coincident surfaces and it still happened.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/23/22 15:48, Chris R wrote:
> > I took my main scene and eliminated everything but the transparent box, and even
> > added media to it and everything looked fine. I added one scene element at a
> > time back and it was all fine until I added in the drip of water I had modeled
> > falling from the downspout. As soon as I added that object back into the scene,
> > the transparent box with media became a reflective mirror instead!
> >
> > The drip of water is modeled as a quartic. It had a material to look like
> > water, (so transparent, ior 1.33, reflective, etc.). When I changed the
> > material to just a simple gray pigment, the media box was no longer visible or
> > reflective, but the media also disappeared.
>
> Unsure...
>
> What version of POV-Ray is being used?
>
I am using the latest 3.8 beta.
> Are the shapes involved part of the same union or merge?
My scene, as is my usual practice, is a single union of all of the individual
objects in the scene.
>
> The only obvious thing I can think of would be if the water material was
> defined by name and happened to have the same name as the one used for
> the media box - and the water material definition was seen last.
>
The material for the media box was defined inline with the box declaration, so
there could be no name collision.
> If you can get a simpler scene showing the issues I'll add it to my
> collection for debug, though no promises as to when I'd dig. I've been
> busy with other than POV-Ray of late.
>
I will play around with it and see if I can find something simple and
repeatable. I had the scene down to just a few elements, but there are a lot of
my own include files involved, so it will take a bit to try and reproduce it.
> --- Deeper and less likely possibility...
>
> With some older shape types - due ill advised automatic polynomial order
> reduction code combined with the lack of tight automatic / manual
> bounding for some shapes - we sometimes end up with an additional root
> (and so another surface) being introduced(a) by the auto-order reduction
> itself.
>
> Maybe something like this is going on but, that surface by order
> reduction would have to have a very particular position to see the
> results you posted.
>
> A test for this fail would be to change your quartic to a simple sphere
> or similar and see if the apparent reflection propagation to the box
> problem persists?
>
> (a) - One of the shipped scenes long has had a vertical line in the
> result due the auto-order reduction changing two roots (4th order eqn)
> to three roots (third order eqn) for one or more of the scene's shapes.
> I cannot remember which it is for sure - primitiv.pov maybe? The povr
> branch fixed this particular exposure(b) by ripping out the automatic
> order reduction code.
>
> (b) - Order reduction introduces slight root/surface shifts in the
> intended roots even when it mostly works in a consistent way. The
> reduction code also sometimes flips 'sturm on' to fixed solvers, without
> notice due the order reduction, on a per ray->surface equation basis.
> The sturm vs fixed solver results for identical equations are often not
> themselves identical and this occasionally introduce at same surface,
> subtle, consistency issues - which are sometimes visible. And there's
> more 'solver noise' possible due the order reduction I won't detail -
> partly because I no longer remember all the possible implications!
>
> Bill P.
Thanks, if I can find some time to reproduce the problem with a simple example
I'll post it. Would you prefer it in bug reports, sources, or here in the
images newsgroup?
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/23/22 22:33, Chris R wrote:
> Would you prefer it in bug reports, sources, or here in the
> images newsgroup?
Either OK for me. For future reference a post to bug reports with some
sort of pointer or mention of this thread in binary images is likely
better.
---
Given you do put everything into a scene union, it'd be worth trying a
render where you include the transparent box at outside the union. You'd
do this by commenting your box ID reference or raw box code inside the
union and then include the box code as you posted it at the bottom of
your scene file. (Supposing no transforms on the union itself)
Trying something other than a quartic for the spout water drop would
tell us something too. I've run across some quartic specific code
somewhere - csg code perhaps...
Alain's idea about coincident surfaces as a cause is one scenario in my
head for an extra surface(a) due order reduction causing trouble, but
the image doesn't look quite right for it to me. However, if your wall
texture itself mirrors across the ground plain who knows...
(a) - In it, the additional order reduction surface - you might not know
you have - becomes the one of the coincident surfaces.
Hmm, Have you tried a render where you remove the reflection block from
finish block of the spout water drop?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/06/2022 6:46 pm, Chris R wrote:
.......
>
> Any ideas? It's driving me crazy
>
> -- Chris R.
Try: finish{phong 0}
Solved a similar problem for me.
m@
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/23/22 22:33, Chris R wrote:
> > Would you prefer it in bug reports, sources, or here in the
> > images newsgroup?
>
> Either OK for me. For future reference a post to bug reports with some
> sort of pointer or mention of this thread in binary images is likely
> better.
>
> ---
> Given you do put everything into a scene union, it'd be worth trying a
> render where you include the transparent box at outside the union. You'd
> do this by commenting your box ID reference or raw box code inside the
> union and then include the box code as you posted it at the bottom of
> your scene file. (Supposing no transforms on the union itself)
>
> Trying something other than a quartic for the spout water drop would
> tell us something too. I've run across some quartic specific code
> somewhere - csg code perhaps...
>
> Alain's idea about coincident surfaces as a cause is one scenario in my
> head for an extra surface(a) due order reduction causing trouble, but
> the image doesn't look quite right for it to me. However, if your wall
> texture itself mirrors across the ground plain who knows...
>
> (a) - In it, the additional order reduction surface - you might not know
> you have - becomes the one of the coincident surfaces.
>
> Hmm, Have you tried a render where you remove the reflection block from
> finish block of the spout water drop?
>
> Bill P.
I was able to create a simple example with the same problem and posted it in the
bug reports news group:
http://news.povray.org/povray.bugreports/thread/%3Cweb.62b9bd71ec325a4a89a9c4065cc1b6e@news.povray.org%3E//povray.bugre
ports/thread/%3Cweb.62b9bd71ec325a4a89a9c4065cc1b6e@news.povray.org%3E/
In the example, I removed the outer union of all objects in the scene and the
bug remained. I was also able to remove the normal and finish elements of the
water drip without changing the results. Removing the interior { ior 1.33 },
however, caused both the drip and the box to disappear from the scene.
Also, the test scene has the box resting 0.1 units above the ground plane, so
there shouldn't be any coincident surfaces.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 24-6-2022 om 09:20 schreef William F Pokorny:
> [snip]
> Trying something other than a quartic for the spout water drop would
> tell us something too. I've run across some quartic specific code
> somewhere - csg code perhaps...
>
> [snip]
>
Replacing the quartic object by a sphere{} solves the problem, so it
definitely seems to be a quartic problem to me.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/28/22 07:54, Thomas de Groot wrote:
> Op 24-6-2022 om 09:20 schreef William F Pokorny:
>> [snip]
>> Trying something other than a quartic for the spout water drop would
>> tell us something too. I've run across some quartic specific code
>> somewhere - csg code perhaps...
>>
>> [snip]
>>
>
> Replacing the quartic object by a sphere{} solves the problem, so it
> definitely seems to be a quartic problem to me.
>
Chris & Thomas,
Thank you for the test scene and experimental feedback.
I'm busy for 2-3 days or so. It will be a while until I can dig into the
issue.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.06.2022 um 15:07 schrieb William F Pokorny:
> On 6/28/22 07:54, Thomas de Groot wrote:
>> Op 24-6-2022 om 09:20 schreef William F Pokorny:
>>> [snip]
>>> Trying something other than a quartic for the spout water drop would
>>> tell us something too. I've run across some quartic specific code
>>> somewhere - csg code perhaps...
>>>
>>> [snip]
>>>
>>
>> Replacing the quartic object by a sphere{} solves the problem, so it
>> definitely seems to be a quartic problem to me.
>>
>
> Chris & Thomas,
>
> Thank you for the test scene and experimental feedback.
>
> I'm busy for 2-3 days or so. It will be a while until I can dig into the
> issue.
>
> Bill P.
I took a short look into this issue only. Most likely the interaction
between the quartic and the water material is a problem. If you exchange
material { water_material }
with
pigment { colour Red }
within the Grip-object in the demo scene, Chris gave in the bugs report
section, the problem do not show up.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
