I remember my Atari had an Option key and a Help key.

Post a reply to this message

> : Can GOTO be far behind?
>
>   I don't think that goto will be needed. I do think that #break and #continue
> statements inside a loop would be handy.

What about using goto to break out of nested loops?
Brendan Ryan

>

>
> --
> 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 like POV-Ray's language style the way it is.  If I wanted to learn
something 500 times more cryptic, I'd learn BMRT.  I did try BMRT but found
it far too difficult.  The Pixar Renderman spec is very heavy reading and
difficult to understand.  POV-Ray on the other hand is easy to get a grip
on.

Post a reply to this message

Andrea Ryan <ary### [at] global2000net> wrote:
: What about using goto to break out of nested loops?

  I code in C++ as my job, and I have _never_ needed the goto statement.
I don't consider it the Evil keyword, but still I have never used it.

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

Hi,

John VanSickle wrote:
> 
> Or make it like C really is:
> 
> #for (whatever initialization you want;
>       condition to continue;
>       whatever update you want)
> 
> #end

Not exactly like C is!

I think if you want it like C then the syntax is:

#for (whatever you want;
      whatever you want;
      whatever you want)

as for in C and C++ you can do _anything_ in for-specification block,
even everything else than initialisation, break condition and update
code. You could even leave everything of the initialisation, break
condition and update code and do anything else.

Huuuuuuu. very ugly......

Yours Axel

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: I think if you want it like C then the syntax is:

: #for (whatever you want;
:       whatever you want;
:       whatever you want)

: as for in C and C++ you can do _anything_ in for-specification block,
: even everything else than initialisation, break condition and update
: code. You could even leave everything of the initialisation, break
: condition and update code and do anything else.

  Nope. You can't do anything there. For example you can't put other loops
in there or if-statements, etc.
  Also the second parameter has to have a value. For example calling a
function returning void is no good. The value is used to evaluate the
condition.

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

On 21 Mar 2000 09:26:56 -0500, Nieminen Juha wrote:

>  Also the second parameter has to have a value. For example calling a
>function returning void is no good. The value is used to evaluate the
>condition.

What is the value of the second parameter in 'for (;;)'?

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: What is the value of the second parameter in 'for (;;)'?

  This is a special case. The empty value is considered as true. But if
you try to make a function call returning void you will probably get an
error.

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

Ay, up.

Ken wrote in message <38C7685C.5A4F3A68@pacbell.net>...
>
>
>Greetings,
>
>  As we all know the language used by POV-Ray is not only easy to use
>but offers a lot of flexibility. There are often many ways to describe
>an object or attribute of an object because of the "looseness" of
>it's language.
>
><snipped/>
> What I do worry about though is the influence that the people who seek
>a more programmer like language may have for the mass of people that have
>no programming background but still enjoy using the program. It might
>be good for them in some circumstances but would it be good for everyone
>is not so cut and dried as it were.
>
>


This is quite interesting.  My feeling is that programming structures on the
POVray scene language are unnecessary.  I wonder whether we might be able to
abstract out the discussion a bit... I'm 99% programmer, 1% sculptor, so
forgive me if I sound patronising to anyone who is more balanced than me...

Firstly, when I think about a language, there is usually a target machine to
which it will be compiled/interpreted/translated - by "machine" I mean some
intermediate bytecode (e.g a Java virtual machine) or some interpreter (e.g.
BASIC, javascript, etc).

Secondly, I think about the linkage between this machine and the
expressiveness of the language.  For instance, if the target machine is
really good at adding numbers together, then how easy should it be to write
a program that adds numbers together?  If my machine deals with raytracing
scenes, then one would assume that you should be able to build scenes
relatively easily.  In any discussion of the language, there is always the
lingering thought that one is really talking about the machine behind it.
On POV this especially true, since the POV scene language is tied to the POV
renderering machine.

In this case, what does the underlying "machine" of POVRay do?  Say, 90% of
the syntax is there to represent a single, static, scene, consisting of
objects and their properties.  The power of the existing POVRay syntax is
that it allows one to build these scenes with the minimum of fuss.  The
defaults applied to objects are sensible, and seem to be based on knowledge
of common operations that an artist may want to employ at any one time.  The
fact that you can do the same thing lots of different ways (with respect to
scene description) is recognition that artists think about scene
construction in different ways.  Wearing my "artist" hat - a beret,
prehaps -  POV suits me very well.

The remaining ~10% of the syntax is to controlling the rendering machine
itself.  Most of this 10% is within the .ini file structure that controls
the rendering meta-process, but there are a few primitives for setting the
constraints under which rendering will be done (e.g. the Max_Level... type
properties).  The scene language is predominantly an artistic medium, the
ini file predominantly a programmers one.

Off hand (and I've probably used only 10% of the capabilities of povray) I
can think of only one construct in POV that is used both in the artistic
process, and the meta-process, and that's the 'clock' pseudo-variable.  This
is there to help a) the artist move from rendering single scenes to
rendering simple camera paths or time-variant properties, and b) the
meta-process render multiple, similar, frames more efficiently.  This is the
exception, rather than the rule, and it has a valid artistic rationale.

Wearing my "programmers" hat - suggestions welcome - I want to be able to
automate the process of scene generation.  I want to be able to express
ideas of scene construction in ways that I use in any most other aspects of
my wired life - loops, methods, branches, libraries.  Of these by far the
most important is support for libraries - if I can programmatically create a
sphere, than I only want to have to do it once.  I would argue that in order
to support this sort of construct, you would either need both a fully
fledged programming language, and/or access to the underlying rendering
meta-process.  The latter is not desirable - I believe it would cause
assumptions to be made about the underlying machine that may or may not be
true, and certainly wouldn't be robust.  The former is undesirable in that
there are already more than enough programming languages available to suit
ANY model of development or approach that one would care to take to express
3D scenes.

I think the povray language should stick to the current approach - add new
facilities to the scene language to enable artists more freedom to
experiment (and graphics-engine gurus more freedom to create staggering
effects), and to speedily express their ideas.  Any half-decent "hacker" can
use perl, visual basic, java, prolog, etc. to generate povray scene files.
I see no reason to add programmatic constructs, like loops and branches,
when these can so easily be handled by a "generating" program.   For the
cases where programmers wish to add complex "behaviour" to their scenes,
perhaps we chould discuss how to allow programmers easier access to the
povray rendering meta-process.  Particularly, I think it might be worth
defining an object model of the pov constructs, and allow access from java,
perl, etc. in a similar fashion to the XML community.

From the point of few of the more advanced animator, the looseness of the
syntax could be a problem, especially when working in teams, trying to
understand what another artist has encoded.  I think this is a valid
concern, and perhaps is similar to the problems faced by software developers
the world over.  I would certainly advocate a more structured, readable,
modularised POVRay scene language.

Perhaps a more object oriented approach would be suitable.  There are
problems with this - POVRay is essentially a transformational language,
rather than a modelling language - although I think they are surmountable.
Recognition of this mismatch actually provides a potential solution.  If we
separate out scene language primitives into objects (and their properties)
and transformations, then the choice of syntax for each set becomes much
more clearcut.  Actually deciding on the set of objects isn't
straightforward [is the position of an object a property or a
transformation?], but it certainly won't be tedious...

>So the questions I have are really for the non-programmer types out there.
>
>Would you have difficulty re-learning POV-Ray if it's language format
>changed ?

No, but I think there would be frustration if you changed the things I could
do "easily".

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



>P.S. I am not suggesting that the POV-Team is even considering changing
>     the language at this time. I am mearly trying to find out what the
>     mainstream users of the program think about this and if they really
>     like the way the syntax is currently structured.


I like the syntax, for certain tasks.  I would like a more structured syntax
too, so that a "generating program" is easier to write, but not at the
expense of the current syntax.

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

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

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

Post a reply to this message

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] wsracat               |   -- 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.

POV works in practice, but it doesn't work in theory ;¬].  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?

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?


> POV works in practice, but it doesn't work in theory ;¬]. 

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

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

-- 
   _  | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | 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

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

-- 
   _  | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | 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.

> > POV works in practice, but it doesn't work in theory ;¬].
> 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...


> > > POV works in practice, but it doesn't work in theory ;¬].
> > 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

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.

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.

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.

------
PoD.

Post a reply to this message

PoD wrote:

> Nobody really cares about the renderer except those who coded it.
> The lagnuage *IS* POV-Ray.

Yep !

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

> > The lagnuage *IS* POV-Ray.

The potential for POV-Ray is much more than POV script.

--
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 lagnuage *IS* POV-Ray.
> 
> The potential for POV-Ray is much more than POV script.

POV-Ray will always be defined by the language fed to the rendering
engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.

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

Ken wrote:

> Nigel Stewart wrote:
> >
> > > > The lagnuage *IS* POV-Ray.
> >
> > The potential for POV-Ray is much more than POV script.
>
> POV-Ray will always be defined by the language fed to the rendering
> engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.
>

It seems that what seems confusing to a few people here is that in other 3D
packages (and particularly the high-end ones) there is an apparently
clear-cut separation between the scene-design abilities and the rendering
ones. You often see pictures "created with A, rendered with B". This is
obviously a quite efficient way to do things, since you have the best of
both worlds.
However, POV is a free, amateur tool. AFAIK, people who use it usually don't
have much the choice when it come to scene design and rendering : it's
either POV or nothing at all. At best, some of us can afford commercial
utilities like Poser or Rhino. Those who can afford (or are willing to use
pirated versions of) Max or Softimage, or have enough programming skills to
use BMRT and learn the RIB specifications, have already done so.
So, for the rest of us who stick with POV, there's no particular reason to
make a difference between the language and the renderer, because it is the
intricate mixing of the two that makes the software usable in the first
place.
G.

Post a reply to this message

Gilles Tran wrote:
> 
> Ken wrote:
> 
> > Nigel Stewart wrote:
> > >
> > > > > The lagnuage *IS* POV-Ray.
> > >
> > > The potential for POV-Ray is much more than POV script.
> >
> > POV-Ray will always be defined by the language fed to the rendering
> > engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.
> >
> 
> It seems that what seems confusing to a few people here is that in other 3D
> packages (and particularly the high-end ones) there is an apparently
> clear-cut separation between the scene-design abilities and the rendering
> ones. You often see pictures "created with A, rendered with B". This is
> obviously a quite efficient way to do things, since you have the best of
> both worlds.
> However, POV is a free, amateur tool. AFAIK, people who use it usually don't
> have much the choice when it come to scene design and rendering : it's
> either POV or nothing at all. At best, some of us can afford commercial
> utilities like Poser or Rhino. Those who can afford (or are willing to use
> pirated versions of) Max or Softimage, or have enough programming skills to
> use BMRT and learn the RIB specifications, have already done so.
> So, for the rest of us who stick with POV, there's no particular reason to
> make a difference between the language and the renderer, because it is the
> intricate mixing of the two that makes the software usable in the first
> place.
> G.

The important destinction between POV-Ray and many of the commercial
packages is the fact that POV-Ray does not provide an integrated
modelling environment such as many of the programs you listed. It
never was intended to. It's language does however help in the quest
to describe an image and any number of external tools can help in
the process.

 One thing I still don't understand is why people want POV-Ray to
talk to other programs.

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

>  One thing I still don't understand is why people want POV-Ray to
> talk to other programs.

	Because there are all kinds of tasks that can't be
	solved with the current tools, and there is no
	technical reason that POV should be limited to
	one single "view" or "interface" to the rendering
	technology.

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

Post a reply to this message

On Fri, 31 Mar 2000 11:24:35 +0930, PoD wrote:
>The lagnuage *IS* POV-Ray.

This is a good point.

But somehow I don't think the POV-Ray team would be very happy if I
implemented a different renderer which uses the same szene description
language and called it POV-Ray.

	hp

-- 
   _  | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | 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

"Peter J. Holzer" wrote:
> 
> On Fri, 31 Mar 2000 11:24:35 +0930, PoD wrote:
> >The lagnuage *IS* POV-Ray.
> 
> This is a good point.
> 
> But somehow I don't think the POV-Ray team would be very happy if I
> implemented a different renderer which uses the same szene description
> language and called it POV-Ray.
> 

But if your renderer was better, you could release an unofficial version
and your renderer might even find its way into a future official
release.

PoD.

Post a reply to this message

><snipped/>
>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.
>

I agree.

How about a more declarative approach?  For simple loops where you can do
some range analysis (all tagnames/attributes are tentative):

    <forall subject="i" range="{0..360}">
<!--declare the range of i-->
        <where expr="i%12 == 0">
            <apply-in-sequence>
<!--not sure about this - see below-->
                <rotate>
                    <vector>0 <valueOf select="i"/> 0</vector>   <!--invoke
i within longhand rotate->
                </rotate>
                <transform t="t 830 60 0"/>
<!--use shorthand form where feasible
                <object use="vesta"/>
<!--assume vesta is mesh, as opposed to macro. see below-->
            </apply-in-sequence>
        </where>
    </forall>

The apply-in-sequence (or something like it) would be needed to avoid having
nested transforms like:

<rotate>
    <vector>...</vector>
    <transform t="...">
        <object .../>
    </transform>
</rotate>

This would be poor in the sense that the author could place the <vector> tag
pair after the <transform>.  To check for this the DOM traverser would have
to scan all children to extract the info it needed.  An event based XML
parser wouldn't be affected, though so the latter form is still viable.

I believe a suitable editor would be able to allow the user to edit this
shape by changing the expression in the <where> tag.  If you look at XSL,
they have the <xsl:choose> tag, which has <xsl:when> and <xsl:otherwise>
tags.  Take this idea and apply it to ranges of values rather than tag
patterns, and I think you've got a powerful

Macros are a bit trickier - to include a circle of circles you could a)
define a clause (a subroutine in procedural languages) which exposes a
variable, and then b) invoke the clause with a given range for the variable.

a)

    <clause name="vestaTwist">
        <expose subject="i" default-range="{0..360}"/>
        <forall subject="i">
            <where expr="i%12 == 0">
                <apply-in-sequence>
                    <rotate>
                        <vector>0 <valueOf select="i"/> 0</vector>
                    </rotate>
                    <transform t="t 830 60 0"/>
                    <object use="vesta"/>
                </apply-in-sequence>
            </where>
        </forall>
    </clause>

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

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

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,

Something to be avoided, sure, although it might be fun...;¬].

>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