POV-Ray : Newsgroups : povray.bugreports : Is the following cutaway_textures bug commonly understood? : Re: Is the following cutaway_textures bug commonly understood? Server Time
12 May 2024 11:35:55 EDT (-0400)
  Re: Is the following cutaway_textures bug commonly understood?  
From: Kenneth
Date: 19 Dec 2023 09:25:00
Message: <web.6581a2a3f36a20089b4924336e066e29@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.