 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 29 Mar 2000 23:00:31 +1000, Nigel Stewart 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.
>
> 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.
First let me say that I like XML (and I do hand-code it, and I also
think that vi is the best HTML-editor), but I think that omitting the
algorithmic elements of POV-Script in POVML (or whatever we would like
to call it) would be a mistake.
Consider this fragment of POV-Script:
#declare i = 0;
#while (i < 360)
object {
vesta
translate <830, 50+10, 0>
rotate <0, i, 0>
}
#declare i = i + 12;
#end
This puts 30 "vesta" objects in a circle of 830 pov-units radius.
If this would be converted to
<object name="vesta">
<translate><vector>830 60 0</vector></translate>
<rotate><vector>0, 0, 0</vector></rotate>
</object>
<object name="vesta">
<translate><vector>830 60 0</vector></translate>
<rotate><vector>0, 12, 0</vector></rotate>
</object>
.
.
.
<object name="vesta">
<translate><vector>830 60 0</vector></translate>
<rotate><vector>0, 348, 0</vector></rotate>
</object>
It isn't a circle of objects any more. These are 30 independent objects
which just happen to form a circle.
I do admit that I would prefer something like
<loop start="0" end="348" step="12">
...
</loop>
to
<set variable=i value="0" />
<while expr="i < 360">
...
<set variable=i expr="i+12" />
</while>
The latter doesn't really feel XMLish to me.
hp
--
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsr acat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Mar 2000 00:37:42 +1000, 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)
Yep. I can whip up a perl script which makes quite complex changes to an
XML file in a rather short time (the parser already exists, but I even
wrote my own (not quite conforming) in two or three evenings).
I never considered writing a POV parser in perl. It would be a major
project and by the time it is finished, POV 4.0 would be out and I could
start implementing all the new features ...
I haven't looked at parpov yet. If it really is a good, stable POV
parser and if it actively maintained, it could be used in a standalone
POV-Script -> POV-XML translator. The reverse direction is trivial.
A standalone translator would be good enough for me (I render szenes by
typing "make" anyway, and one rule more in my Makefiles doesn't matter),
and it would have several advantages:
* Independent releases from Povray. Code and Features can change as fast
as they need to, competing designs can exist at the same time. I think
this is important during early development.
* No POVray license. The POVray license is IMHO overly restrictive. I
would be very reluctant to put any of my code under that license.
* "One Tool for every job". I don't really see why POVray should be able
to read a load of different file formats. If it can read both
POV-Script and POV-XML, the next person will want it to read VRML or
DXF.
hp
--
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Nobody is suggesting this.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I do admit that I would prefer something like
>
> <loop start="0" end="348" step="12">
> ...
> </loop>
There are pros and cons. If you drag this into an
editor, and want to customise the 45th sphere -
it's going to get ugly.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So you just write a simple little program that outputs POV code whenever
> you need objects created with programming constructs?
Show us a "simple little program" to parse POV code.
> So you want it to work in theory, but not in practice? :-)
Not at all - Works differently in practice.
> Have you ever heard of the saying, "If it works, don't fix it!"?
The same could have been said about MSDOS.
I'm sure there were quite a few people hesitant
about giving up their command line. I heard
that punch-cards were a good technology too.
> chopping out the most popular portions and making
> the rest harder to hand code would be a big mistake in my opinion.
That scenario is not what is being suggested.
> And if it is left in, why deprecate it?
> Why should POV-Script be declarative and not procedural?
POV-Script should remain procedural, but perhaps
in the XML context it would be better to leave it
out. We're talking about an alternative, not
a replacement.
> > 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
An ANSI C compiled library is about as portable as it
gets. A Java wrapper to this API is also pretty portable.
> harder to distribute "scene files",
Distributing scene files isn't the only goal, what about the
images that come out at the end?
> harder to learn to use,
I find it harder to learn POV script than to use languages
that I'm already confortable with.
> requiring external programs to code scenes,
Entirely optional.
> and also a lot harder to offer support for.
You don't offer support for 3rd party apps anyway. I get
support for the compilers that I've bought.
> If everyone is using their own language, that will break the POV community
> into several different sections.
The POV community could use some diversification. :-)
> Having just one POV-Script means everyone can gain from experience
> of others and sharing information is easier.
The pov scripts that I write are of zero interest to anyone
else. My goal is usually the image, not an elegant scene
file.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38E2A34A.501545B8@nigels.com>, nig### [at] eisanetau wrote:
> > So you just write a simple little program that outputs POV code
> > whenever you need objects created with programming constructs?
>
> Show us a "simple little program" to parse POV code.
Who said anything about parsing? Read the part I was replying to:
"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.
Only POV generators were mentioned...
> > So you want it to work in theory, but not in practice? :-)
>
> Not at all - Works differently in practice.
How?
> > Have you ever heard of the saying, "If it works, don't fix it!"?
>
> The same could have been said about MSDOS.
> I'm sure there were quite a few people hesitant
> about giving up their command line. I heard
> that punch-cards were a good technology too.
So...loops, macros, and conditionals are things of the past, obsolete,
and not needed anymore?
> > chopping out the most popular portions and making
> > the rest harder to hand code would be a big mistake in my opinion.
>
> That scenario is not what is being suggested.
Yes, it is. Macros, loops, and conditionals are some of the most common
pieces of POV code, the suggestion was to remove them and leave POV as a
declarative language. Or did I misinterpret Nick Drew's message?
> > And if it is left in, why deprecate it?
> > Why should POV-Script be declarative and not procedural?
>
> POV-Script should remain procedural, but perhaps
> in the XML context it would be better to leave it
> out. We're talking about an alternative, not
> a replacement.
How would this "alternative" be useful? If it can be used with
POV-Script, you have to use a POV parser anyway. Otherwise, you can use
either one or the other, but not both. And you would be making more work
for the POV Team, who would have to support a separate language.
> > This has the disadvantages of being more platform dependant
>
> An ANSI C compiled library is about as portable as it
> gets. A Java wrapper to this API is also pretty portable.
POV-Script is even more portable...if there is a version of POV on that
platform, your script will run on it.(Unless your script uses certain
features like halo and the POV application is the wrong version, of
course.)
Not everyone who wants to use POV will want to install and learn to use
a C compiler to make their POV scenes. For those who do, just make a
library for outputting POV code! It isn't that hard to do, just tedious.
> > harder to distribute "scene files",
>
> Distributing scene files isn't the only goal, what about the
> images that come out at the end?
How would XML make the output better?
> > harder to learn to use,
>
> I find it harder to learn POV script than to use languages
> that I'm already confortable with.
Your point...?
It is always harder to learn a new language than to use the ones you
know, what do you expect?
I meant that it is easier to learn POV-Script than to learn Java, C,
C++, or others like them.
> > requiring external programs to code scenes,
>
> Entirely optional.
You have the option of staring at a screenful of tags trying to decipher
the underlying structure or using an external program, you mean?
> > and also a lot harder to offer support for.
>
> You don't offer support for 3rd party apps anyway. I get
> support for the compilers that I've bought.
Huh?
People will ask for help. They will expect it to be given to them. If it
is some kind of framework for use in C, C++, or Java, they will ask the
people who make it. If it is POV-XML, they will ask the people who make
it. Meaning the TAG and POV-Team.
And besides that, the POV-Team will have to support the actual
programming required.
3rd party apps are irrelevant, there is still a need for language
support.
Of course, you *could* do something like what I am going to attempt with
POV-CSDL, and make a separate translator program to go from POV-XML to
POV-Script. You could make the program open source, and the POV-Team
wouldn't have to support anything.
> > If everyone is using their own language, that will break the POV
> > community
> > into several different sections.
>
> The POV community could use some diversification. :-)
Not that kind. All that would do is add confusion.
> > Having just one POV-Script means everyone can gain from experience
> > of others and sharing information is easier.
>
> The pov scripts that I write are of zero interest to anyone
> else. My goal is usually the image, not an elegant scene
> file.
And nobody is ever interested in sample code for solving a problem or
showing how to use an advanced technique, right?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Show us a "simple little program" to parse POV code.
> Who said anything about parsing?
I keeps coming back to this issue which Nick Drew
is aware of - is POV input data, or a program?
Having programming is useful, but also imposes
limitations.
> > > Have you ever heard of the saying, "If it works, don't fix it!"?
> So...loops, macros, and conditionals are things of the past, obsolete,
> and not needed anymore?
They are not needed for the kind of flexibility
that is being proposed. It comes down to a
"is it a bug, or a feature?" argument.
> > That scenario is not what is being suggested.
> Yes, it is.
No it isn't, it is ingenuous for you to suggest so.
>Or did I misinterpret Nick Drew's message?
Perhaps. I think Nick is simply pointing out
that POV script can not be all things to all
people. Things like POV-SDML are a flawed
attempt at this kind of goal.
> How would this "alternative" be useful? If it can be used with
> POV-Script, you have to use a POV parser anyway. Otherwise, you can use
> either one or the other, but not both. And you would be making more work
> for the POV Team, who would have to support a separate language.
Nobody here is making work for the POV team.
Again, you're being intentionally misleading
to suggest it.
> > An ANSI C compiled library is about as portable as it
> > gets. A Java wrapper to this API is also pretty portable.
>
> POV-Script is even more portable...if there is a version of POV on that
> platform, your script will run on it.
POV-Script is portable in this sense, but not in the
sense that you can parse your data back from it.
It's a one way street, why not have the option of
a two way street?
> Not everyone who wants to use POV will want to install and learn to use
> a C compiler to make their POV scenes.
Of course not, and that is not what is being suggested.
> How would XML make the output better?
If it means I can do more in less time, the output
will be better.
> > I find it harder to learn POV script than to use languages
> > that I'm already confortable with.
>
> Your point...?
The point is there is no real need to tie people to
one language.
> You have the option of staring at a screenful of tags trying to decipher
> the underlying structure or using an external program, you mean?
Exactly. What's the problem? Don't like options?
> Of course, you *could* do something like what I am going to attempt with
> POV-CSDL
This POV-CSDL suffers limitations of it's own. Why would
anyone bother learning YAPL (yet another programming language)
if they had a choice to use whatever fits their environment.
> and make a separate translator program to go from POV-XML to
> POV-Script. You could make the program open source, and the POV-Team
> wouldn't have to support anything.
Personally, I wouldn't be involved in anything that came
under the current POV licensing terms. This problem
with support of POV is tied to the license.
> > The POV community could use some diversification. :-)
> Not that kind. All that would do is add confusion.
I think you underestimate the intelligence of people.
Cheers,
Nigel
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38E2CF09.D78C66BE@nigels.com>, nig### [at] eisanetau wrote:
> > > Show us a "simple little program" to parse POV code.
> > Who said anything about parsing?
>
> I keeps coming back to this issue which Nick Drew
> is aware of - is POV input data, or a program?
Neither, it is a scene description language. Partially input data,
partially algorithms for making input data.
> Having programming is useful, but also imposes
> limitations.
But removing it imposes even more severe limitations.
> > So...loops, macros, and conditionals are things of the past, obsolete,
> > and not needed anymore?
>
> They are not needed for the kind of flexibility
> that is being proposed. It comes down to a
> "is it a bug, or a feature?" argument.
What do you mean? This doesn't make any sense.
I don't see how loops, conditionals, and macros can possibly be
considered bugs. And the reason they were added is because there was a
need for them.
> > > That scenario is not what is being suggested.
> > Yes, it is.
>
> No it isn't, it is ingenuous for you to suggest so.
Yes, it is. Read the message! I went back to it yet another time, and
couldn't find any other way to interpret it.
> Nobody here is making work for the POV team.
> Again, you're being intentionally misleading
> to suggest it.
How could this be included in the official version without making extra
work?
I am not being misleading, you just aren't making any sense.
> > POV-Script is even more portable...if there is a version of POV on that
> > platform, your script will run on it.
>
> POV-Script is portable in this sense, but not in the
> sense that you can parse your data back from it.
> It's a one way street, why not have the option of
> a two way street?
This seems to be the only real advantage that POV-XML would have. But it
isn't that hard to write a parser that supports the basic object syntax.
Why not do that? Of course, it would be easier to use a separate file
format and just convert it to POV-Script, but you seem determined to
read POV files...
> > Not everyone who wants to use POV will want to install and learn to use
> > a C compiler to make their POV scenes.
>
> Of course not, and that is not what is being suggested.
Show me a way to compile an ANSI C library("An ANSI C compiled library
is about as portable as it gets.") without a C compiler.
If you weren't talking about using the library to generate a scene
somehow, what were you talking about?
> > How would XML make the output better?
>
> If it means I can do more in less time, the output
> will be better.
How could XML let you do that? The only thing it seems to be capable of
doing is letting you exchange data between programs, at the cost of
requiring programs to generate the data.
I don't see how requiring generator programs is any better from
requiring converter programs.
> > Your point...?
>
> The point is there is no real need to tie people to
> one language.
What?
> > You have the option of staring at a screenful of tags trying to decipher
> > the underlying structure or using an external program, you mean?
>
> Exactly. What's the problem? Don't like options?
I like the option of hand coding using procedural constructs like loops
and macros.(and in a way which is actually *readable*) This seems to be
lost in the POV-XML ideals.
> This POV-CSDL suffers limitations of it's own. Why would
> anyone bother learning YAPL (yet another programming language)
> if they had a choice to use whatever fits their environment.
Huh?
I know POV-CSDL has limitations, but I don't see how POV-XML would be
more limited than it is already if it was implemented in a similar
way.(as an external translator program)
> Personally, I wouldn't be involved in anything that came
> under the current POV licensing terms. This problem
> with support of POV is tied to the license.
What does the POV license have to do with this? You don't have to use
that license for a program that outputs POV code.
> > > The POV community could use some diversification. :-)
> > Not that kind. All that would do is add confusion.
>
> I think you underestimate the intelligence of people.
What does that have to do with anything I said?
If people are intelligent, they will find the right tool for the job. If
that means POV-Script, and POV-Script is replaced with POV-XML, they
will go find another tool. You could have POV-XML support embedded
POV-Script, but that makes the advantages of POV-XML meaningless, you
are back to writing a POV parser.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Mar 2000 10:43:54 +1000, Nigel Stewart wrote:
> The same could have been said about MSDOS.
> I'm sure there were quite a few people hesitant
> about giving up their command line. I heard
were?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ....... and POV-Script is replaced with POV-XML............
This is the basis of our misunderstanding.
POV script is good for what it is.
But it can't be all things to all people.
So don't get so upset about proposing an
alternative. There are ways of doing this
without having to support two formats -
it means having an API for POV.
> You could have POV-XML support embedded
> POV-Script, but that makes the advantages of POV-XML meaningless, you
> are back to writing a POV parser.
No, it doesn't. It just means that you can only
handle XML data with XML tools. POV script gets
ignored, but preserved - no problem.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
