|
 |
Axel Baune <aba### [at] neuro informatikuni-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
|
|
|
|
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
|
|
