POV-Ray : Newsgroups : povray.binaries.programming : CSG algorithms Server Time
21 Dec 2024 22:11:50 EST (-0500)
  CSG algorithms (Message 1 to 4 of 4)  
From: majucatur
Subject: CSG algorithms
Date: 29 Jan 2002 17: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.

Thanks for your time.


Post a reply to this message

From: Peter Popov
Subject: Re: CSG algorithms
Date: 29 Jan 2002 18: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


Post a reply to this message

From: Ron Parker
Subject: Re: CSG algorithms
Date: 29 Jan 2002 19:02:36
Message: <slrna5ee0v.l3r.ron.parker@fwi.com>
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


Post a reply to this message

From: Peter Popov
Subject: Re: CSG algorithms
Date: 30 Jan 2002 17: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


Post a reply to this message

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