 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Ken <tyl### [at] pacbell net> 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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Jan 2001 07:11:33 -0800, 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.
If the macro is provided with the release of POV you download and install,
you won't have to go looking for it (ideally) and you'll be able to use it
almost like any other keyword, modulo the slight performance hit someone
mentioned (and that we're working on fixing.)
Just because you *can* find and change the behavior of the macro doesn't
mean you have to. I'm sure plenty of people here use Chris Colefax's
macros without the slightest clue how they work, and there's no reason
why any other macro, particularly one that's included with the program,
wouldn't be the same.
But if you *want* to change the behavior, it's a lot easier if it's a
macro than if it's a keyword, and far more portable to other installations
of POV.
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.
The idea is that you then wouldn't have to remember whether the pattern
you want to use is implemented as a macro or a builtin, i.e. you use
"hexagon color, color, color modifiers" but you use "hextiles(mortar,
pigment, pigment, pigment, pigment) modifiers" or you use "sphere {center,
radius modifiers}" but you use "object {TorusSpline(radius, points, start)
modifiers}". But I'm not sure how to implement any of this cleanly at the
moment.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> Just because you *can* find and change the behavior of the macro doesn't
> mean you have to. I'm sure plenty of people here use Chris Colefax's
> macros without the slightest clue how they work, and there's no reason
> why any other macro, particularly one that's included with the program,
> wouldn't be the same.
When I saw this -
#macro Gradient2 (Vector)
#local FX=vnormalize(Vector).x;
#local FY=vnormalize(Vector).y;
#local FZ=vnormalize(Vector).z;
#local Len=vlength(Vector);
function {
min(1,max(0,(x*FX + y*FY + z*FZ)/Len))
}
#end
I concluded I have absolutely no idea what it does, how to use it,
nor do I stand any chance of modifying it with any predictable outcome.
However I understood exactly what Rune was asking for and delighted
at the thought of something basic but very useful being added to the
program that both new and experienced users could take advantage of.
I guess we cater to the mathematical and programmer elite these days
leaving the rest of us to play with solid colored spheres and boxes.
(sorry, cheap shot)
> 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.
What you propose is nothing short of extraordinary. I applaud your
thinking process. Now if you would just....
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Jan 2001 07:53:32 -0800, Ken wrote:
>When I saw this -
[snip macro]
>I concluded I have absolutely no idea what it does, how to use it,
>nor do I stand any chance of modifying it with any predictable outcome.
>However I understood exactly what Rune was asking for and delighted
>at the thought of something basic but very useful being added to the
>program that both new and experienced users could take advantage of.
The problem with that macro isn't that it's a macro. The problem is that
it's not documented. I'd say that even without documentation, you stand
a better chance of figuring out how it works than you would with a first-class
pattern that wasn't documented.
>What you propose is nothing short of extraordinary. I applaud your
>thinking process. Now if you would just....
I'm not sure how this was intended, so I won't reply except to ask what the
last part of the third sentence was supposed to have been.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> >What you propose is nothing short of extraordinary. I applaud your
> >thinking process. Now if you would just....
...make it possible.
--
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 <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?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> The problem with that macro isn't that it's a macro. The problem is that
> it's not documented. I'd say that even without documentation, you stand
> a better chance of figuring out how it works than you would with a first-class
> pattern that wasn't documented.
>
Since i originally wrote it, i'm probably the one to blame for that. I
did not write it as something complete, furthermore i was quite in a hurry
at that moment. Anyway, if you think it's useful for a macro collection,
i could describe it more detailed both for usage as well as how it works
internally.
Concerning the rest of the discussion, i think it's quite reasonable to
expect some basic programming skills from an advanced povray user, since
povray code *is* some kind of programming language. Furthermore most
povray users have some basic geometry knowledge.
Anyway i don't think that means everyone should be able to understand this
macro at the first glance, but i agree with all of the arguments Warp
mentioned. I also think that a typical povray user should be able to
teach him/herself how such a macro works using some basic math knowledge
or a math book from a local library and the povray documentation. On the
other hand if such a function is implemented in the povray source code
it's much more difficult to understand it by looking at it.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" wrote:
> I understood exactly what Rune was asking for and delighted
> at the thought of something basic but very useful being
> added to the program that both new and experienced users
> could take advantage of.
I'm glad you think that way too. And I even consider myself one of the
programmer types...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp, if it was up to you, would you remove all solid build-in patterns if
it wasn't for the backward-compatibility?
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 <3A5F287C.139688BB@pacbell.net>, lin### [at] povrayorg
wrote:
> I concluded I have absolutely no idea what it does, how to use it,
> nor do I stand any chance of modifying it with any predictable outcome.
What makes you think you would have better luck if it was in C, embedded
in the POV-Ray source code?
The user won't have to look at the macro, ever. They will just look in
the documentation, see it in the section on "Pattern Macros", and learn
how to use it in the same way they learn the built-in patterns. However,
someone who wants to know how it is done simply has to open an .inc file
and look at the appropriate macro. *They* are the ones who will see the
macro and want to modify it, not the ordinary users. The only thing they
will have to do is #include "patmacs.mcr" and put a macro call where
they would otherwise put a keyword.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
