 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] povray org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 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:
>
>
> > > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 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:
>
>
> > > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
