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?

Bill P.

//...
default { pigment { rgb <1,1,0> } }
#declare Sph00 = sphere { 0, 0.5 }
#declare Cyl00 = cylinder { -1*y, 1*y, 0.50 }

#declare G =    0;
#declare R =   0;
#declare C =  0;
#declare B = 0;

#declare I00 = intersection {
     object { Sph00
         #if (G) pigment { Green } #end
     }
     object { Cyl00 translate +0.25*z
         #if (R) pigment { Red }   #end
     }
     #if (C) cutaway_textures #end
     #if (B) pigment { Blue } #end
}

#declare D00 = difference {
     object { Sph00
         #if (G) pigment { Green } #end
     }
     object { Cyl00 translate -0.5*z
         #if (R) pigment { Red }   #end
     }
     #if (C) cutaway_textures #end
     #if (B) pigment { Blue } #end
}

object { I00 translate -0.6*x }
object { D00 translate +0.6*x }
//...

=============

Default texture's pigment (DfltPig).

Intersection                    | Difference
------------                    | ------------
                                 |
        Sphere    Cylinder       |        Sphere    Cylinder
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     Green      =   | 0101   Green     Green      =
0110   Red       Red        .   | 0110   Nullptr   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        =

Post a reply to this message

On 12/18/23 10:16, William F Pokorny wrote:
> Do windows users see the same bug?

Sorry, the top part of the scene was missing.

     #version 3.8;
     global_settings {
         assumed_gamma 1 }
     #declare Grey50 = srgb <0.5,0.5,0.5>;
     background { Grey50 }
     #declare Camera00 = camera {
         perspective
         location <3,3,-3.001>
         sky y
         angle 35
         right x*(image_width/image_height)
         look_at <0,0,0>
     }
     #declare Red = srgb <1,0,0>;
     #declare Green = srgb <0,1,0>;
     #declare Blue = srgb <0,0,1>;
     #declare White = srgb <1,1,1>;
     #declare Light00 = light_source { <50,150,-250>, White }
     default { pigment { rgb <1,1,0> } }
     camera { Camera00 }
     light_source { Light00 }

and to see the bug this bit should be:

     #declare G =    0;
     #declare R =   1;
     #declare C =  1;
     #declare B = 0;


Bill P.

Post a reply to this message

> and to see the bug this bit should be:
>
>     #declare G =    0;
>     #declare R =   1;
>     #declare C =  1;
>     #declare B = 0;

In Windows 10, running v3.8 beta 1--

Using your 0110 suggestion, the RED shows up on the cutaway surfaces.

Post a reply to this message

Attachments:
Download 'wp_cutaway_textures_test_from_kw.jpg' (6 KB)

Preview of image 'wp_cutaway_textures_test_from_kw.jpg'

I also get the same result in v3.7.0.

Post a reply to this message

On 12/18/23 13:51, Kenneth wrote:
> I also get the same result in v3.7.0.
> 
Thank you Kenneth! :-) Results are the same.

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.

Bill P.

Post a reply to this message

Thanks for looking into this part of the code.  I've always run into problems
when trying to use it, and never ferreted out what the source of the problem
was.

Running some experiments to test your yuqk fork would give some good reference
SDL to look at.

https://news.povray.org/povray.bugreports/thread/%3Cweb.5e3385d55a7390894eec112d0%40news.povray.org%3E/

I'm switching to a new position at work, and need to leave in 15 min for
training.
Hopefully that all goes smoothly.

- BW

Post a reply to this message

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