PoD wrote in message <38E4055B.5EA96B54@merlin.net.au>...
>Nigel Stewart wrote:
>>
>>         This is the basis of our misunderstanding.
>>
>>         POV script is good for what it is.
>
>What you seem to fail to understand is that POV is not a rendering
>engine, it is a scene description language.


I think I made a similar point in my original post.  The POV language is
tightly coupled to the rendering machine.  The rendering engine is part and
parcel of the whole caboodle, though.

I also made the point that the POV language has got it right from the point
of the artist, e.g. it enables people to sit at a text editor and construct
scenes which match their mental scenes.  Lovely.

>Try to replace the language (I know you're not) and you'll not only get
>howls of outrage from users,



>but you won't have POV any more.


This could descend into talk of semiotics and the nature of identity, but
let's not go there.

>Replace the rendering engine and it's still POV. If the new engine is
>faster and/or gives the better output, you'll be congratulated.
>
>Nobody really cares about the renderer except those who coded it.
>The lagnuage *IS* POV-Ray.


A controversial statement, this, although I appreciate the spirit of it.

At the risk of stating the obvious, POV is an inexpensive (as opposed to
cheap) raytracer, developed by some great people, with a delicately
structured language which allows you to raytrace scenes.  It has a good
reputation, and the POV community incorporates and rewards the work that
people put in to extend it and make it better.  But first and foremost it is
the cost and quality of the rendering engine that makes POVRay popular.
Making the language more complex, or more obtuse, would obviously diminish
both the reputation and popularity of POVRay.  But the best language on a
pathetic renderer would quickly cross the great firewall in the sky.

I agree with you that I don't care about how good the code is.  But it seems
a shame to tie both the language and the machine together like this.  What
are the real objections to allowing the rendering technology in POVRay to be
used in a way other than through the POV language?  I can see worries that
POVRay would become a library in some monolithic corporation's product and
this team not getting any credit for it.  I can see that the POV community
has effectively created and contributed to a brand, and doesn't want it to
be diluted.  Are these good reasons for tying language and renderer
together?

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

In article <38eb4be3@news.povray.org>, "Nick Drew" 
<hyp### [at] btinternetcom> wrote:

>     <forall subject="i" range="{0..360}">
>       <where expr="i%12 == 0">
>             <apply-in-sequence>
>                 <rotate>
>                     <vector>0,<valueOf select="i"/>,0</vector>
>                 </rotate>
>                 <transform t="t <830,60,0>"/>
>                 <scale s="1/830 1/60 0"/>
>                 <eval name="vestaTwist">
>                     <supply id="i" range="{0..90}"/>
>                  </eval>
>             </apply-in-sequence>
>         </where>
>     </forall>

*shudder*

-- 
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

> *shudder*

Yawn


--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Thoughts on XML and POVRay...

I have been away from POV-Ray for a while, busy with other things.  
So when I first saw this thread a while ago, I thought "Oh-oh, there goes 
the neighborhood!  Now what are they up to?"

  I agree with computer scientists such as Don Knuth and Ian Joyner, 
who have written extensively on programming languages - one of their
main points being that the scripts written in a well-designed language 
needs to be easy for humans to write and to read, even if it's ultimately
destined for the machine.   Software today has so much power to parse 
very complex languages, with very complex data models, there's no 
reason to design languages to make life easy for the computer.

  So what if the parser is complicated?  It needs to be written only once.
(Well, in an ideal world.)   If there comes  to be a need for several apps 
or utilities to parse the language, a parser can be written and packaged 
as a shared library or component.  

   A human-friendly language that is difficult to parse puts only a few
programmers temporarily at an inconvenience.

   An language that is easy to parse, but hard to for humans to deal with, 
puts many users at an inconvenience for a long time.    


The weakness about XML that worries me is that XML is designed to 
describe structure and meanings and properties of parts of that structures,
not process.   That may sound good for geometric models, which are 
structures with associated properties.  But 3D scenes have patterns in
there structures, often which can easily be described algorithmically - that
is,
by "how to" descriptions, rather than "what and where" descriptions.

Consider Postscript - a powerful way of describing where to put ink 
on a page.  Because it allows transformations, loops, and subroutines - and 
is in fact a general purpose programming language - it has a lot of power. 
Even at the most basic level, just about every text document involves letters
arranged serially left to right, and this is described easily by a process of
moving a "current point" according to letter  width, assumed by the
interpreter, but one can apply commands and define subroutines to make 
very complex documents.

  In contrast,  XML -- or HTML (since i am more familiar with it) merely 
says "This is a paragraph"   or "this is the radius".   It seems to me a
"verbless"
language, unable to say "Do this twenty times: ..."  Furthermore, it
describes the structure of the document it is a part of - as a markup
language, that
 exactly what it's for.  It does not describe well something else, outside its
 own file, as the proposed notion of having an XML script describe a
geometric model or complete scene.   

  Ultimately, symbols mean what you want them to mean. Of course it's
possible to use XML to describe scenes - just like it's possible to write ray
 tracers in COBOL.  But why?  *Possible* isn't enough for me - I want *easy,
elegant, effortless and enjoyable.*  

Perhaps XML would be useful as an intermediate language between 
programs, though I don't see how it would be a good choice.  There are
simpler ways to describe geometry, textures and scenes already in use.   
If someone wants to use XML, okay, but I dont' want to see it.

Eventually, of course the geometric model really does become a large number
of independent objects in POV-Rays data structures, suitable for hit-testing
and rendering.  It would be neat if POV-Ray could directly read this level
of data in - but i suspect XML would require much more effort than some
format that is command-oriented, saying in effect "Create Cylinder with 
radius=xxx, endpoints=..."  You know, with *VERBS*...

Are we seeing in this thread a contrast between POV-Ray users who are 
more mathematically minded - who usually prefer static descriptive 
models of things, using logical categories and relations, and those
who are deep down primarily artists - who perhaps prefer ACTION, 
MOTION and MEANING but don't mind trying describing these 
mathematically as pov script?

IMOH, we must cater to artists, not to parser writers.



Final thought:  What if the same argument for marking up scene files as 
XML were to be applied to  C++?  Syntaxic elements of C++ source 
files could be made into XML tags - what would that look like?  Would
anyone like that?   Scary...

*shudder me too*




Daren Scot Wilson
dar### [at] pipelineocm
www.newcolor.com
-- 
Daren Scot Wilson
dar### [at] pipelineocm
www.newcolor.com

Post a reply to this message

> Thoughts on XML and POVRay...

Daren,

I don't mean to disagree with the bulk of your argument,
but I'll persue a couple of points here for the sake of
discussion.

>   I agree with computer scientists such as Don Knuth and Ian Joyner,
> who have written extensively on programming languages - one of their
> main points being that the scripts written in a well-designed language
> needs to be easy for humans to write and to read, even if it's ultimately
> destined for the machine.  

LaTeX comes to mind as being roughly a Knuth style solution to
same kind of problem as HTML.  If history had been different,
all our web pages could have been built out of LaTeX documents,
but they arn't.  I like LaTeX, and I use it for quite specialised
things - but in a lot of cases the language is a bit mysterious
and behaves in unexpected ways.  For most jobs, I think HTML is
better because of it's simplicity.  LaTeX is good for it's
"macro" abilities, but HTML will prevail, perhaps because it is
more easily parsed and emitted by programs.  WYSIWYG is seen
as more user friendly than text-based editing with markup tags.
(LaTeX is roughly speaking a markup language)

> Software today has so much power to parse
> very complex languages, with very complex data models, there's no
> reason to design languages to make life easy for the computer.

If it means making exchange of data efficient, unambiguous and
robust - there is a case for making it easier for the computer.

>    An language that is easy to parse, but hard to for humans 
> to deal with, puts many users at an inconvenience for a 
> long time.

XML is not being proposed as being a replacement for hand-edited
scenes.

> The weakness about XML that worries me is that XML is designed to
> describe structure and meanings and properties of parts of that structures,
> not process.   

That's true - I'd prefer to see a pure data description, rather than
scripting or algorithms in an XML format.  

> Final thought:  What if the same argument for marking up scene files as
> XML were to be applied to  C++?  Syntaxic elements of C++ source
> files could be made into XML tags - what would that look like?  Would
> anyone like that?   Scary...

Providing that the source editor provided a good level of abstraction
from the XML representation - this would be quite a good way to develop
C++ software.  The concern should not be about what the low level
data looks like - think about rich functionality and ways of layering
useful views on top of that.
 
> *shudder me too*

Admittedly, XML is a paradigm shift.  People are pretty familiar
with hand editing text files.  But it's not the only way to get
things done.

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

Nigel Stewart wrote:

> Admittedly, XML is a paradigm shift.  People are pretty familiar
> with hand editing text files.  But it's not the only way to get
> things done.

For many of us it is the only acceptable way of getting things done.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Daren Scot Wilson wrote in message <38efe5cf@news.povray.org>...
>Thoughts on XML and POVRay...
>
>I have been away from POV-Ray for a while, busy with other things.
>So when I first saw this thread a while ago, I thought "Oh-oh, there goes
>the neighborhood!  Now what are they up to?"
>
>  I agree with computer scientists such as Don Knuth and Ian Joyner,
>who have written extensively on programming languages - one of their
>main points being that the scripts written in a well-designed language
>needs to be easy for humans to write and to read, even if it's ultimately
>destined for the machine.   Software today has so much power to parse
>very complex languages, with very complex data models, there's no
>reason to design languages to make life easy for the computer.

That's true.  We should design languages to make life easier for the
ultimate
end-user.  Who is the end-user of the POV rendering engine?  With the
current
POVscript, that's those people who want to hand-edit text files, although
there
are a group of artists who utilise modelling and animation tools which
export to
POV, and there are a group of artists who use POV as the destination of
bespoke
tools.

Let's make different languages suitable for different needs.

An additional point to the above is that choices made now impact future
developers.
While we can't predict the future, it is desirable to safeguard where
possible.  By
using a simple, extensible, parser, one can expedite the incorporation of
new ideas
with minimal fuss.   While you don't choose simplicity simply to make the
computer's
life easier, making future developers' life easier is a perfectly good
rationale.  I think
it would be wise to decide whether the current POVscript parser is suitably
robust.

>  So what if the parser is complicated?  It needs to be written only once.
>(Well, in an ideal world.)   If there comes  to be a need for several apps
>or utilities to parse the language, a parser can be written and packaged
>as a shared library or component.

This is a great minimal impact suggestion - would the terms of the license
allow such a shared library to be distributed free?  This would keep POV
a separate product, but I think it would need support from the POV team to
keep in line with changes to POV script.

Those users who wish to express POV using POVML,  POV++, etc, should
have input into the design of such a library.

>   A human-friendly language that is difficult to parse puts only a few
>programmers temporarily at an inconvenience.
>
>   An language that is easy to parse, but hard to for humans to deal with,
>puts many users at an inconvenience for a long time.

>
>
>The weakness about XML that worries me is that XML is designed to
>describe structure and meanings and properties of parts of that structures,
>not process.   That may sound good for geometric models, which are
>structures with associated properties.  But 3D scenes have patterns in
>there structures, often which can easily be described algorithmically -
that
>is,
>by "how to" descriptions, rather than "what and where" descriptions.
>
>Consider Postscript - a powerful way of describing where to put ink
>on a page.  Because it allows transformations, loops, and subroutines - and
>is in fact a general purpose programming language - it has a lot of power.
>Even at the most basic level, just about every text document involves
letters
>arranged serially left to right, and this is described easily by a process
of
>moving a "current point" according to letter  width, assumed by the
>interpreter, but one can apply commands and define subroutines to make
>very complex documents.


Postscript would obviously never be taken up as a hand-edited format, since
it has
been written with parsing simplicity in mind (a simple stack machine).
Considering
Postscript doesn't really add anything to your argument, although I take
your point
that Postscript is general programming language optimised for page layout.

One thing that you can say about PostScript is that it's a bloody pain to
work back from
a postscript document to the artist's original concepts.  If you look at the
evolution from
Postscript to PGML and then (merging with VML) to SVG, you'll see that
they've managed
to perform quite a successful balancing act between file size, readability,
extensibility, and
simplicity of implementation.

>  In contrast,  XML -- or HTML (since i am more familiar with it) merely
>says "This is a paragraph"   or "this is the radius".   It seems to me a
>"verbless"
>language, unable to say "Do this twenty times: ..."  Furthermore, it
>describes the structure of the document it is a part of - as a markup
>language, that
> exactly what it's for.  It does not describe well something else, outside
its
> own file, as the proposed notion of having an XML script describe a
>geometric model or complete scene.

I think this is a good point.  So far XML has needed an additional language
into which to escape to perform algorithmic processing - usually ECMA
script, Javascript,  or something like it.  Actually the choice of scripting
language is up to the
developer (and the target platform upon which the document will be
processed), and shouldn't
be a constraint upon the development of XML as a data modelling
language.  XML + XSLT + "AnyScript" is a pretty powerful combination.

This is a strong argument for generalising algorithmic commands out of
POVscript, allowing artists
to write loops and procedures in what ever language they wish, and requiring
the POV parser to
escape to another parser when necessary.

The incorporation of XML into POV is secondary, IMHO, to this separation
of scene primitives and algorithmic description.

>  Ultimately, symbols mean what you want them to mean. Of course it's
>possible to use XML to describe scenes - just like it's possible to write
ray
> tracers in COBOL.  But why?  *Possible* isn't enough for me - I want
*easy,
>elegant, effortless and enjoyable.*


I want the same.  I want it now, AND I want it in 5 years time.

>Perhaps XML would be useful as an intermediate language between
>programs, though I don't see how it would be a good choice.  There are
>simpler ways to describe geometry, textures and scenes already in use.
>If someone wants to use XML, okay, but I dont' want to see it.


>Eventually, of course the geometric model really does become a large number
>of independent objects in POV-Rays data structures, suitable for
hit-testing
>and rendering.  It would be neat if POV-Ray could directly read this level
>of data in - but i suspect XML would require much more effort than some
>format that is command-oriented, saying in effect "Create Cylinder with
>radius=xxx, endpoints=..."  You know, with *VERBS*...
>
>Are we seeing in this thread a contrast between POV-Ray users who are
>more mathematically minded - who usually prefer static descriptive
>models of things, using logical categories and relations, and those
>who are deep down primarily artists - who perhaps prefer ACTION,
>MOTION and MEANING but don't mind trying describing these
>mathematically as pov script?
>
>IMOH, we must cater to artists, not to parser writers.
>
>
>
>Final thought:  What if the same argument for marking up scene files as
>XML were to be applied to  C++?  Syntaxic elements of C++ source
>files could be made into XML tags - what would that look like?  Would
>anyone like that?   Scary...


I would love to be able to analyse my source code as XML documents.  This
would be a great step towards full literate programming - which of course
Don Knuth has been working towards for quite some time...

Nick Drew.

Post a reply to this message

291 posts and a month later, this thread is still going...

Amazing.

Mark

Post a reply to this message

Mark Wagner wrote:
> 
> 291 posts and a month later, this thread is still going...
> 
> Amazing.

What amazes me is with 291 posts it has managed to stay reasonably on
topic for so long. Seems to be popular topic for discussion.

-- 
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

> What amazes me is with 291 posts it has managed to stay reasonably on
> topic for so long. Seems to be popular topic for discussion.

	You betcha!

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message