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