Hello all,

this is my first time posting here, even though I've been using POVRay on and
off for quite a few years. I'm currently using version 3.7 as shipped by Debian
(sid), I believe I have a found a configuration where the no_image tag is
ignored for a union member when the union itself is inside a difference. A repro
is the following:

--- 8< -----

#version 3.7;

#include "colors.inc"

#declare Wall = box {
 <-100, 0, 0>
 < 100, 100, 5>
}

#declare Pair = union {
 object { Wall translate 100*z no_image on }
 object { Wall translate 200*z }
}

difference {
 object { Pair }
 box { <0, 0, 0> <0, 0, 0> }
 pigment { color White }
}

light_source {
 <200, 200, -10>
 color White
}

camera {
 location <0, 200, 0>
 look_at  <0, 100, 100>
}


--- 8< -----


illustrate the odd behavior: both walls are rendered. Replacing the `difference`
with a direct use of the object `object { Pair pigment { color White } }` works
as expected, as does using a union instead of a difference (in both cases, a
single wall is visible, albeit with a shadow cast from the other, invisible
wall).

I'm not entirely sure if this behavior is expected or a bug. In the latter case,
should I open a GitHub issue?

Best regards and thanks for your patience,

Oblomov

Post a reply to this message

On 3/23/20 7:20 PM, Oblomov wrote:
> Hello all,
...
> 
> The `difference` is intentionally ‘useless’, since it's only supposed to
> illustrate the odd behavior: both walls are rendered. Replacing the `difference`
> with a direct use of the object `object { Pair pigment { color White } }` works
> as expected, as does using a union instead of a difference (in both cases, a
> single wall is visible, albeit with a shadow cast from the other, invisible
> wall).
> 
> I'm not entirely sure if this behavior is expected or a bug. In the latter case,
> should I open a GitHub issue?
> 

Hi,

I believe what you see is expected behavior - though not sure it's 
anywhere documented(1). What happens for an end result with no_image and 
similar object modifiers can get complicated.

Object modifiers like no_image don't - generally - propagate through csg.

That said, union is a special case because shapes withing the unions are 
flattened / unnested to the top and bounding is applied to each 
component there. Further, unions don't potentially 'ignore' surfaces.

You can code up a difference as difference { Pair pigment...} and that 
should work because the parser, IIRC, basically ignores the difference 
creating a top level object which in turn is the flattened union. And 
I'm not sure why this one, odd difference encoding works...

It could be argued your particular difference with a null box is the 
same thing, but handling all the sorts of situations where this might be 
true in csg generally is probably never going to happen - and I don't 
think there is much point trying to make it work.

The aim for the no_image et al qualifiers is for them to be used on 
complete things at the scene level - trees or whatever.

Bill P.

(1) - With respect to documentation, it might be worth posting a pointer 
to this thread in povray.documentation.inbuilt asking if deeper 
documentation related to the propagation of object qualifiers exists - 
and I've missed it. If not, whether some such documentation should be 
added to the inbuilt documentation. Jim - who currently handles all 
documentation - should at some point see it.

Post a reply to this message

Hello,
and thanks for taking time to look into this and provide an explanation:

William F Pokorny <ano### [at] anonymousorg> wrote:

> > illustrate the odd behavior: both walls are rendered. Replacing the `difference`
> > with a direct use of the object `object { Pair pigment { color White } }` works
> > as expected, as does using a union instead of a difference (in both cases, a
> > single wall is visible, albeit with a shadow cast from the other, invisible
> > wall).
> >
> > I'm not entirely sure if this behavior is expected or a bug. In the latter case,
> > should I open a GitHub issue?
> >
>
> Hi,
>
> I believe what you see is expected behavior

I was actually hoping for this to be a bug, since achieving the same effect will

to be able to define a Room object with all the walls and floors and ceilings

guess now I'll have to build the rooms without the see-through wall at all and
then add it (with the no_image tag) as a separate object. I guess I'm lucky I
don't need to operate complex transformations on the rooms themselves, so this
will be relatively easy.

> - though not sure it's
> anywhere documented(1). What happens for an end result with no_image and
> similar object modifiers can get complicated.

> Object modifiers like no_image don't - generally - propagate through csg.

Hm, I'm guessing the problem is deciding what to do for the subvolumes
intersection of components with different attributes: do you take the union of
the attributes there, or their intersection? E.g. in the documentation examples,
assume one sphere is no_image and the other is not; do you show the volume
corresponding to the intersection because at least one has no_image off, or do
you hide it because at least one has no_image on? I can see why both would be
acceptable answers depending on what the user wants, and thus the developers may
have opted for essentially ignoring the attribute for the single component.

> That said, union is a special case because shapes withing the unions are
> flattened / unnested to the top and bounding is applied to each
> component there. Further, unions don't potentially 'ignore' surfaces.
>
> You can code up a difference as difference { Pair pigment...} and that
> should work because the parser, IIRC, basically ignores the difference
> creating a top level object which in turn is the flattened union. And
> I'm not sure why this one, odd difference encoding works...
>
> It could be argued your particular difference with a null box is the
> same thing, but handling all the sorts of situations where this might be
> true in csg generally is probably never going to happen - and I don't
> think there is much point trying to make it work.

Well, my actual code is much more complicated than just a difference with a null
box, but even in that case I was actually expecting it to work, since at least

of intersections and merges.

> (1) - With respect to documentation, it might be worth posting a pointer
> to this thread in povray.documentation.inbuilt asking if deeper
> documentation related to the propagation of object qualifiers exists -
> and I've missed it. If not, whether some such documentation should be
> added to the inbuilt documentation. Jim - who currently handles all
> documentation - should at some point see it.

I'll do it, thanks for the hint.

Post a reply to this message

hi,

"Oblomov" <nomail@nomail> wrote:
> ...
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > > ...
> > I believe what you see is expected behavior
>
> I was actually hoping for this to be a bug, since achieving the same effect will

> to be able to define a Room object with all the walls and floors and ceilings


can you not do that using two different textures?


regards, jr.

Post a reply to this message

Le 2020-03-24 à 09:14, Oblomov a écrit :
> Hello,
> and thanks for taking time to look into this and provide an explanation:
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>> The `difference` is intentionally ‘useless’, since it's only supposed to
>>> illustrate the odd behavior: both walls are rendered. Replacing the `difference`
>>> with a direct use of the object `object { Pair pigment { color White } }` works
>>> as expected, as does using a union instead of a difference (in both cases, a
>>> single wall is visible, albeit with a shadow cast from the other, invisible
>>> wall).
>>>
>>> I'm not entirely sure if this behavior is expected or a bug. In the latter case,
>>> should I open a GitHub issue?
>>>
>>
>> Hi,
>>
>> I believe what you see is expected behavior
> 
> I was actually hoping for this to be a bug, since achieving the same effect will
> require me to restructure the source in a somewhat «illogical» way: I was hoping
> to be able to define a Room object with all the walls and floors and ceilings
> and holes in them, and make one of the walls “see-through” for the camera. I
> guess now I'll have to build the rooms without the see-through wall at all and
> then add it (with the no_image tag) as a separate object. I guess I'm lucky I
> don't need to operate complex transformations on the rooms themselves, so this
> will be relatively easy.
> 

For that «see through» wall : You can replace that wall with a polygon 
and give it a regular texture and an inside_texture with pigment{rgbt 1}.

When seen from the front, you see the normal texture, but, when seeing 
it from the back, it will be perfectly transparent.

Another way would be to define your room as a mesh with an 
inside_vector. You then give it : pigment{rgbt 1} and an 
interior_texture with the texture for the walls.

That way, when the camera is inside the room, everything will look 
normal, but, when the camera is outside, the walls facing the camera 
will be invisible.

Not perfect as lights that are outside of the room will see the 
transparent part and shine through.

Post a reply to this message

On 3/24/20 8:05 AM, William F Pokorny wrote:
> (1) - With respect to documentation, it might be worth posting a pointer 
> to this thread in povray.documentation.inbuilt asking if deeper 
> documentation related to the propagation of object qualifiers exists - 
> and I've missed it. If not, whether some such documentation should be 
> added to the inbuilt documentation. Jim - who currently handles all 
> documentation - should at some point see it.

well i'd agree that the noted behavior /appears/ to not be documented... 
i did a little more than a cursory search and came up empty. before i 
get to it, i have a couple of questions...is this limited to the 
no_shadow/image/reflection modifiers? if so a couple of notes and/or a 
paragraph should be enough. if it gets more involved than that maybe a 
"pitfalls" sub-section below 3.5.1.5

Post a reply to this message

On 3/25/20 5:52 AM, Jim Holsenback wrote:
> On 3/24/20 8:05 AM, William F Pokorny wrote:
>> (1) - With respect to documentation, it might be worth posting a 
>> pointer to this thread in povray.documentation.inbuilt asking if 
>> deeper documentation related to the propagation of object qualifiers 
>> exists - and I've missed it. If not, whether some such documentation 
>> should be added to the inbuilt documentation. Jim - who currently 
>> handles all documentation - should at some point see it.
> 
> well i'd agree that the noted behavior /appears/ to not be documented... 
> i did a little more than a cursory search and came up empty. before i 
> get to it, i have a couple of questions...is this limited to the 
> no_shadow/image/reflection modifiers? if so a couple of notes and/or a 
> paragraph should be enough. if it gets more involved than that maybe a 
> "pitfalls" sub-section below 3.5.1.5

Yep, the essential question. ;-) I had those three and hollow in my head 
as I responded, but I don't have in hand a definitive list. I avoid 
using non-transform modifiers down in the nesting - excepting inverse.

I've got a little buzzer going off that somewhere in the last few years 
Christoph responded to someone hitting a particular hollow issue with it 
propagating or not as desired. I'll try and find that post.

Quickly thinking. I'd bet photon and radiosity blocks are also not 
always propagating through csg. What others... double_illuminate, hmm...

Anyway, I've promised to do some other stuff first thing this morning. 
I'll come back to this thread later.

Bill P.

Post a reply to this message

On 3/25/20 8:05 AM, William F Pokorny wrote:
> On 3/25/20 5:52 AM, Jim Holsenback wrote:
...
> 
> Anyway, I've promised to do some other stuff first thing this morning. 
> I'll come back to this thread later.
> 

OK.

---
Modifiers are not generally passed from nested objects to a csg 
resultant involving those objects - excepting with unions and there 
excepting unions using 'split_union off'. This is true for:


Keywords:
---------
no_image
no_reflection
no_shadow
no_radiosity
double_illuminate
hollow

Modifier blocks:
----------------
photons {}
radiosity {}


The following are OK if applied to csg components:

Keywords:
-----------------------------------------
all transforms
inverse
bounded_by
clipped_by
cutaway_textures
hierarchy
sturm


------------------------
And then we have interior{} and subsurface{} object/finish block modifiers.

Interiors get attached to the objects where the interior is defined. The 
subsurface{} ended up as part of the finish{} block instead of being 
like other block modifiers - anyone know why? In any case that is part 
of the texture attached to the object. What this means is these two 
object modifiers blocks should propagate with the objects surfaces 
through csg. However.

With interior{} the behavior even propagated will be iffy for overlapped 
interiors/no-interior surfaces. There is basically an interior stack and 
if the interiors are seen out of order or due a difference say by only 
entering or exiting surface we'll get the wrong interior treatments, 
media artifacts and the like. Things might work OK, might not. It's 
complicated and a situation true propagation through csg or not.

With subsurface{} things might work better just thinking about it - 
perhaps why the block is part of finish{}? I tested a difference both 
with and without cutaway_textures and functionally I see correct 
behavior without the cutaway_texture and 'sort of' the right result with 
cutaway_texture. In the later case, the subsurface result doesn't look 
to me to be quite right. With cutaway_textures on, if I add a finish 
block to the sphere cutting into the candle, the region turns white with 
no warnings whatever that's about. As just prior, but adding a candle 
matched pigment I get a result matching the original cutaway_textures 
result. To me the color in the divot is more like what it might be if 
the original candle was being used for the subsurface calculations and 
not the candle with the divot and the thin parts at the lip are pretty 
dark - are subsurface rays jumping through the the thin parts?

So... Suppose with interior{} and subsurface{} I'd summarize as:

-----------
The interior{} and subsurface{}(1) object and finish modifier block 
results, respectively, vary where definitions are part of components 
making up any given csg.


The disclaimer here is I've not created but a half dozen test cases to 
verify behavior. With the no_* and hollow keywords confident without 
testing. Anyway, I think I have the behaviors through csg mostly right...

Bill P.

Post a reply to this message

Le 2020-03-25 à 13:11, William F Pokorny a écrit :

> -----------
> The interior{} and subsurface{}(1) object and finish modifier block 
> results, respectively, vary where definitions are part of components 
> making up any given csg.
> 
> 
> The disclaimer here is I've not created but a half dozen test cases to 
> verify behavior. With the no_* and hollow keywords confident without 
> testing. Anyway, I think I have the behaviors through csg mostly right...
> 
> Bill P.

In the case of subsurface, if the distance between two surface is 
similar or smaller than the translucency value, then, we start to see 
through the object. In a CSG, if the back surface don't have a similar 
translucency, you can expect some unexpected results.

Post a reply to this message

On 3/25/20 1:11 PM, William F Pokorny wrote:
> On 3/25/20 8:05 AM, William F Pokorny wrote:
>> On 3/25/20 5:52 AM, Jim Holsenback wrote:
> ...
>>
>> Anyway, I've promised to do some other stuff first thing this morning. 
>> I'll come back to this thread later.

Thanks Bill and Alain for the input...
When you get a moment please review: 
http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

Post a reply to this message