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