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

On 3/27/20 8:26 AM, Jim Holsenback wrote:
> 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

http://wiki.povray.org/content/Reference:Object_Modifiers
---------------------------------------------------------

---
Where we start with:

"Some conditions can produce unexpected results."

is there a way to make it a note? "Note..."

---
I don't know looking at the next sentence / list again...

"When applied to CSG components these modifiers work as expected: All 
Transforms, inverse, bounded_by, clipped_by, cutaway_textures, 
Hierarchy, and sturm."

What do you think about striking that sentence and only listing the next 
items that mostly don't get passed through CSG - except where we have 
unions not using split_unions off? I was trying to list things where I 
thought people might wonder whether they make it through CSG, but maybe 
it's just more confusing to do this?

I mean, I didn't list textures{} interior_texture{}, etc mostly because 
I think folks know or quickly learn how those work in CSG. They get 
attached to surfaces and do propagate through CSG except to the extent
those surfaces are seen in the resultant CSG (and cutaway_textures use).

Maybe your first take on a simpler statement with a list for what 
doesn't always make it through CSG is more understandable?

---
We list "Hierarchy" and it doesn't get highlighted with a link perhaps 
due the upper case H ?

---
Perhaps reword the sentence:

"Setting split_union off provides the exception with unions and their 
accepting unions."

as

"CSG unions pass all modifiers listed above unless split_union off has 
been set in which case the later list is ignored as with difference, 
intersection and merge."

---
Could we start a new paragraph before:

"Interiors get attached to the objects where interiors are defined."

Starting that paragraph with:

"While not technically object modifiers, object interior blocks and 
finish subsurface blocks see similar CSG propagation complications. 
Interiors get attached"

---
Where we have:

"In the case of subsurface,"

Perhaps change that to:

"Further, in the case of subsurface, ..."

---
Suppose:

"See also: All Transforms translate, rotate and scale"

technically includes too: matrix and transform{}.

---


Thanks for working on this.

Bill P.

Post a reply to this message

On 3/27/20 9:58 AM, William F Pokorny wrote:
> Thanks for working on this.

you are correct... in this case less is more.

http://wiki.povray.org/content/Reference:Object_Modifiers

Post a reply to this message

On 3/27/20 4:36 PM, Jim Holsenback wrote:
> On 3/27/20 9:58 AM, William F Pokorny wrote:
>> Thanks for working on this.
> 
> you are correct... in this case less is more.
> 
> http://wiki.povray.org/content/Reference:Object_Modifiers
> 
Yes. I think that latest looks good.

My head keeps coming up with more questions about what might and might 
not work. But to test and enumerate all the fringe cases - ugh. And the 
detail would only confuse.

Thanks again.

Bill P.

Post a reply to this message

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

> My head keeps coming up with more questions about what might and might
> not work. But to test and enumerate all the fringe cases - ugh. And the
> detail would only confuse.

Just asking out of curiosity - is there any way to flowchart most of this?
I often have a hard time deciphering the docs - because that's the nature of
documentation and language in general - but when there's a diagram or rendered
code example, to support the text, then it's usually much better.

Perhaps there's some debugging lines that can be inserted into a copy of the
source that will spit out how the stack of CSG onion layers gets "flattened".

Perhaps a simple POV-Ray scene that diagrammatically shows the "before" and
"after"  flattening attributes of CSG components just to illustrate the basic
concept graphically.

Post a reply to this message

On 3/28/20 9:56 AM, Bald Eagle wrote:
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> My head keeps coming up with more questions about what might and might
>> not work. But to test and enumerate all the fringe cases - ugh. And the
>> detail would only confuse.
> 
> Just asking out of curiosity - is there any way to flowchart most of this?

Probably. "It's only a matter of code," as an old work friend would say. :-)

> I often have a hard time deciphering the docs - because that's the nature of
> documentation and language in general - but when there's a diagram or rendered
> code example, to support the text, then it's usually much better.
> 
> Perhaps there's some debugging lines that can be inserted into a copy of the
> source that will spit out how the stack of CSG onion layers gets "flattened".
> 
> Perhaps a simple POV-Ray scene that diagrammatically shows the "before" and
> "after"  flattening attributes of CSG components just to illustrate the basic
> concept graphically.
> 

I'm with you on learning best from examples and diagrams. It's on my 
list to dig more into the bounding / final internal representations 
given I have a list of situations these days where bounding - or lack of 
good bounding - is the largest component of a scenes render time.

I've wanted too, to be able to dump the internal representation after 
parse and bounding, but no idea when I'll get something like that going. 
At the moment focused on the pattern/function cleanup I was working on 
late last year - but now in my cut down version of POV-Ray / povr.

Bill P.

Post a reply to this message

On 3/25/20 8:05 AM, William F Pokorny wrote:
...
> 
> 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.
> 

On my initial search I couldn't find anything, but just now, while 
creating a list of github issues and pull requests my cut down POV-Ray 
addresses or fixes, I ran across:

object hierarchy changes hollow set flag #307

  https://github.com/POV-Ray/povray/issues/307

For reference. Looks like whether and how hollow works or not is change 
v36 to v37 and complicated. Avoiding propagation through CSG still seems 
to me the safest bet.

Bill P.

Post a reply to this message

On 3/29/20 11:44 AM, William F Pokorny wrote:
> On 3/25/20 8:05 AM, William F Pokorny wrote:
> ...
> 
And a few more for the record:

---
Port of FS183 - cutaway_textures broken with child unions
#207

https://github.com/POV-Ray/povray/issues/207

---
Port of FS115 - More cutaway_textures. Difference color inheritance 
wrong. #196

https://github.com/POV-Ray/povray/issues/196

Unsure I agree with the conclusion of others in this one of it being a 
bogus result... This sort of override happens all the time of object {}, 
if a user wants the cutaway_textures to work they should not create a 
new overriding texture - or maybe I'm missing something.

Bill P.

Post a reply to this message