POV-Ray : Newsgroups : povray.binaries.programming : CSG algorithms Server Time: 21 Sep 2020 16:30:42 GMT
 CSG algorithms (Message 1 to 4 of 4)
 From: majucatur Subject: CSG algorithms Date: 29 Jan 2002 22:06:49 Message: <3c571cf9@news.povray.org>
```Hello.

I have a little problem, Someone knows how the CSG works?, mathematically, I
am interested in the algorithm that determine what object is product of the
CSG construction and how can I develop a CSG raytracing system. I was
"reading" the POV sourde files, but with all that modules i got confused.

```
 From: Peter Popov Subject: Re: CSG algorithms Date: 29 Jan 2002 23:14:04 Message: <2iae5u0vkt2eva8jqvno1lpdjjcv2qljv5@4ax.com>
```On Tue, 29 Jan 2002 16:04:39 -0600, "majucatur" <maj### [at] yahoocom>
wrote:

>I have a little problem, Someone knows how the CSG works?, mathematically, I
>am interested in the algorithm that determine what object is product of the
>CSG construction and how can I develop a CSG raytracing system. I was
>"reading" the POV sourde files, but with all that modules i got confused.

Simple. Get all ray-shape intersections from all objects in the CSG,
depth-sort them, then get the first one that is contained inside all
objects of the CSG except the one it belongs to. That's your
intersection point with the CSG. The normal at this point is the
normal of the object the intersection belongs to, flipped if
necessary.

For this to work, all objects should have an Inside(Point) method, an
All_Intersections(Ray) method and a Normal_At(Point) method, or the
equivalent functionality in the language you're coding in.

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg
```
 From: Ron Parker Subject: Re: CSG algorithms Date: 30 Jan 2002 00:02:36 Message:
```On Wed, 30 Jan 2002 01:11:40 +0200, Peter Popov wrote:
> For this to work, all objects should have an Inside(Point) method, an
> All_Intersections(Ray) method and a Normal_At(Point) method, or the
> equivalent functionality in the language you're coding in.

You don't need a Normal_At(Point) method if you instead compute and save
the normal when you retrieve the intersection; for some objects this is less
time-consuming and less ambiguous.

--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
```
 From: Peter Popov Subject: Re: CSG algorithms Date: 30 Jan 2002 22:31:31 Message: <0n3f5ugom0ca1le375i1rr6m4vjv7dtr9h@4ax.com>
```On 29 Jan 2002 19:02:36 -0500, Ron Parker <ron### [at] povrayorg>
wrote:

>You don't need a Normal_At(Point) method if you instead compute and save
>the normal when you retrieve the intersection; for some objects this is less
>time-consuming and less ambiguous.

OK, OK, but for some it is not. Maybe something like:

#define Returned_Normal N

if ((!N.x) && (!N.y) && (!N.z) )
N = ThisObject.Normal_At(Intersection_Point);

You know, I never thought of it this way - that by the maths of it,
some objects will readily provide the normal while intersection
testing. Now there's something to wake me up :)

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg
```