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

Dan Johnson wrote:
> 
> 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.
>...

I think that the macro below will do the same.


#macro FourPointPlane(p1, p2, p3, pInside)

  #local vA = p2 - p1;
  #local vB = p3 - p1;
  #local vC = pInside - p1;
  #local vN = vcross(vA, vB);
  #local STP = vdot(vN, vC); // Scalar Triple Product of vA, vB and vC
  #if (STP = 0) // Check for coplanar vectors
    #error "\nMacro FourPointPlane: All points lie in the same plane.\n"
  #else
    #local vN = (STP > 0 ? -1 : 1)*vnormalize(vN);
    plane { vN, vdot(p1, vN) }
  #end // if

#end // macro FourPointPlane


- But I haven't tested it much. Sorry.

I also have some suggestions for some of
your support macros if you are interested.


-- 
Best regards,

Tor Olav

mailto:tor### [at] hotmailcom
http://hjem.sol.no/t-o-k/tokpicts.html
http://www.crosswinds.net/~tok

Post a reply to this message

Tor Olav Kristensen wrote:

> Dan Johnson wrote:
> >
> > 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.
> >...
>
> I think that the macro below will do the same.
>
> #macro FourPointPlane(p1, p2, p3, pInside)
>
>   #local vA = p2 - p1;
>   #local vB = p3 - p1;
>   #local vC = pInside - p1;
>   #local vN = vcross(vA, vB);
>   #local STP = vdot(vN, vC); // Scalar Triple Product of vA, vB and vC
>   #if (STP = 0) // Check for coplanar vectors
>     #error "\nMacro FourPointPlane: All points lie in the same plane.\n"
>   #else
>     #local vN = (STP > 0 ? -1 : 1)*vnormalize(vN);
>     plane { vN, vdot(p1, vN) }
>   #end // if
>
> #end // macro FourPointPlane
>
> - But I haven't tested it much. Sorry.
>
> I also have some suggestions for some of
> your support macros if you are interested.
>
> --
> Best regards,
>
> Tor Olav
>
> mailto:tor### [at] hotmailcom
> http://hjem.sol.no/t-o-k/tokpicts.html
> http://www.crosswinds.net/~tok

You have the right idea, my beta program seems to be working lets optimize
it.  Your error catching test is simple, and clever.  I checked all the
math, and it should effectively catch all the bugs my functions do.  It
isn't very helpful to anyone using it, as to what specific thing, or things
they did wrong though.  I would like to use it as a condition for running
the other tests so that it only tries to find out what is wrong, after it
has found out that something is wrong.  I don't understand how the sign of
the triple scalar product is used to find out if the normal needs to be
corrected.  The line " plane { vN, vdot(p1, vN) } " is very similar to what
I get when I write out the formula I used and simplified.  An important
difference is that when I simplified I needed an abs around the result of
the vdot.

Having written my own version I have a fairly comprehensive test scene.  I
decided to replace my macro with your macro in the scene, and see what
happens.  Immediately it got a user error directive.  I commented out all
the function calls, but the first, and it still happened.  Now I knew that
the very first function call was getting an error.  I did the math by hand,
and found out that the value of STP should be -4 not 0.  I dug further, and
found out that the value of vN was <0,0,0>.  This shouldn't be, now I am
very confused.  Here is the test scene maybe you can make sense of it.

#include "colors.inc"
#include "polyhedra.inc"
#include "finish.inc"

#macro ThreePointPlane(P1,P2,P3)
        FourPointPlane(P1,P2,P2,<0,0,0>)
#end

/*
#declare Cube1 = <1,1,1>; // Cube vertexes
#declare Cube2 = <1,1,-1>;  // from polyhedra.inc
#declare Cube3 = <1,-1,1>;
#declare Cube4 = <1,-1,-1>;
#declare Cube5 = <-1,1,1>;
#declare Cube6 = <-1,1,-1>;
#declare Cube7 = <-1,-1,1>;
#declare Cube8 = <-1,-1,-1>;
*/

intersection {
                ThreePointPlane (Cube5,Cube3,Cube2)
                ThreePointPlane (Cube8,Cube3,Cube2)
                ThreePointPlane (Cube2,Cube5,Cube8)
                ThreePointPlane (Cube8,Cube5,Cube3)
                FourPointPlane (<0,1,1>,<0,0,0>,<0,-1,1>,<-1,0,0>)
                texture {pigment {rgbt <1,0,0,0>}} finish {
                ambient .1
                diffuse 1
                reflection .15
                specular 0
                roughness .6
}}
object{Cube_edges(1,.1) texture { finish {
                ambient .1
                diffuse .4
                reflection .25
                specular .6
                roughness .1
}pigment{Green}}}
//object {FourPointPlane (<2,2,1>,<3,3,1>,<4,7,1>,<0,0,20>) pigment
{CornflowerBlue}}
sphere{Cube1,.2 pigment{Blue}}

light_source {<100,30,-100> rgb 2}
camera {location <6,8,-12> look_at 0 angle 20}


--
Dan Johnson

http://www.geocities.com/zapob

Post a reply to this message

Dan Johnson wrote:
>...
> Having written my own version I have a fairly comprehensive test scene.  I
> decided to replace my macro with your macro in the scene, and see what
> happens.  Immediately it got a user error directive.  I commented out all
> the function calls, but the first, and it still happened.  Now I knew that
> the very first function call was getting an error.  I did the math by hand,
> and found out that the value of STP should be -4 not 0.  I dug further, and
> found out that the value of vN was <0,0,0>.  This shouldn't be, now I am
> very confused.  Here is the test scene maybe you can make sense of it.
>....


Your macro below has an error.

>....
> #macro ThreePointPlane(P1,P2,P3)
>         FourPointPlane(P1,P2,P2,<0,0,0>)
> #end
>....

You're not using P3. (P2 is written twice.)

I'm in a hurry right now, so I don't have 
time for more testing or to try and explain.
Maybe later ...

But if you're going to do further tests,
then I'm interested in hearing about your
results.


-- 
Best regards,

Tor Olav

mailto:tor### [at] hotmailcom
http://hjem.sol.no/t-o-k/tokpicts.html
http://www.crosswinds.net/~tok

Post a reply to this message

Tor Olav Kristensen wrote:

> Your macro below has an error.
>
> >....
> > #macro ThreePointPlane(P1,P2,P3)
> >         FourPointPlane(P1,P2,P2,<0,0,0>)
> > #end
> >....
>
> You're not using P3. (P2 is written twice.)

Doh!  Such a headache over a typo.  Well now everything works.  I'm sure I will
spend a few hours figuring out why.  Much more enjoyable than figuring out why
something doesn't work.  Then I will obfuscate it.  I am learning more about math
this way than reading the book.  Jon wrote me directly telling me about the
project he is working on that uses my macro.  When he is done maybe he will be
willing to share his code, and we can test this version on it to see if it gets
the same results.  Thanks for pointing out my error, I'm sure it would have taken
me another hour before I spotted it.




>
> I'm in a hurry right now, so I don't have
> time for more testing or to try and explain.
> Maybe later ...
>
> But if you're going to do further tests,
> then I'm interested in hearing about your
> results.
>
> --
> Best regards,
>
> Tor Olav
>
> mailto:tor### [at] hotmailcom
> http://hjem.sol.no/t-o-k/tokpicts.html
> http://www.crosswinds.net/~tok




--
Dan Johnson

http://www.geocities.com/zapob

Post a reply to this message

If you're interested in this subject, please see my
follow-up and pics in povray.binaries.images.


"Dan Johnson" <zap### [at] hotmailcom> wrote in message
news:3AF324DD.D3777CCE@hotmail.com...
> See povray.binarys.images for reply
> Dan
>

Post a reply to this message

Ok Tor Olav now that I understand the math I am certain your code works perfectly I
simplified it enough to remove 3 local variables.  I then added descriptive error
messages without halting rendering.  There aren't any support functions now.  Unless
someone thinks of a way to make it better this is the final version.

////////////////////////////////////////////////////////////////
// Four_point_plane  Beta 2  May 7 2001
//
// Original Idea Dan Johnson
// Code Dan Johnson, and Tor Olav Kristensen
//
// In povray everything on one side of the plane is considered inside the plane
object
// P1, P2, and P3 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. Tor Olav posted much simpler code to do the same job a few
days after me.
// I believe that I can prove it always works.  The plane generating code is based on
Tor Olav's with a
// few minor simplifications, and the error trapping is mostly mine.
// Dan Johnson


#macro Four_point_plane(P1, P2, P3, I)// P1-3 = points on plane I = inside point

  #local Cross = vcross(P2 - P1, P3 - P1);
  #local STP = vdot(Cross, I - P1); // Scalar Triple Product
  #if (STP = 0) // Check for invalid data
    //determine specific error, or errors.
    #local Errors = "\nFour_point_plane did not create a plane because of the
following bad imput\n"
    #local S1 = (vdot((P1 = P2),<1,1,1>) = 3);  // same checks
    #local S2 = (vdot((P2 = P3),<1,1,1>) = 3);
    #local S3 = (vdot((P3 = P1),<1,1,1>) = 3);
    #if (S1 + S2 + S3 > 0)
     #if (S1) #local Errors = concat (Errors,"Point1 = Point2\n")#end
     #if (S2) #local Errors = concat (Errors,"Point2 = Point3\n")#end
     #if (S3) #local Errors = concat (Errors,"Point3 = Point1\n")#end
    #else
     #if (abs(vdot(vnormalize(P2-P1),vnormalize(P3-P2))) = 1)
      #local Errors = concat (Errors,"All points on same line\n")
     #else
      #local Errors = concat (Errors,"Inside point is on plane\n")
     #end
    #end
    #warning Errors
    sphere {<0,0,0>,0}  //Whatever called Four_point_plane is expecting an object.
  #else
    #local N = (STP > 0 ? -1 : 1)*vnormalize(Cross);// normal vector
    plane { N, vdot(P1, N) }
  #end // if

#end // macro Four_point_plane

//  Three_point_plane assumes that the origin is in the object.
#macro Three_point_plane(P1,P2,P3)
        Four_point_plane(P1,P2,P3,<0,0,0>)
#end


--
Dan Johnson

http://www.geocities.com/zapob

Post a reply to this message

Dan Johnson wrote:
> 
> Ok Tor Olav now that I understand the math I am certain your code works perfectly I
> simplified it enough to remove 3 local variables.  I then added descriptive error
> messages without halting rendering.  There aren't any support functions now.  Unless
> someone thinks of a way to make it better this is the final version.

Your macro looks much better now. And it also 
seems that you have got a better understanding 
of vector dot products now ;)

But I still have some more suggestions for you.
=> See my comments below.


-- 
Best regards,

Tor Olav

mailto:tor### [at] hotmailcom
http://hjem.sol.no/t-o-k/tokpicts.html
http://www.crosswinds.net/~tok


>...
> #macro Four_point_plane(P1, P2, P3, I)// P1-3 = points on plane I = inside point
> 
>   #local Cross = vcross(P2 - P1, P3 - P1);
>   #local STP = vdot(Cross, I - P1); // Scalar Triple Product
>   #if (STP = 0) // Check for invalid data
>     //determine specific error, or errors.
>     #local Errors = "\nFour_point_plane did not create a plane because of the
> following bad imput\n"

>     #local S1 = (vdot((P1 = P2),<1,1,1>) = 3);  // same checks
>     #local S2 = (vdot((P2 = P3),<1,1,1>) = 3);
>     #local S3 = (vdot((P3 = P1),<1,1,1>) = 3);


To "check" if any two points are equal you could write:

#local EqualAB = (vlength(PB - PA) = 0);


>     #if (S1 + S2 + S3 > 0)

You may want to try this:

#if (S1 | S2 | S3)


>      #if (S1) #local Errors = concat (Errors,"Point1 = Point2\n")#end
>      #if (S2) #local Errors = concat (Errors,"Point2 = Point3\n")#end
>      #if (S3) #local Errors = concat (Errors,"Point3 = Point1\n")#end
>     #else
>      #if (abs(vdot(vnormalize(P2-P1),vnormalize(P3-P2))) = 1)

You could simply check if the length of the 
normal vector is 0. (If the length of your 
"Cross" vector is greater than 0, then a
proper normal vector was formed.)


>       #local Errors = concat (Errors,"All points on same line\n")
>      #else
>       #local Errors = concat (Errors,"Inside point is on plane\n")
>      #end

But what if Point1, Point2 and Point3 are 
all on a line, while the "inside point" is 
not on the same line ?


>     #end
>     #warning Errors
>     sphere {<0,0,0>,0}  //Whatever called Four_point_plane is expecting an object.
>   #else
>     #local N = (STP > 0 ? -1 : 1)*vnormalize(Cross);// normal vector
>     plane { N, vdot(P1, N) }
>   #end // if
> 
> #end // macro Four_point_plane
> 
> //  Three_point_plane assumes that the origin is in the object.
> #macro Three_point_plane(P1,P2,P3)
>         Four_point_plane(P1,P2,P3,<0,0,0>)
> #end


Further notes:

If the STP test fails while the normal vector
is found to be "sound" (I.e.: The length of
your "Cross" vector is greater than 0), then
you can deduce from this that the "inside 
point" must also lie within the the plane 
defined by the 3 points: P1, P2 and P3. 

To see this, you may form a vector from the
"inside point" to any one of the other three
points. Now it might be easier to understand
that the only way the dot product between 
this vector and the plane's normal vector 
can be orthogonal to each other (I.e.: their
dot product equals zero) is if the "inside 
point" lies within that plane.



Also note that if you calculate the point-
to-point vectors several times, then this 
will probably slow down your macro bitte-
littegranne.

Post a reply to this message