 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> 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.
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.
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> 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.
[snip]
Yeah, most people don't know how to use camera{} before reading the docs either.
The macros would come with documentation. I don't see the problem.
As for modifying it, you don't have to, but at least it's possible this way. Are
you saying if it was hard-coded you could dl the source and recompile it more
predictably than with modifying a macro?
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
