 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] mac com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
