A while ago I was working on a big complicated image, and I wanted to
make a precise plane intersection shape far away from the origin.  I
quickly realized that although I knew exact locations, planes are
described around the origin.  It only takes three points to define a
plane, but for use in plane intersections there is an inside and an
outside, so I decided to use a fourth point to decide witch side of the
plane is inside.  I thought I could write a macro to do it in 15
minutes, I was very wrong.  I think it finally works now, but I thought
that a few days ago before I found some huge bugs.  If you find any bugs
or have suggestions, please comment.


///////////////////////////////////////////////////////////////////
//
//  Four_point_plane support functions
//

#macro Proj (U,V)  // projection of U onto V
        (V*(vdot(U,V)/vdot(V,V)))
#end
#macro Same_test (Vector1,Vector2) //tests if two vectors are the same
returns boolean
        (vdot((Vector1 = Vector2),<1,1,1>) = 3)
#end
#macro Collinear_test (Vector1,Vector2,Vector3)  //tests if three points
are on the same line
        #local U = (Vector1-Vector2);
        #local V = (Vector1-Vector3);
        (abs(vdot(U,V)/(vlength(U)*vlength(V))) = 1)
#end
#macro On_plane_test (Point_on_plane,Normal,Test_point)     //  Uses a
point on the plane, and normal vector to test if Test_point
        (vlength(Proj (Point_on_plane-Test_point,Normal)) = 0)  // is on
the plane, returns boolean.
#end
#macro Same_direction_test (Vector1,Vector2) // Tests if two vectors
point in same direction.  If either point is the zero vector,
        (2*(vdot(Vector1,Vector2)/(vlength(Vector1)*vlength(Vector2)) =
1)-1) // you will get a divide by zero error.
#end
// Returns positive or negative 1.

#macro Same_side_test (Point_on_plane,Normal,Test_point1,Test_point2)
//  Tests if both test points are on same side of plane.
        #local Vec1 = Proj(Test_point1-Point_on_plane,Normal);
//  If either test point is in the plane you will get a
        #local Vec2 = Proj(Test_point2-Point_on_plane,Normal);
//  divide by zero error.  Returns positive or negative 1.
        Same_direction_test (Vec1,Vec2)
#end
//
//  End support functions
//
////////////////////////////////////////////////////////////////

// Four_point_plane
// In povray everything on one side of the plane is considered inside
the plane object
// Vector1, Vector2, and Vector3 are points on the plane, none of these
points can be the same as any other,
// and they can't be in a strait line.  Inside point is a control point
to determine witch side of the plane
// is considered inside.  Originally all of the error tests were just
going to be warning messages, but
// in testing I found that all of the errors the error trapping codes
are used to find would cause something
// like a divide by zero error before the warning message was
displayed.  I decided then that it would be better
// to give a usefull error, and halt the render process, because the
render would be halted regardless.
#macro Four_point_plane (Vector1,Vector2,Vector3,Inside_point)
        #if (Same_test (Vector1,Vector2))
        #error "Vector1 = Vector2" #end
        #if (Same_test (Vector1,Vector3))
        #error "Vector1 = Vector3" #end
        #if (Same_test (Vector3,Vector2))
        #error "Vector2 = Vector3" #end
        #if (Collinear_test (Vector1,Vector2,Vector3))
        #error "All vectors on same line" #end
        #local Cross =
vnormalize(vcross(Vector1-Vector2,Vector3-Vector2));
        #if (On_plane_test(Vector1,Cross,Inside_point))
        #error "Inside_point is on plane"#end
        #if (On_plane_test(Vector1,Cross,<0,0,0>))
           #local Distance_from_origin = 0;
           #local Normal_vector = -Same_side_test
(Vector1,Cross,Cross,Inside_point)*Cross;
           // If Cross vector points to the same side of the plane that
the inside point is on, inverts Cross to create normal vector.
        #else
           #local Test_n = Same_direction_test
(Cross,Proj(Vector1,Cross));
           #local Test_o = Same_side_test
(Vector1,Cross,<0,0,0>,Inside_point);
           #local Normal_vector = Test_n * Test_o * Cross;
           #local Distance_from_origin = Test_o *
vlength(Proj(Vector1,Normal_vector));
        #end
        plane {Normal_vector, Distance_from_origin}
#end
//  Three_point_plane assumes that the origin is in the object.
#macro Three_point_plane (Vector1,Vector2,Vector3)
        Four_point_plane (Vector1,Vector2,Vector3,<0,0,0>) // lazy way
to do things
#end

/////////////////////////////////////////
//                                     //
//  More macros I have been working on //
//                                     //
/////////////////////////////////////////

#macro Array_plane (Array)    // creates a plane from data points stored
in an array
        plane {<Array[1],Array[2],Array[3]>,Array[4]}
#end
#macro Inclusion (Object1,Object2)     // Cuts a hole in an object and
fills it.
        union
{difference{object{Object1}object{Object2}}object{Object2}}
#end
#macro Sign (X)    //Positive or negative 1 depending on the sign of X
        (X/abs(X))
#end
#macro Angle_between_vectors(U,V)
        (degrees (acos(vdot(U,V)/(vlength(U)*vlength(V)))))
#end
#macro Three_Point_Angle (Vector1,Vector2,Vector3)   //measures an angle
defined by three points the middle point is
        Angle_between_vectors((Vector1-Vector2),(Vector3-Vector2))
//the vertex.
#end

////////////////////////////////////////



--
Dan Johnson

http://www.geocities.com/zapob

Post a reply to this message

Dan Johnson wrote in message <3AEE7E92.6963DACB@hotmail.com>...
> A while ago I was working on a big complicated image, and I wanted to
> make a precise plane intersection shape far away from the origin.

Perhaps much better place for it's tutorial or scene-files groups.

> If you find any bugs or have suggestions, please comment.

I don't know how your macro works but I found that....

> #macro Sign (X) // Positive or negative 1 depending on the sign of X
>        (X/abs(X))
> #end

...could be more precise and still short

#macro Sign(P)
  (P>0?1:P<0?-1:0)
#end

also in megapov there is inclusion of Chris Chuff which builds-in function
sign() to available keywords

ABX

Post a reply to this message

In article <3aed54c7@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> also in megapov there is inclusion of Chris Chuff which builds-in function
> sign() to available keywords

Actually, it's sgn()...I was too lazy to get it to work properly with 
"sign", which is already used elsewhere...and as far as I know, hasn't 
been added to MegaPOV for this reason. Since it won't be in POV 3.5, you 
might as well use a macro.

Oh, and it's Chris Huff. ;-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote in message ...
>In article <3aed54c7@news.povray.org>, "Wlodzimierz ABX Skiba"
><abx### [at] abxartpl> wrote:
>
> > also in megapov there is inclusion of Chris Chuff which builds-in function
> > sign() to available keywords
>
> Actually, it's sgn()...I was too lazy to get it to work properly with
> "sign", which is already used elsewhere...and as far as I know, hasn't
> been added to MegaPOV for this reason. Since it won't be in POV 3.5, you
> might as well use a macro.

I found in tokenize.c entry
  {SGN_TOKEN, "sgn"}, /*Chris Huff jan 2001*/
then look for SGN_TOKEN in other files and found in express.c
  case SGN_TOKEN: /*Chris Huff "sign() function"*/
then forgot about sgn() and remembered sign()

but now I write:
  #version unofficial megapov 0.7;
  #warning concat(str(sgn(100),0,0),"\n")

and it won't work ???

> Oh, and it's Chris Huff. ;-)


I try remember ;-)
The reason is that both ("H" and "CH") have identical vocalizations in polish.

ABX

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-61F0EA.07305030042001@news.povray.org...
>
> Oh, and it's Chris Huff. ;-)
>

Chuff being UK slang for a fart ;)

Post a reply to this message

Wlodzimierz ABX Skiba wrote:

> Chris Huff wrote in message ...
> >In article <3aed54c7@news.povray.org>, "Wlodzimierz ABX Skiba"
> ><abx### [at] abxartpl> wrote:
> >
> > > also in megapov there is inclusion of Chris Chuff which builds-in function
> > > sign() to available keywords
> >
> > Actually, it's sgn()...I was too lazy to get it to work properly with
> > "sign", which is already used elsewhere...and as far as I know, hasn't
> > been added to MegaPOV for this reason. Since it won't be in POV 3.5, you
> > might as well use a macro.
>
> I found in tokenize.c entry
>   {SGN_TOKEN, "sgn"}, /*Chris Huff jan 2001*/
> then look for SGN_TOKEN in other files and found in express.c
>   case SGN_TOKEN: /*Chris Huff "sign() function"*/
> then forgot about sgn() and remembered sign()
>
> but now I write:
>   #version unofficial megapov 0.7;
>   #warning concat(str(sgn(100),0,0),"\n")
>
> and it won't work ???
>
> > Oh, and it's Chris Huff. ;-)
>
> I try remember ;-)
> The reason is that both ("H" and "CH") have identical vocalizations in polish.
>
> ABX

Sign was originally part of the four point plane macro, but I found that version
had huge bugs.  When I rewrote it the guts of the program were very different, and
I didn't need it anymore.  If I thought a stupid little program I wrote in 30
seconds to save myself typing elsewhere was going to take all the attention away
from the main point of my post I wouldn't have included it.  Maybe I am being
selfish, sorry, but I still don't know if I should be proud of the program I spent
hours on, because I am not completely confident that it works right.


--
Dan Johnson

http://www.geocities.com/zapob

Post a reply to this message

In article <3aed6365@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> I found in tokenize.c entry
>   {SGN_TOKEN, "sgn"}, /*Chris Huff jan 2001*/
> then look for SGN_TOKEN in other files and found in express.c
>   case SGN_TOKEN: /*Chris Huff "sign() function"*/
> then forgot about sgn() and remembered sign()
> 
> but now I write:
>   #version unofficial megapov 0.7;
>   #warning concat(str(sgn(100),0,0),"\n")
> 
> and it won't work ???

Because, as I said, it's turned off...you left out the #ifdef 
SignPatch...#endif blocks surrounding those lines. The definition of 
SignPatch in frame.h is commented out, and a reason given:

/*#define SignPatch*/ /*Chris Huff July 2000 (added to mp jan 2001)*/
/* not truned on because of the conflict with sign in the isosurface. 
sng and sign ???? no :) */

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Wlodzimierz ABX Skiba wrote:

> ...could be more precise and still short
>
> #macro Sign(P)
>   (P>0?1:P<0?-1:0)
> #end

Who says the sign of 0 is 0? ;-)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Dan,

I was kind of surprised to see the sign-discussion spawned with no mention
of your macro, too. The macro is very cool, in my opinion. In fact, this
will be a life-saver for me if it you can work out the bugs -- I'm rendering
a house with very strange roof-lines, which in real life were cut
on-the-fly, which makes for very complicated work to reproduce accurately in
POV.

I've been playing with it, and it never seems to generate a plane with a
negative normal. I did this quick test:

Four_point_plane(<0,16,7>,<0,16,45.3>,<19,22,26.15>,<1,-100,26.15>)

I tried y=+/-100 in the fourth vector, and the results are the same in both
cases. The angle and position of the plane looks perfect, but the vector is
always positive (the plane is always solid "pointing down", towards y=0).

This box roughly defines the size of the house I'm rendering so you can see
how this plane cuts it and how the points are positioned relative to most of
the rest of the model:

box{<0,0,7> <66,22,45.3>}

Unless I misunderstand the usage, changing y from 100 to -100 in this case
should flip the plane "up" and "down", correct?

--Jon


"Dan Johnson" <zap### [at] hotmailcom> wrote in message
news:3AEEF4DF.27E6A513@hotmail.com...
> Wlodzimierz ABX Skiba wrote:
>
> > Chris Huff wrote in message ...
> > >In article <3aed54c7@news.povray.org>, "Wlodzimierz ABX Skiba"
> > ><abx### [at] abxartpl> wrote:
> > >
> > > > also in megapov there is inclusion of Chris Chuff which builds-in
function
> > > > sign() to available keywords
> > >
> > > Actually, it's sgn()...I was too lazy to get it to work properly with
> > > "sign", which is already used elsewhere...and as far as I know, hasn't
> > > been added to MegaPOV for this reason. Since it won't be in POV 3.5,
you
> > > might as well use a macro.
> >
> > I found in tokenize.c entry
> >   {SGN_TOKEN, "sgn"}, /*Chris Huff jan 2001*/
> > then look for SGN_TOKEN in other files and found in express.c
> >   case SGN_TOKEN: /*Chris Huff "sign() function"*/
> > then forgot about sgn() and remembered sign()
> >
> > but now I write:
> >   #version unofficial megapov 0.7;
> >   #warning concat(str(sgn(100),0,0),"\n")
> >
> > and it won't work ???
> >
> > > Oh, and it's Chris Huff. ;-)
> >
> > I try remember ;-)
> > The reason is that both ("H" and "CH") have identical vocalizations in
polish.
> >
> > ABX
>
> Sign was originally part of the four point plane macro, but I found that
version
> had huge bugs.  When I rewrote it the guts of the program were very
different, and
> I didn't need it anymore.  If I thought a stupid little program I wrote in
30
> seconds to save myself typing elsewhere was going to take all the
attention away
> from the main point of my post I wouldn't have included it.  Maybe I am
being
> selfish, sorry, but I still don't know if I should be proud of the program
I spent
> hours on, because I am not completely confident that it works right.
>
>
> --
> Dan Johnson
>
> http://www.geocities.com/zapob
>
>

Post a reply to this message

Anybody want to take a crack at fixing the +/- normal problem?

My vector math skills aren't up to it -- I understand the basics, but
not enough to understand how they work together to make up the
final result. The macro appears to generate a plane in the correct
position and orientation, but the inside_point vector doesn't seem
to work right -- no matter what coordinates I specify, the plane always
ends up with the normal in the same direction.

It's a pretty nice little tool... any takers?

Post a reply to this message