 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a5fb073@news.povray.org>, "Rune" <run### [at] iname com>
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
|
|
| |
| |
|
|
|
|
| |
|
|
