 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A5FD39A.10B10F70@pacbell.net>, lin### [at] povray org
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: 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!
This is exactly my point and exactly what I don't understand in Ken's
opinion.
It seems like he thinks that he automatically knows how a builtin pattern
is used and what is its syntax, but he will not know the same things for
a macro.
I just wonder how this can be possible. If someone tells me that there's
a builtin pattern called 'spiral2' in povray, I have not any idea what would
be its syntax or how it is used or how it will look like (I can guess from
the name, but will probably guess wrong in this case).
What I make in this case is to look in the povray documentation how this
pattern is used and what does it do.
How this differs from a standard macro goes beyond me.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
: 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.
You are taking it to the extreme without reason.
The point was that why implement in source code a pattern which can be
easily done with a macro, when it only would cause more problems than benefits?
A macro is just as easy to use as a builtin pattern and it has many advantages.
However, not every pattern can be done with a macro (at least not with
the current megapov functions). For example mandel.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] inamecom> wrote:
: Anyway, if it's just because you think my suggested pattern is not useful
: enough
Where did you get the idea that your suggested pattern is not useful enough?
No-one has said anything like that.
Since when "useful things" are done in the source code and "less useful
things" with macros?
Why do you think that Colefax's includes are not implemented in the povray
source code? Because they are not so useful?
No, it's because there's no need to do it, and doing it would only make
more trouble than it's worth. There are more benefits for them being include
files than being part of the core renderer engine.
--
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 <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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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).
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).
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A60C792.D0AC3B43@faricy.net>, David Fontaine
<dav### [at] faricynet> 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).
You would basically have to include a compiler with the program...and
rewrite it for each platform to produce code for each processor and do
the same optimizations that the development environments used to produce
POV on those platforms do.
Function patterns are fairly fast now, there isn't a lot of reason to go
through all this. There are some optimizations that could be done,
though.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> wrote:
: Is there no way to make external patterns as fast as internal ones?
Interpreted code can never be as fast as optimized machine code. You
always get some overhead.
The interpreted code can be sometimes almost as fast as machine code,
but there is always a little overhead. Sometimes interpreted code is a lot
slower.
The only way of making fastest possible "plugins" is to make them in C
(or some other similar compiled language) and compile them to DLL's or
something similar and making povray to support them.
This has been discussed several times before and it's not a very good
option in povray.
In a one-platform software (such as Moray) it's an excellent option.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
