> Poor little me, trying to carve out a name for myself in the wonderous
field
> of macros, and everyone has to go and use VanSickle's...
> Well I see yours is nice and lengthy compared to mine ;-)

Well, thanks to all three of you that presented a solution. I will now
proceed to try and decide which one to use, probably by testing which macro
parses quickest  :)

Post a reply to this message

"David Fontaine" <dav### [at] faricynet> wrote:
> If you want the math behind it I can give it to you :-)
> And if you want a second cone differenced out of it to smoothly connect
the
> interior as well, most of the work is already done.

I tried your macro, but it seems that the radius of the cone is slightly
smaller than it should be. There is a tiny visible edge at the connection
point when using highlights, and that same edge does not occur with
VanSickle's version.

Post a reply to this message

Hi

Sebastian Strand wrote:

> Well, thanks to all three of you that presented a solution. I will now
> proceed to try and decide which one to use, probably by testing which macro
> parses quickest  :)

Try this:

#macro TorusConnect(SP,SMaR,SMiR,EP,EMaR,EMiR)

  #local a=EP-SP;
  #local b=SMaR-EMaR;
  #local c=SMiR-EMiR;
  #local d=vdot(a,a);
  #local e=d+b*b;
  #local f=sqrt(d);
  #local g=sqrt(e-c*c);
  #local h=(f*g-c*b)/e;
  #local i=(f*c+g*b)/e;
  #local j=a/f;

  cone { SMiR*i*j+SP,SMiR*h+SMaR,(EMiR*i+f)*j+SP,EMiR*h+EMaR }

#end // macro TorusConnect

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Sebastian Strand wrote:

> I tried your macro, but it seems that the radius of the cone is slightly
> smaller than it should be. There is a tiny visible edge at the connection
> point when using highlights, and that same edge does not occur with
> VanSickle's version.

$%&%$&#!!!!!

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message

David Fontaine wrote:
> 
> Poor little me, trying to carve out a name for myself in the wonderous
> field of macros, and everyone has to go and use VanSickle's...
> Well I see yours is nice and lengthy compared to mine ;-)

I avoided using the trig functions.  I also made local copies of the
arguments, so that if the user passes an expression as one of the arguments,
that expression will be evaluated.  For instance, this macro

  #macro MyMacro(A,B) (A-B) #end

can be invoked this way:

  #local J=MyMacro(77*2,45*2-23*3);

which POV-Ray will evalaute as:

  #local J=77*2-45*2-23*3;

which is almost certainly *not* what the user wanted.

Regards,
John

Post a reply to this message

Hi John

John VanSickle wrote:

> I avoided using the trig functions.  I also made local copies of the
> arguments, so that if the user passes an expression as one of the arguments,
> that expression will be evaluated.

Will this also make it parse faster?

What if one uses () around the passed arguments when one uses them
in i.e. multiplications and divisions?

And if so, would it be sufficient to do this in the cone statement in the last
torus-connect macro i posted?

Like this:
cone { (SMiR)*i*j+SP,(SMiR)*h+SMaR,((EMiR)*i+f)*j+SP,(EMiR)*h+EMaR }

() around SMiR and  EMiR ...

By the way: Did you recognize any of the math in that macro?

Regards

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> John VanSickle wrote:
> 
> > I avoided using the trig functions.  I also made local copies of the
> > arguments, so that if the user passes an expression as one of the arguments,
> > that expression will be evaluated.
> 
> Will this also make it parse faster?

That depends on how much faster a label look-up is compared to the evaluation
of an expression.  Most of the time a single variable or a constant is being
passed.

> What if one uses () around the passed arguments when one uses them
> in i.e. multiplications and divisions?

Same effect.

> And if so, would it be sufficient to do this in the cone statement in the last
> torus-connect macro i posted?
> 
> Like this:
> cone { (SMiR)*i*j+SP,(SMiR)*h+SMaR,((EMiR)*i+f)*j+SP,(EMiR)*h+EMaR }
> 
> () around SMiR and  EMiR ...

Yes, the parentheses force evaluation of the argument so that expressions
can be passed without causing an error.  This is important if you are going
to had it out for other people to use.

> By the way: Did you recognize any of the math in that macro?

It appears to be the same calculations as what I posted, although I may
have taken an unnecessary root here or there.  I used long labels as the
arguments in the sample code so that people could tell which argument to
the macro was supposed to be the start point, the end point, etc., without
having to puzzle out the acronyms.  In a real .INC file I use shorter
labels that follow the naming coventions I use in all of my scene code.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

In article <38C9B210.6698DB45@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> ... I also made local copies of the arguments, so that if the user 
> passes an expression as one of the arguments, that expression will be 
> evaluated.  For instance, this macro
> 
>   #macro MyMacro(A,B) (A-B) #end
> 
> can be invoked this way:
> 
>   #local J=MyMacro(77*2,45*2-23*3);
> 
> which POV-Ray will evalaute as:
> 
>   #local J=77*2-45*2-23*3;
> 
> which is almost certainly *not* what the user wanted.

POV always evaluates the parameters, which is one of it's differences 
with C macros.
See this section in the manual: 4.2.8.3  Are POV-Ray Macros a Function 
or a Macro?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38C9B210.6698DB45@erols.com>, John VanSickle
> <van### [at] erolscom> wrote:
> 
> > ... I also made local copies of the arguments, so that if the user
> > passes an expression as one of the arguments, that expression will be
> > evaluated.  For instance, this macro
> >
> >   #macro MyMacro(A,B) (A-B) #end
> >
> > can be invoked this way:
> >
> >   #local J=MyMacro(77*2,45*2-23*3);
> >
> > which POV-Ray will evalaute as:
> >
> >   #local J=77*2-45*2-23*3;
> >
> > which is almost certainly *not* what the user wanted.
> 
> POV always evaluates the parameters, which is one of it's differences
> with C macros.
> See this section in the manual: 4.2.8.3  Are POV-Ray Macros a Function
> or a Macro?

Hmm, the docs back you up on this.  I guess that I do it this way because
it fixed a bug I had somewhere...

-- 
ICQ: 46085459

Post a reply to this message

John VanSickle wrote:

> I avoided using the trig functions.  I also made local copies of the
> arguments, so that if the user passes an expression as one of the arguments,
> that expression will be evaluated.  For instance, this macro
>
>   #macro MyMacro(A,B) (A-B) #end
>
> can be invoked this way:
>
>   #local J=MyMacro(77*2,45*2-23*3);
>
> which POV-Ray will evalaute as:
>
>   #local J=77*2-45*2-23*3;
>
> which is almost certainly *not* what the user wanted.

Bzz, wrong!
Run this code:

#macro Test(a,b) a-b #end
#render concat(str(Test(2*5,2*4-2*3),1,0),"\n")
sphere{0,1} //So POV doesn't whine

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message