On 12/18/23 14:53, William F Pokorny wrote:
> I'll dig a more into the code - really not much of it in truth. There is 
> a dynamic_cast used in one of the conditional test which is why I wanted 
> to be sure windows binaries behaved the same way.
> 
> ---
> There is this bit too in the documentation which I don't currently see 
> any code for:
> 
> "If the parent object is a CSG of objects with different textures, then 
> the textures on overlapping parts will be averaged together."
> 
> but maybe somehow 'averaging' happens... The test case in this thread 
> isn't set up to trigger it. Guess, I'll need to create more complex 
> cases. My guess at the moment is we'll get, not 'averaging', but 
> multiple individual textures (including any texture lists) from the 
> parent's component parts.

Using more or less the same set up, but with union{}s in the 
intersection and difference.

With cutaway_textures where the intersection{} and difference{} blocks 
themselves don't have textures, the results are different than when the 
input is not the CSG union. :-(

And in the difference case I now do see some sort of 'maybe averaging' 
happening though I'm unsure of what textures/texture-components; nor do 
I have a clue how it's happening internal to POV-Ray at the moment.

The testing combinations explode in number from here :-(


I wonder if I can make intersections and differences using 
cutaway_textures without a dedicated block texture illegal in yuqk and 
just walk away carrying my bag of blissful ignorance...

Bill P.


Intersection                    | Difference
------------                    | ------------
                                 |
        CSG       CSG            |        CSG       CSG
BCRG   Surface   Surface        | BCRG   Surface   Surface
-----|---------|----------|---| | -----|---------|----------|---|
0000   DfltPig   DfltPig    =   | 0000   DfltPig   DfltPig    = ==
0001   Green     DfltPig    =   | 0001   Green     DfltPig    = ==
0010   DfltPig   Red        =   | 0010   DfltPig   Red        = ==
0011   Green     Red        =   | 0011   Green     Red        = ==
0100   DfltPig   DfltPig    =   | 0100   DfltPig   DfltPig    = ==
0101   Green     DfltPig    .   | 0101   Green     Gre+Ave    . ??
0110   DfltPig   Red        =   | 0110   DfltPig   Red        = ??
0111   Green     Red        =   | 0111   Green     Red        = ==
1000   Blue      Blue       =   | 1000   Blue      Blue       = ==
1001   Green     Blue       =   | 1001   Green     Blue       = ==
1010   Blue      Red        =   | 1010   Blue      Red        = ==
1011   Green     Red        =   | 1011   Green     Red        = ==
1100   Blue      Blue       =   | 1100   Blue      Blue       = ==
1101   Green     Blue       =   | 1101   Green     Blue       = ==
1110   Blue      Red        =   | 1110   Blue      Red        = ==
1111   Green     Red        =   | 1111   Green     Red        = ==

(*) - The Red, Green and Blue in the table above are really similar 
unique colors for each element of the union{}s.

Post a reply to this message

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

> There is this bit too in the documentation which I don't currently see
> any code for:
>
> "If the parent object is a CSG of objects with different textures, then
> the textures on overlapping parts will be averaged together."
>
> but maybe somehow 'averaging' happens... The test case in this thread
> isn't set up to trigger it. Guess, I'll need to create more complex
> cases. My guess at the moment is we'll get, not 'averaging', but
> multiple individual textures (including any texture lists) from the
> parent's component parts.
>

It's interesting that you should mention this topic. *Many* years ago (2009), I
had a 'discussion' in the newsgroups with long-time user Warp-- actually an
argument :-( -- as to what we *should* see when using cutaway_textures re:
'averaging'. Even Clipka chimed in, in a more reasonable way. I don't recall my
exact thinking or frame of mind at the time, but I'm sure that I made some
logical errors in my side of the argument. (Warp and I had a sort of
antagonistic approach to one another at the time, but he is a very smart guy,
with a sharp mind. I haven't seen him in the newsgroups for years, sadly.)
Anyway, here it is...warts and all...

https://news.povray.org/povray.newusers/thread/%3Cweb.4a13ff1fd9818dbeab6e42900%40news.povray.org%3E/?mtop=310905

Maybe there is a germ of an idea somewhere in that discussion that will be of
use.

FWIW, I am currently using the cutaway_textures feature in my long-overdue
object-slicing-to-3D-printing scheme (via the 3D SLICER CT-scan app)... and I
*still* had to experiment with it to find the best approach.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
 https://news.povray.org/povray.newusers/thread/%3Cweb.4a13ff1fd9818dbeab6e42900%40news.povray.org%3E/?mtop=310905
>
> Maybe there is a germ of an idea somewhere in that discussion that will be of
> use.

Yes, maybe if you reread that, you'll see where you don't understand their
point.

I don't exactly understand clipka's example but...


One way to address the color selection would be to allow the optional inclusion
of a hierarchical index in the cutaway_textures call.   No index averages the
colors as is currently the default behaviour.  Supplying an index allows the
user to choose some texture in whatever texture hierarchy that POV-Ray
constructs, up to the max.   So, if there are only 2, and you supply 20, then
it's texture #2.

Thinking about clipka's point about other software packages, I suppose it would
be useful to have a macro called Union () that differences away one object from
another before creating a union {} of them, thereby conveniently eliminating the
problem in the first place.

I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  Like adding a bit of f or t in the cutting
object's texture to act as a filter to view the final surface through to modify
the final cutaway_texture result, or applying a faint amount of dye in the
cutter to tint the surface.   That would be useful indeed.

And truly, I think it would be as simple as adding the cutting object's texture
into the averaged result.  Since enabling that would require a flag of some
sort, and a source-rewrite / new keyword or optional auxiliary keyword (like
sturm), then you would just supply a weighting for the cutting object's
contribution to the average.

(And this is written knowingly full well what "just" entails  ;) )

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Yes, maybe if you reread that, you'll see where you don't understand their
> point.

I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
now fully understand their point and where I was wrong. My basic assumption back
then was...naive and rather uninformed :-\

William's comments about cutaway_textures induced me to go back to an *old* test
file I made at the time, and update it... while discovering some additional
interesting things. I've included that scene below, with updated comments. The
various code pieces are worth playing around with, to see what happens.

Some salient points:
Cutaway_textures can only be used in a 'difference' or 'intersection', and both
behave the same way regarding it.

Given a complex CSG object with lots of overlapping parts and overlapping
individual textures/colors: When cutaway_textures is used as the final step, the
colors end up being 'averaged' at the surface(s) when the overall object is
sliced into with a difference or intersection. (This assumes that the slicing
object has NO specifically-applied texture of its own, which is an important
point.) The averaging makes sense, because at present there is no way for
POV-ray to know *which* of the overlapped/nested objects should contribute its
own 'pure' color at that surface; the big slicing surface may intersect any
number of differently-colored and overlapping objects. Luckily, the UN-textured
slicing object does not impose its own color on those surfaces...but will if
given a 'specified' texture of its own.

(I find it interesting-- and useful!-- that the un-textured object behaves this
way, even though it does have a default texture applied 'behind-the-scenes'. Why
it does not impose that on the cut surfaces is a mystery to me. But it's a happy
circumstance!)
>
> One way to address the color selection would be to allow the optional
> inclusion of a hierarchical index in the cutaway_textures call.   No index
> averages the colors as is currently the default behaviour.  Supplying an
> index allows the user to choose some texture in whatever texture
> hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> and you supply 20, then it's texture #2.

Ah yes-- and that would have been the solution to my old argument too!
Well-explained, laddie.

> I do very much like your suggestion of the partial contribution of the cutting
> object's texture to the surface.  Like adding a bit of f or t in the cutting
> object's texture to act as a filter to view the final surface through to
> the final cutaway_texture result, or applying a faint amount of dye in the
> cutter to tint the surface.   That would be useful indeed.

That can be done even now. :-) It's part of my code test.
>
> And truly, I think it would be as simple as adding the cutting object's
> texture into the averaged result.

Exactly.

--------------
#version 3.8;
global_settings{assumed_gamma 1.0 max_trace_level 40}
#default{finish{ambient .05 emission 0 diffuse .85}}

camera {
  perspective
  location  <1, 2, -5>
  look_at   <0, -.3,  0>
  right x*image_width/image_height
  angle 40
}

// It is difficult to arrange the lighting here, to show the various
// results well.

light_source {
  0*x
  color rgb .6
  translate <-10, 15, -30>
}

light_source {
  0*x
  color rgb <1,1,1>*.33
  translate <20, -10, -40>
}

light_source {
  0*x
  color rgb <1,1,1>*.63
  translate <40, 20, 0>
}

background{rgb .1}

#declare S1 = seed(3); // for the objects' colors -- try 12 and 25 too
#declare S2 = seed(10); //for object creation and placement-- try 5, 6,
// and 10 too
#declare counter = 1;

difference{ // difference. For the cutaway box at end. But try intersection
// instead.
 union{ // try merge instead
 #while(counter <= 10)
 box{0,1 translate -.5
  texture{
   pigment{color srgb <rand(S1),rand(S1),rand(S1)>}
         }
  // an experiment...
  interior_texture{ pigment{bozo scale .15}}

  translate 1.3*<rand(S2) - .5,rand(S2) - .5,rand(S2) - .5>
    }

 cylinder{-1.8*x,1.8*x,.08
  texture{
   pigment{color srgb <rand(S1), rand(S1), rand(S1)>}
    }

  // an experiment...
  interior_texture{ pigment{gradient x frequency 20}}

  translate 1.5*<0,1.3*(rand(S2) - .5),rand(S2) - .5 -.1>
    }
 #declare counter = counter + 1;
 #end
  rotate 30*y
 } // end of merge


// === The cutting object ===... with NO applied texture, OR with various
// others. Assuming that a DIFFERENCE is used above:
// When NO initial texture is applied here:
//          1) with cutaway_textures missing, this
//             box applies its default WHITE color to the cut surfaces
//             (it used to be black when I originally wrote this code in 2009
//             in an older version of POV-ray.)
//          2) With cutaway_textures APPLIED, all of the original object
//             textures get blended or averaged together.
// When a totally *transparent* texture is applied below:
//          1) with cutaway textures missing, you can see INSIDE the many
//             cutaway objects as HOLLOW with thin walls, with all of the
//             objects' original colors NON-averaged. The COLOR of the
//             transparent texture is not used either.
//             HOWEVER, if the original objects have an inside_texture,
//             *that* texture shows up on the inside surfaces.
//             Good for cutaway diagrams!
//          2) With cutaway_textures applied, it has no visual effect; same
//             as if not applied.
// When a partially-transparent texture is applied:
//          1) with cutaway_textures missing, it's hard to tell what happens--
//             perhaps the look is partially 'hollow' and partially non-hollow,
//             with the texture's color partially applied to the half-visible
//             slicing walls. But no 'averaging' of the original objects'
//             colors occurs.
//          2) with cutaway textures applied, no difference; same as if not
//             applied.

// The differenced box:
box {0,2
 // optional, for experimentation...
 //texture{pigment {color srgbt <0,1,0,1>}} // fully transparent
 // OR, another optional experiment...
 //texture{pigment{srgb 1}}
 // AND/OR, another optional experiment...
 //texture{pigment{srgbt <1,.1,1,.6>}} // partially transparent

 /*
 // and/or a third experiment...it does not seem to show up...
 interior_texture{ // NEEDS a specified regular texture first--
                          // otherwise fatal parse error: "interior_texture
                          // requires an exterior texture"
  pigment{
   gradient y frequency frame_number
    color_map{
     [.5 srgb <0,0,1>]
     [.5 srgb <1,1,0>]
        }
    }
  finish{ambient .4 emission 0 diffuse .6}

       }
 */
  rotate 45*y
  translate <-1.4,-.4,-1.2>
  }  // end of box

 cutaway_textures
 //rotate 180*y
}

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > I do very much like your suggestion of the partial contribution of the
> > cutting
> > object's texture to the surface.  Like adding a bit of f or t in the cutting
> > object's texture to act as a filter to view the final surface through to
> > the final cutaway_texture result, or applying a faint amount of dye in the
> > cutter to tint the surface.   That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.
>
{snip]
> // When a partially-transparent texture is applied:
> //          1) with cutaway_textures missing, it's hard to tell what happens--
> //             perhaps the look is partially 'hollow' and partially non-
//               hollow,
> //             with the texture's color partially applied to the half-visible
> //             slicing walls. But no 'averaging' of the original objects'
> //             colors occurs.

Hmm, it does not work like I thought, for the reason given. The interiors of the
many objects ARE partially visible, as is the partially-transparent slicing
surface. A mix of the two.

Post a reply to this message

On 12/19/23 03:32, Kenneth wrote:
> It's interesting that you should mention this topic.*Many*  years ago (2009), I
> had a 'discussion' in the newsgroups with long-time user Warp

Thanks for the pointer. I read through it. I'll say my up front concern 
isn't really the averaging(a,b,c) when it comes into play, but rather 
that with relatively simple test cases for the cutaway_textures I found 
bugs and instability in behavior depending on the kind of inputs given 
to the intersection{} and difference{} blocks. Maybe the 'bug' mentioned 
in that 2009 thread compared to v3.6 didn't get fixed - or didn't get 
fixed completely?

(a) - Relative to the specific averaged texture discussion in that 
thread, the yuqk fork introduced a list_object{} pattern for pretty much 
the situation discussed. It allows the user to specify a list of objects 
for a patterned / *_map texture in a last one wins order. In other 
words, the user selects which texture wins in overlapping regions.

(b) - The averaging method provides a way to generate a texture when 
there are object overlaps, but the result is clunky I think; as in not 
being actually useful except to provide 'some' texture result indicating 
overlapping regions. In what I've seen so far you get bits that are 
averaged and bits not, depending on overlaps. If all we are after is 
some special effect - like image transitions in an animation or 
something - the set up could be useful.

(c) - I still haven't unrolled completely how the averaging gets done in 
our code. What concerns me some is the inside tests. These are sometimes 
very expensive. Even fast ones will be costly if there are huge numbers 
of shapes in the input CSG objects to the intersection / difference 
(really a modified intersection).

Anyhow, see the image and yuqk scene file(d) for the list_object{} 
pattern approach as a cutaway_textures alternative - one also with 
limitations.

(d) - I played very briefly with cutaway_textures in this file too and 
it seemed like the behavior was different yet again (ignored sometimes 
where not previous...?), but I didn't dig into it.

Bill P.

Post a reply to this message

Attachments:
Download 'list_object.png' (51 KB) Download 'list_object.pov.txt' (3 KB)

Preview of image 'list_object.png'

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Yes, maybe if you reread that, you'll see where you don't understand their
> > point.
>
> I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
> now fully understand their point and where I was wrong. My basic assumption back
> then was...naive and rather uninformed :-\

I feel the same way when I read my posts going back to 2013.  <oof>
> Luckily, the UN-textured
> slicing object does not impose its own color on those surfaces...but will if
> given a 'specified' texture of its own.
>
> (I find it interesting-- and useful!-- that the un-textured object behaves this
> way, even though it does have a default texture applied 'behind-the-scenes'. Why
> it does not impose that on the cut surfaces is a mystery to me. But it's a happy
> circumstance!)

Well, if I had to speculate, it would be that there is a difference between a
primitive and an object.  We can define things as primitives, but the default
texture may not actually get assigned to them until we invoke them as visible
objects to be rendered in a scene, perhaps using object {}.

And honestly, I'd call the fact that a textured object can't be used as the
"cutter" without imparting its assigned texture to the intersection surface,
even when cutaway_textures is invoked, either a bug, or at least unexpected or
undesired behaviour.
So if I want to model a complex CSG object that I want to see in the scene, but
also use as a differencing cutter, I have to model it TWICE?
I would think that cutaway_textures should simply ignore all of the assigned
texturing of the cutter, since that's its conceptual function - to use the
textures of the cut object for the remaining surface, not those of the cutter.

> > One way to address the color selection would be to allow the optional
> > inclusion of a hierarchical index in the cutaway_textures call.   No index
> > averages the colors as is currently the default behaviour.  Supplying an
> > index allows the user to choose some texture in whatever texture
> > hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> > and you supply 20, then it's texture #2.
>
> Ah yes-- and that would have been the solution to my old argument too!
> Well-explained, laddie.
>
> > I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  ..
. That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.

I copied and rendered the code, since The Naughty Walker didn't attach the scene
as a .pov file.  :P

> > And truly, I think it would be as simple as adding the cutting object's
> > texture into the averaged result.
>
> Exactly.

Wait, wha...?   We agree?
To quote Phil Collins, "There must be some misunderstanding...."  ;)

- BW

Post a reply to this message

So, my waking brain was just meandering over this topic, and I was wondering:

We have the object pigment pattern feature, and we have cutaway_textures.

How difficult would it be to implement a sort of hybrid feature?

Consider I have a base object, and I want to "intersect" it with another object,
but not do a CSG - rather leave the "imprint" of the other object on its
surface.

I suppose this is the object pattern, but with a different, simpler syntax,
perhaps leveraging whatever existing algorithmic processes exist under the hood
for cutaway_textures.

If I were to start intersecting the base object with a loop of random spheres
with random pigments, then the final result would either be the average of all
the overlapping spheres' pigments on the surface of the base object, or the
last-intersected sphere's pigment would take precedence, sort of like a
z-buffer/painter's algorithm.

Just an idea to throw out there.

- BW

Post a reply to this message

On 2023-12-18 11:16 (-4), William F Pokorny wrote:
> While continuing to think about yuqk / v4.0 texturing clean up /
> changes, I took a detailed look at cutaway_textures.
> 
> I'm pretty sure the 0110 difference case below should end up as 'Red
> Red'. The nullptr result for the pigment I see as a bug itself in any
> case - the pigment should end up set to something valid.
> 
> The behavior is identical v3.7-stable, v3.8 beta 2 and yuqk on linux.
> 
> Do windows users see the same bug?

I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
multi-texture CSG object."

Post a reply to this message

On 12/22/23 08:29, Cousin Ricky wrote:
> I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
> POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
> multi-texture CSG object."

Thanks! :-) I wondered what might be happening in earlier versions but 
was too lazy to run it.

I was considering adding a render time error to yuqk too as something 
better than what is happening. However, I believe I've worked out a 
relatively simple fix.

In the file csg.cpp and the function CSG::Determine_Textures, change the 
line:

     if (Type & CSG_DIFFERENCE_OBJECT)

to

     if ((Type & CSG_DIFFERENCE_OBJECT) &&
         (children[0]->Texture != nullptr))

This aligns the results with those of intersection{} where the first 
object in the difference has no texture - and we are using cutaway_textures.

I've also worked up some yuqk documentation which goes as far as my 
current understanding of cutaway_textures goes. I'll stick the top part 
of that documentation below.

Bill P.


---
cutaway_textures

A modifier used with intersection and difference to tweak texturing

The keyword can only be used with a difference{} or intersection{} block.

The cutaway_textures is specified with no arguments.

The cutaway_textures keyword is useful ONLY where more than one, but not 
all of the objects in an intersection{} or difference{} blocks have no 
texture and there is no texture specified in the parent intersection{} 
or difference{}.

The keyword can always be used in any difference{} or intersection{} 
block, but as a rule, never do this where the keyword is not useful as 
it triggers extra work during ray tracing / rendering.

---
Useful things to remember when trying to understand cutaway_textures 
results.
---

0) If none of the input objects have textures, the parser will assign 
the current default texture to everything and cutaway_textures will have 
no effect.  This action of the parser can occur during a chain of csg / 
object {} block wraps prior to the difference{} / intersection{} blocks. 
In other words, it helps to keep the inputs - especially the 'cutting 
shape' - simple when attempting to use cutaway_textures.

1) If all input objects have textures, cutaway_textures will have no effect.

2) If the difference{} or intersection{} blocks themselves have a 
texture specified, cutaway_textures will have no effect.

3) Where the inputs are simple single objects (sphere, cone, etc) and 
one or more of the inputs (as seen by the current ray) is not textured, 
but one of the inputs is, use of cutaway_textures will result in the 
copying of of the other input's texture. This can vary, if the input 
object's texture vary.

4) Where the inputs are multiple, simple objects as with a csg input the 
resulting texture from the 'cut' will be an average of all the textured 
components - as seen by the current ray and determined by inside object 
tests.  (Yes, cutaway_textures can get expensive)

5) During parsing and internal to POV-Ray the cutaway_textures keyword 
prevents the copying of the default texture, leaving the texture pointer 
set to nullptr.  It further sets a cutaway_textures flag on those shapes 
with no texture as well on the parent intersection{} or difference{}. At 
render time and for each ray interacting with components having the 
cutaway_textures flag and no texture, extra work gets done to determine 
a resulting texture.

6) The direct inputs being a union{} or merge{} makes no difference. 
Less sure about uses of merge{} in csg chains coming into the 
difference{} / intersection{} blocks.

7) What happens with nested difference{} and intersection{} blocks using 
cutaway_textures in other difference{} and intersection{} blocks also 
using cutaway_textures was not explored - and unsure what happens.

Post a reply to this message