In article <3a5fb073@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Why don't you just take the full step and remove all build-in solid 
> patterns from POV-Ray. Or maybe preserve them for 
> backward-compatibility, but at least generate a warning when used.

Speed, some patterns can't easily be done with the current function 
syntax, etc...


> That would be the logical extension of the philosophy that no new 
> patterns, no matter how general useful and powerful they are, can be 
> added to POV-Ray.

It would be, but what does that have to do with this? Nobody is 
following that philosophy...

-- 
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

Ron Parker wrote:

> Something I'd love to see in the parser, though perhaps it would be too
> confusing, is the ability to invoke macros using alternate syntax, so
> you could have macro invocations that looked more like first-class tokens.

I think that's a great idea, like a parser extention.

Actually, but this is probably going way too far, all the built-in patterns
and objects could be ripped out and put in external data files, then it would
be very easy to make new additions.

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

Post a reply to this message

Rune wrote:
> 
> Why don't you just take the full step and remove all build-in solid patterns
> from POV-Ray. Or maybe preserve them for backward-compatibility, but at
> least generate a warning when used.
> 

If the POVMan patch ever makes it to official, this would actually not be such a
preposterous idea ;)
But seriously, there are innumerable patterns that, while potentially useful,
can already be done with what's available. The question is more like - where to
draw the line? I'm not going to argue about the present case, but I hope you
agree it is not practical to hard-code every possible pattern into POV source.
It's inefficient and inflexible.
A standard, documented set of pattern macros should be easy for anybody to use,
and as a bonus one has the option of modifying them to suit his needs. I for one
do not have the programming skills to modify a built-in pattern, but I do have
the POV skills to tweak a macro.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

Rune wrote:

> Why don't you just take the full step and remove all build-in solid patterns
> from POV-Ray. Or maybe preserve them for backward-compatibility, but at
> least generate a warning when used.
>
> That would be the logical extension of the philosophy that no new patterns,
> no matter how general useful and powerful they are, can be added to POV-Ray.

Not as logical; backwards compatibility should try to be maintained. There has
to be some degree of permanence when these decisions are made. But that doesn't
mean it's too late to change future additions.

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

Post a reply to this message

Warp wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : I concluded I have absolutely no idea what it does, how to use it,
> 
>   So if you have a builtin pattern and you only know its name, you'll
> immediately know how to use it and what does it do?
>   What's the difference?

What I am saying is I don't have to look at the code to understand
how to use a pattern. I know how to use the granite pattern with
complete confidence yet I know absolutely nothing about noise
functions. I don't need to. Additionally a hard coded pattern
can be used with ease not only in pigments but also normals,
texture maps, and pigment maps. The use of a macro complicates
this process. Can you define a normal pattern with a macro ?
I don't recall that being possible. Even if it is possible is
it as easy as it is with a built in pattern ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken wrote:
> 
> Additionally a hard coded pattern
> can be used with ease not only in pigments but also normals,
> texture maps, and pigment maps. The use of a macro complicates
> this process. Can you define a normal pattern with a macro ?
> I don't recall that being possible. Even if it is possible is
> it as easy as it is with a built in pattern ?
> 

If (as in the present case) the macro returns a function, you should be able to
use it anywhere a regular pattern keyword can be used. I.e. if the macro is
something like:

#macro MyPattern()
  function{...}
#end

then any of these should work:

pigment{MyPattern() color_map{...}}
normal{MyPattern() normal_map{...}}
density{MyPattern() density_map{...}}

etc. etc.
You don't need to know what the function itself looks like, you just need to
know the name of the macro, and the purpose of its parameters. Both of which
will presumably be well documented if the macro is part of an official
distribution.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
> > [Removing existing build-in patterns] would be the logical
> > extension of the philosophy that no new patterns, no matter
> > how general useful and powerful they are, can be added to
> > POV-Ray.
>
> It would be, but what does that have to do with this? Nobody
> is following that philosophy...

Well, not you maybe, but others here certainly do...

Anyway, if it's just because you think my suggested pattern is not useful
enough, please tell me why the gradient pattern, with all its limitations,
is more general-purpose useful and powerful than the "band" pattern I'm
suggesting? And I could ask the same question for lots of the other
patterns.

Anyway I really hope you'll make that extension of the wave-types you were
talking about. It would mean that a single simple pattern could work as
gradient, planar, marble, my suggested pattern, and many more.
Another pattern could work as both onion and spherical.
Wood and cylindrical like patterns could also be achieved from the same
pattern. And so on...

This really would be more flexible.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3A5FD39A.10B10F70@pacbell.net>, lin### [at] povrayorg 
wrote:

> What I am saying is I don't have to look at the code to understand
> how to use a pattern. I know how to use the granite pattern with
> complete confidence yet I know absolutely nothing about noise
> functions. I don't need to.

Nobody said you would have to look at the macro code! There is no more 
reason for you to open the include and look at the macros than to poke 
around in the POV-Ray source code!


> Can you define a normal pattern with a macro ? I don't recall that 
> being possible.

It is perfectly possible...function patterns work fine in normals.


> Even if it is possible is it as easy as it is with a built in pattern?

Yes. Just use the macro the same way you would in a pigment.

-- 
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

In article <3A5FC075.C7B98698@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> I think that's a great idea, like a parser extention.

Maybe something like:
#keyword gradient2(Vect)
    // any pattern stuff...function {}, pigment_pattern, etc...
#end

This would add a new keyword with the "keyword keywordParameters" 
syntax. You would then use "gradient2 GradienVector" to use the pattern. 
Or maybe something like:
#block_macro MacroName(Parameters)
#end
This macro would be called like:
MacroName {Parameters}
instead of the usual parenthesis call.


> Actually, but this is probably going way too far, all the built-in 
> patterns and objects could be ripped out and put in external data 
> files, then it would be very easy to make new additions.

I've done something similar with a function include file that has 
functions for most of the patterns. Most of the functions are just 
pigment functions, but a few are implemented directly.

-- 
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

In article <3a604eff@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Anyway, if it's just because you think my suggested pattern is not useful
> enough, please tell me why the gradient pattern, with all its limitations,
> is more general-purpose useful and powerful than the "band" pattern I'm
> suggesting? And I could ask the same question for lots of the other
> patterns.

Well, first, I think the pattern waveform syntax could be extended to 
allow gradient to do both jobs, as you mentioned below. And anyway, 
"gradient" existed long before macros or function patterns...there 
weren't any better alternatives then. And for such a simple pattern, 
there aren't any real advantages to having it built-in, and several 
disadvantages.


> Anyway I really hope you'll make that extension of the wave-types you were
> talking about. It would mean that a single simple pattern could work as
> gradient, planar, marble, my suggested pattern, and many more.
> Another pattern could work as both onion and spherical.
> Wood and cylindrical like patterns could also be achieved from the same
> pattern. And so on...
> 
> This really would be more flexible.

Which is why I prefer it to adding yet another specialized pattern.

-- 
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 <chr### [at] maccom> wrote:
: Nobody said you would have to look at the macro code! There is no more 
: reason for you to open the include and look at the macros than to poke 
: around in the POV-Ray source code!

  This is exactly my point and exactly what I don't understand in Ken's
opinion.
  It seems like he thinks that he automatically knows how a builtin pattern
is used and what is its syntax, but he will not know the same things for
a macro.
  I just wonder how this can be possible. If someone tells me that there's
a builtin pattern called 'spiral2' in povray, I have not any idea what would
be its syntax or how it is used or how it will look like (I can guess from
the name, but will probably guess wrong in this case).
  What I make in this case is to look in the povray documentation how this
pattern is used and what does it do.
  How this differs from a standard macro goes beyond me.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Rune <run### [at] inamecom> wrote:
: Why don't you just take the full step and remove all build-in solid patterns
: from POV-Ray. Or maybe preserve them for backward-compatibility, but at
: least generate a warning when used.

: That would be the logical extension of the philosophy that no new patterns,
: no matter how general useful and powerful they are, can be added to POV-Ray.

  You are taking it to the extreme without reason.

  The point was that why implement in source code a pattern which can be
easily done with a macro, when it only would cause more problems than benefits?
A macro is just as easy to use as a builtin pattern and it has many advantages.

  However, not every pattern can be done with a macro (at least not with
the current megapov functions). For example mandel.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Rune <run### [at] inamecom> wrote:
: Anyway, if it's just because you think my suggested pattern is not useful
: enough

  Where did you get the idea that your suggested pattern is not useful enough?
No-one has said anything like that.
  Since when "useful things" are done in the source code and "less useful
things" with macros?

  Why do you think that Colefax's includes are not implemented in the povray
source code? Because they are not so useful?
  No, it's because there's no need to do it, and doing it would only make
more trouble than it's worth. There are more benefits for them being include
files than being part of the core renderer engine.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: Actually, but this is probably going way too far, all the built-in patterns
: and objects could be ripped out and put in external data files, then it would
: be very easy to make new additions.

  This is not the best solution with all patterns (or whatever). Some
patterns are difficult to make with functions/scripting. Other patterns need
to be very fast in order to be usable, and making them with the scripting
language would only slow them down unnecesarily (a script version could be
done for flexibility reasons, but it shouldn't be the default).

  In my opinion, a new pattern (or whatever we are making) should be a
macro/include if:
  - It's easy to do with the povray scripting language (not necessarily
easy to code, but I mean that you don't have to make serious compromises
for example between parsing/rendering times, memory usage, etc).
  - It's fast enough to be useful; it doesn't take too long to parse and
is pretty fast to render.

  It should be made part of the source code if:
  - It's very useful and generic (making something that perhaps 0.01% of
people might use makes no sense).
  - It's not possible to make with the scripting language (for example the
photon mapping feature or many fractal patterns), or it will be extremely
difficult to do and/or it will take lots of extra memory and time while
doing it in C would be fast and efficient (eg. something requiring dynamic
lists, trees, etc), or:
  - It is a lot faster made with C than with the scripting language.

  I mentioned in a previous article reasons to favor macros/includes when
possible and practical. It makes the development of POV-Ray easier.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Warp wrote:

>   This is not the best solution with all patterns (or whatever). Some
> patterns are difficult to make with functions/scripting. Other patterns need
> to be very fast in order to be usable, and making them with the scripting
> language would only slow them down unnecesarily (a script version could be
> done for flexibility reasons, but it shouldn't be the default).

Is there no way to make external patterns as fast as internal ones? That would
probably require major changes to the code though (if possible).

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

Post a reply to this message

In article <3A60C792.D0AC3B43@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Is there no way to make external patterns as fast as internal ones? 
> That would probably require major changes to the code though (if 
> possible).

You would basically have to include a compiler with the program...and 
rewrite it for each platform to produce code for each processor and do 
the same optimizations that the development environments used to produce 
POV on those platforms do.
Function patterns are fairly fast now, there isn't a lot of reason to go 
through all this. There are some optimizations that could be done, 
though.

-- 
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

David Fontaine <dav### [at] faricynet> wrote:
: Is there no way to make external patterns as fast as internal ones?

  Interpreted code can never be as fast as optimized machine code. You
always get some overhead.
  The interpreted code can be sometimes almost as fast as machine code,
but there is always a little overhead. Sometimes interpreted code is a lot
slower.

  The only way of making fastest possible "plugins" is to make them in C
(or some other similar compiled language) and compile them to DLL's or
something similar and making povray to support them.
  This has been discussed several times before and it's not a very good
option in povray.
  In a one-platform software (such as Moray) it's an excellent option.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

On Sat, 13 Jan 2001 15:24:34 -0600, David Fontaine wrote:
>Is there no way to make external patterns as fast as internal ones? That would
>probably require major changes to the code though (if possible).

Expect "major changes to the code" in version 3.5.  That's all I'm going to 
say, though, unless someone wants to make some official statement.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Expect "major changes to the code" in version 3.5.  That's all I'm going to 
: say, though, unless someone wants to make some official statement.

  You shouldn't have said that. Now you left us (me included) waiting
anxiously for the surprise... :)

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

David Fontaine wrote:
> 
> Ken wrote:
> 
> > Warp wrote:
> > >
> > > Ken <tyl### [at] pacbellnet> wrote:
> > > : Why go looking though a bunch of macro files
> > > : for a specific function when if can be hard wired into the program.
> > >
> > >   Let me think about some reasons why a macro would be better:
> >
> > And this is the exact response I expected from someone with advanced
> > mathematical and programming skills. You just don't get it.
> 
> I don't understand. If someone else has already programmed the pattern for
> you, what's the difference if it's a macro or hard-coded? From the user's
> perspective I would think it wouldn't matter, from the programmer's the
> macro solution is far better. It's not like you code fonts into a word
> processor.
> 
The main difference should be that there is (or ought to be) a help
page about the hard-coded pattern, whereas the documentation of 
macro are usually 'scarce'... (in fact, the documentation of any
include file is usually INSIDE the file itself... starting with
the povray standard include files for wood, gold, glass and so.)
Which means you have no chance to use an integrated search engine 
when you look for something : you have to know that it may exist
in an include file, open it and try to find what your looking for.

Post a reply to this message

Jérôme Grimbert <jer### [at] atosorigincom> wrote:
: The main difference should be that there is (or ought to be) a help
: page about the hard-coded pattern, whereas the documentation of 
: macro are usually 'scarce'...

  It doesn't have to be.
  If povray 3.5 includes a set of standard macros, I'm sure they will be
documented as any builtin feature.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Jérôme Grimbert wrote:

> > I don't understand. If someone else has already programmed the pattern for
> > you, what's the difference if it's a macro or hard-coded? From the user's
> > perspective I would think it wouldn't matter, from the programmer's the
> > macro solution is far better. It's not like you code fonts into a word
> > processor.
> >
> The main difference should be that there is (or ought to be) a help
> page about the hard-coded pattern, whereas the documentation of
> macro are usually 'scarce'... (in fact, the documentation of any
> include file is usually INSIDE the file itself... starting with
> the povray standard include files for wood, gold, glass and so.)
> Which means you have no chance to use an integrated search engine
> when you look for something : you have to know that it may exist
> in an include file, open it and try to find what your looking for.

You're missing the point, an 'official' macro could and would be documented
inside the povray help file just like a built-in pattern. User-created stuff
does sometimes lack good documentation, but that's not limited to macros,
'patches' can have it too.

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

Post a reply to this message

David Fontaine wrote:
> 
> Jérôme Grimbert wrote:
> 
> > > I don't understand. If someone else has already programmed the pattern for
> > > you, what's the difference if it's a macro or hard-coded? From the user's
> > > perspective I would think it wouldn't matter, from the programmer's the
> > > macro solution is far better. It's not like you code fonts into a word
> > > processor.
> > >
> > The main difference should be that there is (or ought to be) a help
> > page about the hard-coded pattern, whereas the documentation of
> > macro are usually 'scarce'... (in fact, the documentation of any
> > include file is usually INSIDE the file itself... starting with
> > the povray standard include files for wood, gold, glass and so.)
> > Which means you have no chance to use an integrated search engine
> > when you look for something : you have to know that it may exist
> > in an include file, open it and try to find what your looking for.
> 
> You're missing the point, an 'official' macro could and would be documented
> inside the povray help file just like a built-in pattern. User-created stuff
> does sometimes lack good documentation, but that's not limited to macros,
> 'patches' can have it too.
> 

<nitpick on>
Would you extend this documentation requirement also to the 'official'
texture definition? I would be interested to have the documentation
for the wood/glass/stones includes files (of 3.1g!).
(While you are at it, I'm also interested in the objects from
shape*.inc ... and I guess that every include file may be of
interest to at least someone, so that would make a lot of new 
pages)

<nitpick off>

<reality check>
Assuming that 3.5 is ready now (I HAVE NO CLUE ABOUT THAT, it's
only an assumption for this rhetorical question), how much delay 
would be introduced by the complete documentation of the official
include files ? 
One year or more, I guess...

Post a reply to this message

In article <3A63FDCB.16C5F746@atosorigin.com>, Jérôme Grimbert 
<jer### [at] atosorigincom> wrote:

> <nitpick on>
> Would you extend this documentation requirement also to the 'official'
> texture definition? I would be interested to have the documentation
> for the wood/glass/stones includes files (of 3.1g!).
> (While you are at it, I'm also interested in the objects from
> shape*.inc ... and I guess that every include file may be of
> interest to at least someone, so that would make a lot of new 
> pages)
> <nitpick off>

How much documentation do those require? They are just variable 
declarations. You include the file, put the variable in your code, and 
that's it...
Maybe the general use of the files should be described in the 
documentation, but the demo scene files do a better job of documenting 
them than a description of each individual texture and object would. 
("T_Green_Glass: A green glass texture. T_Dark_Green_Glass: A darker 
green glass texture. T_Blahblah_Glass: Another blahblah glass texture." 
etc, etc....)


> <reality check>
> Assuming that 3.5 is ready now (I HAVE NO CLUE ABOUT THAT, it's
> only an assumption for this rhetorical question), how much delay 
> would be introduced by the complete documentation of the official
> include files ? 
> One year or more, I guess...

If you are really pessimistic...I see no reason for writing and 
documenting the macro set to take a whole year. Even if you include 
documentation for the existing includes.

-- 
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

Jérôme Grimbert wrote:

> > You're missing the point, an 'official' macro could and would be documented
> > inside the povray help file just like a built-in pattern. User-created stuff
> > does sometimes lack good documentation, but that's not limited to macros,
> > 'patches' can have it too.
> >
>
> <nitpick on>
> Would you extend this documentation requirement also to the 'official'
> texture definition? I would be interested to have the documentation
> for the wood/glass/stones includes files (of 3.1g!).
> (While you are at it, I'm also interested in the objects from
> shape*.inc ... and I guess that every include file may be of
> interest to at least someone, so that would make a lot of new
> pages)
>
> <nitpick off>

Please read http://www.intrepidsoftware.com/fallacy/ss.htm

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

Post a reply to this message

David Fontaine wrote:
> 
> Jérôme Grimbert wrote:
> 
> > > You're missing the point, an 'official' macro could and would be documented
> > > inside the povray help file just like a built-in pattern. User-created stuff
> > > does sometimes lack good documentation, but that's not limited to macros,
> > > 'patches' can have it too.
> > >
> >
> > <nitpick on>
> > Would you extend this documentation requirement also to the 'official'
> > texture definition? I would be interested to have the documentation
> > for the wood/glass/stones includes files (of 3.1g!).
> > (While you are at it, I'm also interested in the objects from
> > shape*.inc ... and I guess that every include file may be of
> > interest to at least someone, so that would make a lot of new
> > pages)
> >
> > <nitpick off>
> 
> Please read http://www.intrepidsoftware.com/fallacy/ss.htm
> 

Interesting, but the main problem is to delimit the scope
of the documentation for a future release (whose code
and files is only known by the Team). 
Documenting ONLY the built-in has a big advantage: there
is no last minute addition/update and the Team can focus on
the code.
Moreover, there is few built-in and the syntax is usually
decided and fixed (with optional part too).
With macro, somes may want to make generic parameter
 (such as first argument is always a vector, the second a map,...)
 even when the argument is a non-sense for a specific macro,
whereas others may want a dedicated parameter list per macro.
and so on.

And back to the speed argument, if it is easy to do with a macro,
it's ok with me, especially if the macro avoid me to type a hundred line
(and moreover, allow me to easily perform quickly update to the 
scene [because I only need to modify the macro definition and not
the hundred of call to it]).
But if the pattern is really a basic one, even if it can be done with a 
macro, it may be worth to thing about having it built-in.
That's why I did the triangular and square pattern patch: I feeled it was
unfair to have only the hexagon pattern in 2D.

Post a reply to this message

Jérôme Grimbert wrote:

> Documenting ONLY the built-in has a big advantage: there
> is no last minute addition/update and the Team can focus on
> the code.

I can understand that to some extent, but is that not up to the POV-Team to make those
changes? They could easily say official add-ons will be modified and distributed by
the same routine the same as compiles.


> Moreover, there is few built-in and the syntax is usually
> decided and fixed (with optional part too).
> With macro, somes may want to make generic parameter
>  (such as first argument is always a vector, the second a map,...)
>  even when the argument is a non-sense for a specific macro,
> whereas others may want a dedicated parameter list per macro.
> and so on.

I don't think so. With MegaPOV and upcoming 3.5 functions, the macro can serve the
same exact purpose as a function and be used practically the same as a keyword. Most
of the built-in patterns don't even take parameters, for those that do they would be
analogous to function parameters and the number would depend on the pattern itself.
The only problem I can see is optional parameters (like you said), since there is no
macro overloading.


> And back to the speed argument, if it is easy to do with a macro,
> it's ok with me, especially if the macro avoid me to type a hundred line
> (and moreover, allow me to easily perform quickly update to the
> scene [because I only need to modify the macro definition and not
> the hundred of call to it]).
> But if the pattern is really a basic one, even if it can be done with a
> macro, it may be worth to thing about having it built-in.
> That's why I did the triangular and square pattern patch: I feeled it was
> unfair to have only the hexagon pattern in 2D.

I can see your points here. Yes, there are probably times when a built-in is a good
idea.
It would be nice of course if there was access to syntax coloring options (other than
assigning colors to categories), though I realize this is not POV's purpose.

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

Post a reply to this message