 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 27 Mar 2000 19:38:41 +0100, Nick Drew wrote:
>I see no reason to add programmatic constructs, like loops and branches,
Am I missing something? Povray already has loops and branches.
hp
--
_ | Peter J. Holzer | Think of it as evolution in action
|_|_) | Sysadmin WSR |
| | | hjp### [at] wsr acat | -- Tony Rand in "Oath of Fealty"
__/ | http://www.hjp.at/ | by Niven & Pournelle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
:>I see no reason to add programmatic constructs, like loops and branches,
: Am I missing something? Povray already has loops and branches.
Thus, what he is saying is that they should be removed.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <38e1c093@news.povray.org>...
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>:>I see no reason to add programmatic constructs, like loops and branches,
>
>: Am I missing something? Povray already has loops and branches.
>
Forgive me my ignorance - I use POV in relative isolation from this
community (until now), and have
never required the use of loops and branches, and so I've never tried to
find out if it's possible. Of course,
I use flow control structures in my pov generators. I guess this reduces
the credibility of my discussion somewhat,
but hopefully not disastrously.
> Thus, what he is saying is that they should be removed.
I seem to be implying this but it's quite an emotive statement, so I need to
state my position. I am saying that
I'd like to see loops and branches raised out of the scene description
language, and be association I'm saying
legacy source files with flow control structures should be supported but
deprecated.
a lot to be gained by separating out the separate theoretical constructs,
especially when considering POV in 5 years. I feel the best separation is
that of declarative vs. procedural. The scene language should be
declarative, and programmers should be allowed to choose which ever
procedural language they wish to write the declarative part. I shudder when
I hear discussions of what syntax a "loop" construct should take. Why
choose?
The case for raising branches is less strong - after all a branch can be
considered both procedurally (i.e. what do I do next?) and declaratively
(e.g. under what conditions do I do this?).
Anyway, I think I'm moving away from my general point - that POV should
focus on making advanced rendering techniques available, and use the file
format to facilitate this. I think the POV team and community should focus
not on becoming a more general programming environment, but on better
linkage to programming environments.
There are a multitude of different ways to support this, but the constraints
are equally expansive, so I'm happy to leave that discussion to another day.
Cheers,
Nick Drew
HyperSpace Ltd,Birmingham Research Park, Edgbaston, UK, B15 2SQ
(e): hyp### [at] btinternetcom (t):+44 (0)121 414
7019
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nick Drew <hyp### [at] btinternetcom> wrote:
: I'd like to see loops and branches raised out of the scene description
: language
It's just easier and handier to them to be there. Just think about all
those outstanding include files and macros.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> : I'd like to see loops and branches raised out of the scene description
> : language
>
> It's just easier and handier to them to be there. Just think about all
> those outstanding include files and macros.
Yes, from a POV-script point of view, macros and stuff
are nice to have. But I think from a data-oriented
point of view, it's cleaner to leave them out and
leave it open to other language environments to do
algorithmic processing.
Therefore - XML is a data view. POV-script remains
as an alternative - a custom, text oriented POV
specific, and POV optimised platform.
The fact that you can include one from the other
keeps flexibility and a gentler migration path.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> Yes, from a POV-script point of view, macros and stuff
> are nice to have. But I think from a data-oriented
> point of view, it's cleaner to leave them out and
> leave it open to other language environments to do
> algorithmic processing.
After reading much of this thread, I still don't get the whole idea (or I'm
utterly dumb). I understand how it would be theoretically interesting to have
alternate language environments for POV (while keeping the regular one), more
suited to programming. I understand the current limitations of the POV script.
What I don't get is the ultimate purpose of the proposed changes. In other
words, apart the satisfaction of having a suitable programming language for
pov, what would it be useful for ? What could be done with that that you
cannot do by the current means, either with macros or by hacking the code ?And
who would use it ? After all, people who have enough programming background
can already have fun with the povray code, or they can have fun programming
utilities for it and they have had a lot of success doing it. Unless I'm
deeply mistaken, a well-written compiled utility developed in C++ will be
always faster and smoother than anything written in an interpreted language. I
can see, for instance, how POV would benefit from a plug-in system that would
allow programmers to develop extensions without the need to recompile the
whole code.
On the other hand, people who want to do professional graphics would rather
program to make RIB files, which is an industry standard (again, please
correct me if I'm wrong).
If someone can provide real-life examples of the benefits of such a
development, I'll be happy to be enlightened :-)
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If someone can provide real-life examples of the benefits of such a
> development, I'll be happy to be enlightened :-)
Let me just clarify - this particular thread is
Nick Drew's - not mine. I don't want to hijack his
train of thought, so I'll keep this explanation short
and uncontraversial.
The basic idea is to use XML as a way of exchanging
a POV scene between applications or tools without
the complexity of parsing and emitting POV script.
(Parsing in particular is difficult to do) One
possibility is that you'd be able to shift a scene
between different tools without having to translate
it between formats.
There is also a thread on povray.programming, if you're
interested.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> The basic idea is to use XML as a way of exchanging
> a POV scene between applications or tools without
> the complexity of parsing and emitting POV script.
> (Parsing in particular is difficult to do)
Ok, thanks. This makes sense to me.
> There is also a thread on povray.programming, if you're
> interested.
Unfortunately conversations in povray.programming are usually out of my
intellectual reach ! I'm more a .general sort of person.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38E0945A.DE23F827@nigels.com>, nig### [at] eisanetau wrote:
> > >Would you resent it or maybe even quit using the program completely ?
> >
> > No, since the real power is in the rendering engine, not the scene
> > desription language.
>
> Nick, I think your post is quite insightful and
> informative. This point about the "real power
> of Povray" is an extremely good point to consider.
A large part of the "real power of POV-Ray" is that it has a simple and
flexible scene description language that doesn't require other programs
to write and is simple to hand code. Drop that and make the description
language nothing but a file format, and you lose a lot of flexibility
and useability.
--
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38e1ec8b$1@news.povray.org>, "Nick Drew"
<hyp### [at] btinternetcom> wrote:
> Forgive me my ignorance - I use POV in relative isolation from this
> community (until now), and have never required the use of loops and
> branches, and so I've never tried to find out if it's possible. Of
> course, I use flow control structures in my pov generators. I guess
> this reduces the credibility of my discussion somewhat, but hopefully
> not disastrously.
So you just write a simple little program that outputs POV code whenever
you need objects created with programming constructs?
> I seem to be implying this but it's quite an emotive statement, so I
> need to state my position. I am saying that I'd like to see loops
> and branches raised out of the scene description language, and be
> association I'm saying legacy source files with flow control
> structures should be supported but deprecated.
Why?
So you want it to work in theory, but not in practice? :-)
Have you ever heard of the saying, "If it works, don't fix it!"?
Adding in features or changing the language to be more flexible and
useable are fine, but chopping out the most popular portions and making
the rest harder to hand code would be a big mistake in my opinion.
And if it is left in, why deprecate it?
> I think there is a lot to be gained by separating out the separate
> theoretical constructs, especially when considering POV in 5 years.
> I feel the best separation is that of declarative vs. procedural.
> The scene language should be declarative, and programmers should be
> allowed to choose which ever procedural language they wish to write
> the declarative part. I shudder when I hear discussions of what
> syntax a "loop" construct should take. Why choose?
Why should POV-Script be declarative and not procedural?
Not everyone who uses these constructs has access to programming tools,
knowledge, or the patience for creating POV utilities. Even for those
who do, it is often(usually?) easier and simpler to do it in POV-Script.
> Anyway, I think I'm moving away from my general point - that POV
> should focus on making advanced rendering techniques available, and
> use the file format to facilitate this. I think the POV team and
> community should focus not on becoming a more general programming
> environment, but on better linkage to programming environments.
This has the disadvantages of being more platform dependant, harder to
distribute "scene files", harder to learn to use, requiring external
programs to code scenes, and also a lot harder to offer support for. If
everyone is using their own language, that will break the POV community
into several different sections. Having just one POV-Script means
everyone can gain from experience of others and sharing information is
easier.
--
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
