|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | "Simon Adameit" <gom### [at] gmx de> wrote in news:3d9ac841@news.povray.org
> I dont see why one would want to use macros anyway in such a case.
50% shorten code ? in scene with many code as above it DO mater
-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | "Rafal 'Raf256' Maj" wrote:
>
> > I dont see why one would want to use macros anyway in such a case.
>
> 50% shorten code ? in scene with many code as above it DO mater
>
#declare blah=
something{}
#macro blah()
#end
How is that 50% shortened code?
Using declare has also some advantages macros dont have.
Afaik it needs less memory to use #declare than to use a macro if you are
going to use the thing several times and not only once.
Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | "Simon Adameit" <gom### [at] gmx de> wrote in news:3d9afacc@news.povray.org
> How is that 50% shortened code?
I don't understant ? The example is :
color_map {
  [0.0 colEye]
  [0.1 colEye]
  [0.11 colSkin]
  [0.5 colSkin]
  [1.0 colBlood]
}
// -----------
color_map {
  [0.0 colEye() ]
  [0.1 colEye() ]
  [0.11 colSkin() ]
  [0.5 colSkin() ]
  [1.0 colBlood() ]
}
// -----------
color_map {
  [0.0 color rgbft colEye]
  [0.1 color rgbft colEye]
  [0.11 color rgbft colSkin]
  [0.5 color rgbft colSkin]
  [1.0 color rgbft colBlood]
}
macro() Vs define is much shorter, macro() Vs macro is a little bit 
shorter, but on the other hand it's probably easy to implement
-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | Rafal 'Raf256' Maj <raf### [at] raf256 com> wrote:
>   [0.0 color rgbft colEye]
  Did you use the obsolete 'color' keyword there on purpose, just to make
it look longer than necessary?
-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp - Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | Warp <war### [at] tag povray  org> wrote in news:3d9b004b@news.povray.org
>>   [0.0 color rgbft colEye]
>   Did you use the obsolete 'color' keyword there on purpose, just to make
> it look longer than necessary?
uuuups ;)
sorry I realy chould check that before posting :(
-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | "Rafal 'Raf256' Maj" wrote:
>   [1.0 color rgbft colBlood]
>
You declare the color this way:
#declare Col=rgb<1,2,3>;
and then use it this way:
 [1.0 Col]
Using declared things is even shorter than calling the macro, so the only
thing that could but not always is longer is the definition. I dont
understamd why you use "color rgbft". To make things look how you want them
to?
 Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | In article <Xns### [at] 204 213  191  226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256  com> wrote:
> macro() Vs define is much shorter, macro() Vs macro is a little bit 
> shorter, but on the other hand it's probably easy to implement
The "rgbft" part is completely unnecessary, and even the "color" is 
optional. You are using the longest possible way to specify colors in 
your comparison. POV's syntax already allows you to make it as short as 
the shortest example you gave.
-- 
Christopher James Huff <cja### [at] earthlink  net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag  povray  org
http://tag.povray.org/ Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | In article <Xns### [at] 204 213  191  226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256  com> wrote:
> Would it be a big problem to allow syntax  :
> 
> #macro finWater1 reflection { .01 .2 } #end
> finish { finWater1 }
> 
> instead of  finish { finWater1() }
> 
> this is a small change [probably] and shorten syntax is more comfortable
It isn't such a small change...you seem to assume that about anything. 
I'm betting that POV uses the "(" to determine it is calling a macro or 
function, and it makes a very helpful visual indicator as well. Your 
version is shorter by one () pair...typing is not really any faster, and 
readability is much worse, you have no way to tell a macro call from a 
variable identifier. It also kills the possibility of passing a macro 
parameter as a parameter in some future version without some weird 
syntax.
Stop counting keystrokes, it is a stupid and useless exercise, and one 
you seem to be obsessed with.
> btw. this will make pov macros act more like C preprocesor macros
That isn't necessarily a good thing. POV macros are not C preprocessor 
macros.
-- 
Christopher James Huff <cja### [at] earthlink  net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag  povray  org
http://tag.povray.org/ Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | In article <Xns### [at] 204 213  191  226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256  com> wrote:
> and another request, in connection with previous post - keyword ignore
> that can be added to any object. It will 'kill' the object.
That is just idiotic. Comment out the stupid object!
-- 
Christopher James Huff <cja### [at] earthlink  net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag  povray  org
http://tag.povray.org/ Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  | 
|  |  | 
|  |  | Rafal 'Raf256' Maj wrote:
>"Rafal 'Raf256' Maj" <raf### [at] raf256 com> wrote in
>news:Xns### [at] 204  213  191  226
>
>> Would it be a big problem to allow syntax  :
>
>and another request, in connection with previous post - keyword ignore
>that can be added to any object. It will 'kill' the object.
>
>Why ?
>Simple - it's very usefull while i.e. 'debugging' scene - if I have object
>long at 100 lines like :
>difference { ... union { ... } merge { ... union { ... }
>  ...
>  ignore
>}
>addning / removing "ignore" is much faster then commenting all 100 lines or
>putting them into  #if (0) ... #end
If this is really an issue, couldn't you just #declare the object, then
comment out the call?  That is, instead of
sphere { <0,0,0>, 1 color Green ignore}
you'd write
#declare MySphere =
    sphere {<0,0,0>, 1 color Green}
object {MySphere} // to show it
//object (MySphere) // to hide it
With the added advantage that it's easy to abstract the object definition to
an #include file and then just use the call to include the object. Post a reply to this message
 |  | 
|  |  | 
|  |  | 
|  |  |  |  | 
|  |  |