In an earlier posting (on 20040121), I requested info on "scanning"
unions and differences of objects to read off height-field data from the
composite structure and thence out to a text file. A day or two after this
I discovered the isect() function, which seems to do the trick.

Except....that when the vector you're using to intersect with the intended
surface strikes the junction between two objects in this composite
structure,
sometimes it shoots through the seam and intersects the surface on the
opposite
side.

Here's a test case.
Create a cube 4 units on a side, centered at the origin.
Create a sphere of radius 1, offset 2 units along the +y axis.
Create an object that is the difference between these--what you get is
a cube with a hemispherical "basin" of radius 1. The composite object
is centered on the y axis.

Now run isect() in a raster pattern from x= -2 to 2 and z = -2 to 2,
y = 3 (for example), and with a downward-pointing vector of length 6
(for example). If you iterate isect with this vector at fine enough a
resolution (say 0.001 unit) in the x and z components of the starting
point, sometimes the vector shoots through the top surface at the
junction between the cube and the hemisphere, along the edge of the
basin.

I can work around this programmatically by trapping the erroneous returns,
but thought I'd document this in case 1) a developer wanted to track this,
or
2) I missed something in generating a simple difference object or in using
isect.

--MVSmith

Post a reply to this message

MVSmith wrote:
> In an earlier posting (on 20040121), I requested info on "scanning"
> unions and differences of objects to read off height-field data from the
> composite structure and thence out to a text file. A day or two after this
> I discovered the isect() function, which seems to do the trick.

I don't know such a function, neither in POV-SDL syntax nor in the 
POV-Ray source code.

> Except....that when the vector you're using to intersect with the intended
> surface strikes the junction between two objects in this composite
> structure,
> sometimes it shoots through the seam and intersects the surface on the
> opposite
> side.
> 
> Here's a test case.
> Create a cube 4 units on a side, centered at the origin.
> Create a sphere of radius 1, offset 2 units along the +y axis.
> Create an object that is the difference between these--what you get is
> a cube with a hemispherical "basin" of radius 1. The composite object
> is centered on the y axis.
> 
> [...]

It would probably be much easier if you just post a minimal test scene 
to reproduce your problem.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Will post a test scene, probably tomorrow.

Chris


"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:8cu### [at] tritonimagicode...
> MVSmith wrote:
> > In an earlier posting (on 20040121), I requested info on "scanning"
> > unions and differences of objects to read off height-field data from the
> > composite structure and thence out to a text file. A day or two after
this
> > I discovered the isect() function, which seems to do the trick.
>
> I don't know such a function, neither in POV-SDL syntax nor in the
> POV-Ray source code.
>
> > Except....that when the vector you're using to intersect with the
intended
> > surface strikes the junction between two objects in this composite
> > structure,
> > sometimes it shoots through the seam and intersects the surface on the
> > opposite
> > side.
> >
> > Here's a test case.
> > Create a cube 4 units on a side, centered at the origin.
> > Create a sphere of radius 1, offset 2 units along the +y axis.
> > Create an object that is the difference between these--what you get is
> > a cube with a hemispherical "basin" of radius 1. The composite object
> > is centered on the y axis.
> >
> > [...]
>
> It would probably be much easier if you just post a minimal test scene
> to reproduce your problem.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
>

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> schrieb im Newsbeitrag
news:8cu### [at] tritonimagicode...
> MVSmith wrote:
> > In an earlier posting (on 20040121), I requested info on "scanning"
> > unions and differences of objects to read off height-field data from the
> > composite structure and thence out to a text file. A day or two after
this
> > I discovered the isect() function, which seems to do the trick.
>
> I don't know such a function, neither in POV-SDL syntax nor in the
> POV-Ray source code.

It's a macro in shapes.inc. From the docs:

"Isect(Pt, Dir, Obj, OPt) and IsectN(Pt, Dir, Obj, OPt, ONorm)
These macros are interfaces to the trace() function. Isect() only returns
the intersection point, IsectN() returns the surface normal as well."

Regards,

Marc-Hendrik

Post a reply to this message

MVSmith wrote:
> Here's a test case.
> Create a cube 4 units on a side, centered at the origin.
> Create a sphere of radius 1, offset 2 units along the +y axis.

Sounds like a problem with coincident surfaces...
http://www.povray.org/documentation/view/46/

Post a reply to this message

In article <402bc4ec$1@news.povray.org>, <MVSmith> wrote:

> In an earlier posting (on 20040121), I requested info on "scanning"
> unions and differences of objects to read off height-field data from the
> composite structure and thence out to a text file. A day or two after this
> I discovered the isect() function, which seems to do the trick.

I assume you are talking about the Isect() and IsectN() macros in 
shapes.inc. Please be more precise in the future...functions are 
something else entirely, and capitalization does matter.


> Except....that when the vector you're using to intersect with the intended
> surface strikes the junction between two objects in this composite
> structure,
> sometimes it shoots through the seam and intersects the surface on the
> opposite
> side.

This is not a problem with the Isect() macros, they are just wrappers 
for the trace() function. And it is very unlikely that it is a problem 
with the trace() function, which uses the same code the rest of POV 
uses. It sounds more likely that it is a problem with your test object 
or with your conception of what to expect. It may be precision errors, 
or something wrong with the way you have things set up...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

> In article <402bc4ec$1@news.povray.org>, <MVSmith> wrote:

> > Except....that when the vector you're using to intersect with the intended
> > surface strikes the junction between two objects in this composite
> > structure,
> > sometimes it shoots through the seam and intersects the surface on the
> > opposite
> > side.

I saw a problem like this with trace() appearing to miss coincident
surfaces in my IRTC entry. While I can see why in tracing it isn't possible
to tell which surface the ray hits, I didn't expect it to miss both surfaces,
at the time I put it down to an error in my code.

light_source {<8,5,-1>,1}
camera{ location <12,5,-5> look_at <5,1,0>}

#declare Y1=0.35;
#declare Y2=0.35;       // 0.35 fails, 0.3501 works

#declare A=
union
{
    intersection
    {
        box{<-20,0,0.86> <20,Y1,3>}
        union
        {
            cylinder{<5,0,2.8> <5,Y2,2.8> 1.94 }
            cylinder{<11,0,2.8> <11,Y2,2.8> 1.94 }
            cylinder{<-5,0,2.8> <-5,Y2,2.8> 1.94 }
            cylinder{<-11,0,2.8> <-11,Y2,2.8> 1.94}
        }
    }
    box{<-20,0,0.86> <-11,Y1,3>}
    box{<-5,0,0.86> <5,Y1,3> } 
    box{<11,0,0.86> <20,Y1,3>}
}

object{A pigment {rgb 1}}

#local i=-15;
#while(i<15)
sphere{trace(A,<i,12,2>,-y) 1/10 pigment {rgb x}}
#local i=i+0.1;
#end

Regards,

Bernard

Post a reply to this message

MVSmith wrote:
> OK, mea culpa...Isect is a macro, documented in Help, 7.13.1  shapes.inc,
> which is indeed a wrapper for the trace function.
>  
> Spent a little time stripping some code down to a test case, which
> follows at the end of this msg. 

This is about as far from a minimal test scene as it can get.  A minimal 
scene would look like:

#include "shapes.inc"

#local Object = object { ... }

#local isIntersection = Isect(<point>, -y, Object, intersectPoint);

#debug str(intersectPoint.y,0,6)

> I've also attached three files zipped 
> together:

Never post binary attachments to a non-binary group.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message