hi,

I'm working on a macro which, given an object positioned at origin, a vertical
resolution, and a frame_number N, returns the Nth "slice", ie the intersection
of object and a (transparent) box.

when I scan a simple (red) sphere[*], the first few frames, and the last few
look exactly as expected, however, on the frames between more and more
information is missing, up to 100% in the middle.

puzzled, and no idea what the problem might be.

I've posted a zip with a set of example frames in povray.binaries.misc.

[*] lit by eight light at corners of imaginary cube, recorded with orthographic
camera positioned above.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
Without code, I can only speculate.
Is the sphere hollow?
Do you apply a transparent pigment/texture to the box?

Looks like some small simple thing that's being overlooked.

Post a reply to this message

On 10/14/19 7:09 AM, jr wrote:
> hi,
> 
> I'm working on a macro which, given an object positioned at origin, a vertical
> resolution, and a frame_number N, returns the Nth "slice", ie the intersection
> of object and a (transparent) box.
> 
> when I scan a simple (red) sphere[*], the first few frames, and the last few
> look exactly as expected, however, on the frames between more and more
> information is missing, up to 100% in the middle.
> 
> puzzled, and no idea what the problem might be.
> 
> I've posted a zip with a set of example frames in povray.binaries.misc.
> 
> [*] lit by eight light at corners of imaginary cube, recorded with orthographic
> camera positioned above.
> 
> regards, jr.
> 

I'm mostly otherwise busy today, but a scene file would help. I don't 
understand how you are getting rings from the box and sphere 
intersection. ...Unless this why you made the box is transparent?

Supposing so. Guess you see one opaque sphere surface cleanly top and 
bottom except at the very edges. Where both box transparent surfaces 
well inside the sphere you'd use those transparent intersections.

At the edges - even where it looks like things are working - you'd get, 
not coincident surfaces, but coincident intersections for at least one 
surface of the transparent box. Perhaps that's the problem?

If ring slices the aim, perhaps something like:

intersection {
   difference { 'sphOuter' 'sphInner' }
   box {... translate <0,frameOffset,0> }
   texture { }
}

Or given the orthographic camera a torus changed frame by frame might be 
better - rings could be of constant width except at the very top and 
bottom.

Bill P.

Post a reply to this message

hi,

(replying to both you and Bald Eagle here)

think BE is right in that it is probably a "small, simple" thing.  currently
thinking it may be the camera.


William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/14/19 7:09 AM, jr wrote:
> > ...
>
> I'm mostly otherwise busy today, but a scene file would help.

yes, my bad.  just posted a zip in p.b.misc.

> I don't
> understand how you are getting rings from the box and sphere
> intersection. ...Unless this why you made the box is transparent?

yes.  and I should have said, there's nothing special about the sphere.  this
"slicing rig" is meant to work with arbitrary objects.  the red sphere is just
testing.

> ...
> Or given the orthographic camera a torus changed frame by frame might be
> better - rings could be of constant width except at the very top and
> bottom.

my current hypothesis: my orthographic camera setup is wrong.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> (replying to both you and Bald Eagle here)
>
> think BE is right in that it is probably a "small, simple" thing.  currently
> thinking it may be the camera.

Nope.  It's putting textures in too early.  The clear texture is what eliminates
the surface[s] of the slice.

I tried this and it looks ok to me.

try this fix, where I moved your sphere texture to the final object {} and
commented out the hollow and texturing of your slicing box.

In reality, nothing should have any textures normals or finishes, and you should
do it ALL in the final object {}.




#version 3.8;

// macro snipped from its .inc file.
#declare SR_EPS = 0.001;

#macro sr_slice(o_, r_, n_)
//  #if (sr_chk_res(r_))
//    #error "oops, bad resolution.\n"
//  #elseif (sr_chk_obb(o_))
//    #error "oops, bad object position/dimension.\n"
//  #end
  #local lb_ = min_extent(o_);
  #local ub_ = max_extent(o_);
  #local D_ = ub_ - lb_;
  /* oversize(d) slice */
  #local tx_ = D_.x * .1;
  #local tz_ = D_.z * .1;
  /* number slices + thickness + offset */
  #local N_ = int(D_.y * r_.y + .5);
  #local T_ = D_.y / N_;
  #local O_ = T_ * n_;
  /* verify {n_} is in range */
  #if ((0 > n_) | (N_ <= n_))
    #error "oops, bad frame/slice number.\n"
  #end
  #local S_ = box {
    <lb_.x-tx_, O_, lb_.z-tz_>-SR_EPS, <ub_.x+tx_, O_+T_, ub_.z+tz_>+SR_EPS
    no_reflection no_shadow
    //texture {pigment {colour srgbt 1}}
  };
  intersection {
    object {o_}
    object {S_}
  }
#end


/* environment */

global_settings {assumed_gamma 1}

background {colour srgb 0}


/* lights */
#if (1)
  /* white lights at corners of an imaginary cube */
  #local LD = 50;
  #local Lpos = array [8] {
    <-LD,LD,-LD>, <LD,LD,-LD>, <-LD,-LD,-LD>, <LD,-LD,-LD>,
    <-LD,LD,LD>, <LD,LD,LD>, <-LD,-LD,LD>, <LD,-LD,LD>
  };
  #for(I_,0,7)
    light_source {Lpos[I_] srgb 1 parallel shadowless}
  #end
#else
  /* white lights along axes */
  #local LD = 50;
  #local Lpos = array [6] {
    <-LD,0,0>, <LD,0,0>, <0,-LD,0>, <0,LD,0>, <0,0,-LD>, <0,0,LD>
  };
  #for(I_,0,5)
    light_source {Lpos[I_] srgb 1 parallel shadowless}
  #end
#end


/* object.
 * fully textured and scaled, its bounding box must run from origin
 * to positive, small-ish <x,y,z>.
 */

#declare Obj = sphere {0,1
  translate +1
};

//#debug concat("min: <",vstr(3,min_extent(Obj),",",0,6),">\n")
//#debug concat("max: <",vstr(3,max_extent(Obj),",",0,6),">\n")


/* cameras.
 * perspective for development, orthographic for slicing.
 */

#if (1)
  camera {
    orthographic
    location <1,5,1>
    look_at <1,0,1>
    sky <0,0,1>
    angle 50
  }
#else
  camera {
    perspective
    location <1,1,-5>
    look_at <1,1,1>
    up <0,1,0>
    right x * (image_width/image_height)
  }
#end

// only Y matters.
#declare Res = <10,100,10>;

//sr_feedback(Obj,Res)
object {sr_slice(Obj,Res,frame_number) texture {pigment {srgb <1,0,0>}} }

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > (replying to both you and Bald Eagle here)
> > think BE is right in that it is probably a "small, simple" thing.  currently
> > thinking it may be the camera.
>
> Nope.  It's putting textures in too early.  The clear texture is what eliminates
> the surface[s] of the slice.

ok.

> I tried this and it looks ok to me.
> try this fix, where I moved your sphere texture to the final object {} and
> commented out the hollow and texturing of your slicing box.

does not for me.  :-(  I get solid (filled) circles, not rings.

promising though and I now have a lead (here goes hope :-))

> In reality, nothing should have any textures normals or finishes, and you should
> do it ALL in the final object {}.

that may not always be an option.  the idea is to slice arbitrary objects
(suitably scaled + positioned).  the object may not always be my own work
though.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> does not for me.  :-(  I get solid (filled) circles, not rings.

Ah.

> that may not always be an option.  the idea is to slice arbitrary objects
> (suitably scaled + positioned).  the object may not always be my own work
> though.

Sounds like that ex-post facto texturing lots of people would like...

try using 2 "clipped_by" objects instead of an intersection?

I really never use that command - so maybe others have advice.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > does not for me.  :-(  I get solid (filled) circles, not rings.
> ...
> Sounds like that ex-post facto texturing lots of people would like...

I'd _love_ a trace()-like function which returns a colour (instead of a normal).

> try using 2 "clipped_by" objects instead of an intersection?

good thought, had overlooked that.  so I modified the macro to return the box
dimensions only and used that in a clipped_by, but, no dice.  in fact, visually
identical.

> I really never use that command - so maybe others have advice.

fingers crossed.  and, thank you.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > does not for me.  :-(  I get solid (filled) circles, not rings.
> > ...
> > Sounds like that ex-post facto texturing lots of people would like...
>
> I'd _love_ a trace()-like function which returns a colour (instead of a normal).

That is called eval_pigment, Sir.

http://wiki.povray.org/content/Reference:Functions.inc

Pre defined functions
eval_pigment(Pigm, Vect): This macro evaluates the color of a pigment at a
specific point. Some pigments require more information than simply a point,
slope pattern based pigments for example, and will not work with this macro.
However, most pigments will work fine.

Parameters:

Vect = The point at which to evaluate the pigment.
Pigm = The pigment to evaluate.

Post a reply to this message

good morning,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > I'd _love_ a trace()-like function which returns a colour (instead of a normal).
>
> That is called eval_pigment, Sir.

no, no, no!  not even close, I tried.

if you look at the macro in 'functions.inc' you'll see why, eval_pigment doesn't
"do" objects, all you get is a colour read from the pigment at the given
co-ordinate.  does not work for all pigments as you say (and I'd need it to work
on textures, anyway), and lighting is not taken into account either.


regards, jr.

Post a reply to this message