Gilles Tran wrote:
> 
> Johannes Hubert wrote:
> 
> > And the "non-programmers" would get a language for which the manual
> > would actually be *thinner* than it is now, a language that is more
> > approachable and easier to learn (because frankly I think, that many of
> > you here who advocate POV-Script as an easy language to learn have lost
> > perspective a bit, since you alreay *know* POV-Script: sure, newbies
> > *can* learn POV-Script, but the language is far from being easy to learn
> > and could be much more so in my opinion).
> 
> It's obvious that there's a general consensus about the fact that the pov
> syntax,
> having evolved from a simple scene description language to a "programming"
> language has now problems of its own. And you're right, it was never easy to
> learn, and I know of people who downloaded pov and were scared right away.
> However, I think that the original construct "primitive transform texture",
> written in such a way, is very intuitive. I know of teachers who use it at
> school
> to teach maths to kids. I guess it's intuitive because it's close to actual
> language :
> "the sphere is big and blue".
> 
> My own ventures in OO programming and other advanced programming indicate
> that, though there's no discussion on the necessity of it when it comes to
> programming efficiency, it also requires a *much higher* level of abstract
> thinking.
> This may be natural to full-time programmers, but for many people
> (including me) these ways of thinking are extraordinary hard, if not
> impossible, to grasp. Many of the concepts discussed in this thread
> (or in the programmers' wish lists) are simply out of my intellectual reach.

Time to add my own two cents, I suppose.

The POV scene language is a bit of an engineering nightmare, since its
usefulness is more or less inversely proportional to its ease of use.
(As is usually the case with such things.) Fortunately for us, you're
not required to access *all* of the complexity to use the language; you
can define very simple scenes very easily without having to mess with
any of that "weird programming stuff".

I don't think we need to add a zillion ways of doing the same thing;
this is almost certainly the idea of some well-meaning but foolish
programmer who thinks that POV should look more like a "real language"..
as if he has the authority to decide what that is. What we DO need is
some polish. This is a raytracer meant for end users, not a
correspondence course in computer science. Either the package should
include a comprehensive set of tutorials (particularly on things like
isosurfaces, realistic skies and water, media, lighting techniques and
complicated crap like that), or it should be provided as a separate download.

And it would be nice if POV-Ray had some sort of plugin architecture so
that if someone wanted to hard-code a tree-generator or fur-generator to
save parsing time, rendering time, and/or memory, they could do it.
Patches could use the same architecture, since they would basically work
the same way (extension to the parser and some custom code to do the
actual work). It wouldn't prevent you from using #includes, and since no
casual user is going to be able to figure out how those things work
anyway, if it's that important to be able to modify the plugins, the
creators could always provide source code.

Finally, it's my opinion that the POV language is *already* OO. I would
love for anyone who disagrees to explain to me how

object
	{
	dimensions { foo }
	transformation { foo }
	texture { pigment { foo } }
	texture { pigment { foo } normal { foo } }
	whatever { foo }
	}

...is in *any* way fundamentally different from something like

object.dimensions = foo
object.transformation = foo
object.texture[0].pigment = foo
object.texture[1].pigment = foo
object.texture[1].normal = foo
object.whatever = foo

-- 
Xplo Eristotle
http://start.at/xplosion/

Post a reply to this message

In article <38CAA340.E350695A@pacbell.net>, lin### [at] povrayorg 
wrote:

> The Devil made me do it...

Uh-oh, you had better start running your self diagnostics and virus 
detection routines more often.


> Absolutely not. I have no patience for positioning 30,000 objects
> by hand in a GUI modelling program.

I said a tree *generator*...I didn't say anything about hand placing all 
the objects.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

True, but what if you had to type:

ediBatchFile->Text = ediBatchFile->Text + "There is more..";

wouldn't you like to have to type only:

ediBatchFile->Text += "There is more..";

you even don't have to copy & paste, then.

--
Regards,
Sander


Matt Giwer <jul### [at] ijnet> schreef in berichtnieuws
38C994D0.C4A06309@ij.net...
> OK. Any what is the value beyond saving a few keystrokes?
>
> The time required for extra keystrokes is the last thing that
> worries even the best of programmers.

Post a reply to this message

Chris Huff wrote:

> If you have a few features to request, then go ahead and request them!
> One of the reasons features are not added is that nobody says they want
> them. You way there are other things you would consider more important
> than syntax streamlining, what are they? You mention clouds, oceans,
> fur, etc but didn't really give much information on what you want to see.

Before we had many people doing patches, the common idea was to not
bother the pov-team with feature requests (and the pov-team is very shy,
for good reasons) and, in fact, most of what have appeared in the development
of pov were very logical improvements. The other problem is that
non-programmers can't tell what's possible from what isn't and may be afraid
to look silly.

Want some ideas ? I've got a trunk full of them...

Clouds : we don't have presently a good system to make them.
Apart the old bozo/granite method (which works
very well sometimes), the 2 current methods (media and multiple planes)
share the same problems : they take ages (forget about using them in large
resolution pictures), may look grainy and they're basically scene-dependent.
These methods have led to impressive pictures but they're very difficult to set
up.
However, I'm pretty sure that something like a cloud
pattern with its specialized parameters would do (think of the brick pigment).
It wouldn't need to interact with the environment (only with the light position

and color) and we wouldn't be able to fly through.
But it would be enough for all the scenes that needs a realistic sky background

that doesn't look too much painted over.
Of course, it would come with cloud structures (cumulus, cirrus etc.),
variable fluffiness, and maps for the most common cloud effects
(white bright clouds, storm clouds, sunset clouds,  silver lining etc), and it
could be animated. Several cloud layers could be added.

Ocean and water : some on-the-fly height-field generation would do, provided it

gives the proper aspect of a 3D ocean surface. Add a foam and spray ability
too...
It could be animated.

Tree generation : if someone has a PhD about this, it should be possible
to create a general purpose tree growth model (Cf PlantStudio for a general
purpose
plant model) whose parameters could be stored in text files (and provided
with the general pov distribution). There would be a tree fonction that would
call
the model parameters and be fed some variables :
tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)

Look at AMAP for instance
http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
Pov would then generate a mesh, but like in Nathan Kopp's implementation
of radiosity and photon map, you could save the optimized mesh between
sessions.

Other stuff :
- a specialized pattern for dirty walls and concrete. There's no way to
properly
add marks and splotches in a way that doesn't seem regular (unless you use
image_maps, or add layers and layers and layers)
- a way to project a pigment on a particular spot of an object (some sort of
decal ;
to do this with pov now it's necessary to cut out the part, apply the pigment
and reinsert the part)
- a improved brick pattern, that would allow for not-so-square bricks not
fouled up by turbulence
- a snake scales pattern (used directly, or through uv mapping)
- a cracks pattern (there's one in Leveller)

Hmmm. I guess that's enough wishful thinking for tonight !

G.

Post a reply to this message

>Of course, it would come with cloud structures (cumulus, cirrus etc.),
>variable fluffiness, and maps for the most common cloud effects


Variable fluffiness, that sounds so cool. =)

Ah, I'm to tired...


--ll

Post a reply to this message

In article <38CAC206.1E895C99@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> Before we had many people doing patches, the common idea was to not 
> bother the pov-team with feature requests (and the pov-team is very 
> shy, for good reasons) and, in fact, most of what have appeared in 
> the development of pov were very logical improvements. The other 
> problem is that non-programmers can't tell what's possible from what 
> isn't and may be afraid to look silly.

That is one of the things the TAG team is for, to get feature requests, 
filter out the outrageous, useless, or impossible ones(like, um, a 
graphical modelling interface as an example.), and let the POV-Team know 
this is a desired feature.


> Want some ideas ? I've got a trunk full of them...

Good, maybe some will get on my to-do list. :-)


> Clouds : we don't have presently a good system to make them.
> Apart the old bozo/granite method (which works very well sometimes), 

Actually, I kind of like wrinkles for clouds.

> the 2 current methods (media and multiple planes) share the same 
> problems : they take ages (forget about using them in large 
> resolution pictures), may look grainy and they're basically 
> scene-dependent. These methods have led to impressive pictures but 
> they're very difficult to set up.

Using media with method 3 sampling gets rid of the graininess and is 
faster(it is much like the old atmosphere or halo), and any method which 
does 3D clouds is going to be slow. You aren't going to get much faster 
than media method 3.


> However, I'm pretty sure that something like a cloud pattern with its 
> specialized parameters would do (think of the brick pigment).
> It wouldn't need to interact with the environment (only with the 
> light position and color) and we wouldn't be able to fly through. But 
> it would be enough for all the scenes that needs a realistic sky 
> background that doesn't look too much painted over. Of course, it 
> would come with cloud structures (cumulus, cirrus etc.), variable 
> fluffiness, and maps for the most common cloud effects (white bright 
> clouds, storm clouds, sunset clouds,  silver lining etc), and it 
> could be animated. Several cloud layers could be added.

Maybe just a general "sky" feature, which would replace(or enclose?) the 
current sky_sphere and rainbow.(I consider "background" to be a separate 
feature from these) You could add cloud layers, and adjust density, 
type, etc. Maybe also stars, nebulae, aurora's, etc. There would also be 
a "sun_light", which wouldn't illuminate the scene but would affect the 
clouds. This would greatly simplify that part of the feature.


> Ocean and water : some on-the-fly height-field generation would do, 
> provided it gives the proper aspect of a 3D ocean surface. Add a foam 
> and spray ability too...
> It could be animated.

Height fields using the pattern feature in MegaPOV can be animated. By 
"on-the-fly", do you mean parse-time or render-time? The "pattern" 
feature is parse-time, isosurfaces can be used to get render-time height 
fields. As for the foam and spray...I have been wondering what a 
particle system syntax could be like.


> Tree generation : if someone has a PhD about this, it should be 
> possible to create a general purpose tree growth model (Cf 
> PlantStudio for a general purpose plant model) whose parameters could 
> be stored in text files (and provided with the general pov 
> distribution). There would be a tree fonction that would call the 
> model parameters and be fed some variables :
> tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)
> 
> Look at AMAP for instance
> http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
> Pov would then generate a mesh, but like in Nathan Kopp's implementation
> of radiosity and photon map, you could save the optimized mesh between
> sessions.

"the result of tens of years of research in plant growth simulation."?
I think a growth simulating algorithm like this would be a little 
excessive. And what about different leaf types? And fruit/flowers/seed 
pods/willow branches?
The usual recursive growth algorithm should be enough, if you modify it 
so you can specify "avoidance regions" occupied by an object which the 
plant would grow around. Something like this:
plant {
    base_position VECTOR
    start_radius FLOAT
    recurse_depth INTEGER
    max_branches INTEGER // maximum number of times to branch per "node"
    branch_probability FLOAT
        //the probability the algorithm will branch at each "node"
    max_branch_angle FLOAT
    radius_scale FLOAT // the factor the radius decreases by each level
    direction VECTOR // specifies the direction growth starts in
    gravity VECTOR // causes the plant to grow against or with gravity
    gravity_change VECTOR
        // allows the gravity effect to change, so for example,
        // tips of branches grow upwards more than main branches
    random_seed SEED // allows you to get a specific plant
    leaf_object {...}
    trunk_texture {...}
    avoidance_object {...}
        // The plant will "grow" to avoid penetrating this object.
        // Use union here to avoid multiple objects.
}
Of course, there would be default values for all of these...


> Other stuff :
> - a specialized pattern for dirty walls and concrete. There's no way 
> to properly add marks and splotches in a way that doesn't seem 
> regular (unless you use image_maps, or add layers and layers and 
> layers)

My blob pattern could be useful for this, it is included in MegaPOV. You 
could hand place the splotches or make a macro or just a loop to create 
them automatically.


> - a way to project a pigment on a particular spot of an object (some 
> sort of decal ; to do this with pov now it's necessary to cut out the 
> part, apply the pigment and reinsert the part)

You could use the object pattern to confine the pattern to a specific 
place. The object pattern is included in MegaPOV. You might also be able 
to do what you want with the blob pattern.


> - a improved brick pattern, that would allow for not-so-square bricks not
> fouled up by turbulence

I don't like the brick pattern at all...I just use real bricks. :-)


> - a snake scales pattern (used directly, or through uv mapping)

Don't forget fish scales. I think this is possible with a combination of 
texture maps and repeat warp, or with function patterns, but a 
specialized pattern might be useful.


> - a cracks pattern (there's one in Leveller)

Hmm, have you tried agate? Or kinds of turbulence?
Or are you looking for a branching type of crack, that looks sort of 
like lightning? That could be done with the blob pattern and a macro or 
two.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

David Fontaine wrote:
> 
> Tor Olav Kristensen wrote:
> 
> > How about making the editor do the re-typing for the lazy ones?
> 
> 1) What if you want to change it later? You have to do it twice.
> 2) People can use whichever syntax they prefer.
> 3) If more and more fancy features are added to the editor it will consume more
> resources.
>    a) I'm not saying I don't like column-select and all that; very useful!
>    b) I don't like it when the computer modifies my work.
> 4) :-p

People can press whatever keys they like.

So if you preferred not to hit that function key, then the computer
wouldn't modify your work...

;-b

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Hmmm...Your for loops looks like c-syntax to me.

Would you suggest that one allowed similar things 
to be allowed in a for-loop declaration in the 
POV-language that one allows in C?

E.g. initialize several variables, call other 
functions/macros within the declaration itself etc. ?

If not, then I my opinion is that one should 
choose another syntax for the for-loop that doesn't 
make the users believe that the same rules applies 
as in C.

And: Wouldn't it be better that the control 
variable(s) in a for-loop is local to the for-loop?

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html


Chris Huff wrote:
> 
> In article <38C816BE.35E35A1C@hotmail.com>, Tor Olav Kristensen
> <tor### [at] hotmailcom> wrote:
> 
> > But what if the loop control variable is a vector that is shared
> > between several nested loops? (See my example macro below.)
> >
> > Would this be possible with nested for-loops?
> 
> It would be possible, but not necessarily the best way to do it.
> Something like this:
> 
> #macro ObjectSplit(Thing, Point1, Point2, nnv)
> // Cuts an object into several "box"-parts
> // Result is returned in an array of such parts
> 
>   //#local nnv = <nx, ny, nz>;
>   #local ThingArray = array[nnv.x][nnv.y][nnv.z]
>   #local dPoint = (Point2 - Point1)/nnv;
> 
>   #for(Cntv = <0,0,0>; Cntv.z < nnv.z; Cntv.z += 1)
>     #for(Cntv.y = 0; Cntv.y < nnv.y; Cntv.y += 1)
>       #for(Cntv.x = 0; Cntv.x < nnv.x; Cntv.x += 1)
>         #local ThingArray[Cntv.x][Cntv.y][Cntv.z] =
>           intersection {
>             object { Thing }
>             box { Point1 + dPoint*Cntv, Point1 + dPoint*(Cntv+Unitv) }
>           }
>       #end // for
>     #end // for
>   #end // for
> 
>   ThingArray
> 
> #end // macro ObjectSplit
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

>I particularly like the ideas posted above of adding the C-style FOR loops
and
>such.  I would find these particularly helpful as I am just getting my feet
wet
>with C programming and I could work on my C coding with POV.

I mentioned how great for-loops would be about a year ago. My idea was
rejected at the time. I personally prefer writing

#for(C,C<N,C++)
[block]
#end

to writing

#declare C = 0;
#while (C<N)
[block]
#declare C = C + 1;
#end

And I think that it would help a lot of code to look cleaner. What the heck,
why not make it so you write for-loops, but POV reads it in like a while
loop for its own internal purposes?

Post a reply to this message

>Like what? I really don't know what you mean...
>Do you want a goto statement or something?


<cringe> <shudder>

Post a reply to this message

In article <38C### [at] unforgettablecom>, 
inq### [at] unforgettablecom wrote:

> Either the package should include a comprehensive set of tutorials 
> (particularly on things like isosurfaces, realistic skies and water, 
> media, lighting techniques and complicated crap like that), or it 
> should be provided as a separate download.

Remember though, that POV-Ray is created by people in their free time. I 
wouldn't want them to delay the releases so documentation like that 
could be written. Maybe a basic manual which describes the features of 
the scene language, and which would be included with and updated for 
each release, and separate tutorials for skies, water, isosurfaces, and 
other "complicated crap", which could be released one by one after the 
main release. :-)


> And it would be nice if POV-Ray had some sort of plugin architecture so
> that if someone wanted to hard-code a tree-generator or fur-generator to
> save parsing time, rendering time, and/or memory, they could do it.
> Patches could use the same architecture, since they would basically work
> the same way (extension to the parser and some custom code to do the
> actual work). It wouldn't prevent you from using #includes, and since no
> casual user is going to be able to figure out how those things work
> anyway, if it's that important to be able to modify the plugins, the
> creators could always provide source code.

This is a nice idea, but would be nearly impossible to implement. An 
include/scene file is the closest thing to that which wouldn't require a 
large amount of effort to do. Remember that the solution would have to 
be cross-platform...a kind of "virtual machine" like Java might work, 
but would probably be a lot of work to write(although it could be much 
faster than ordinary script).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CAF26F.AF099263@hotmail.com>, Tor Olav Kristensen 
<tor### [at] onlineno> wrote:

> Hmmm...Your for loops looks like c-syntax to me.

Yes.


> Would you suggest that one allowed similar things 
> to be allowed in a for-loop declaration in the 
> POV-language that one allows in C?
> 
> E.g. initialize several variables, call other 
> functions/macros within the declaration itself etc. ?
> 
> If not, then I my opinion is that one should 
> choose another syntax for the for-loop that doesn't 
> make the users believe that the same rules applies 
> as in C.

I don't see any reason not to support the full C syntax(other than 
possible difficulty in supporting some things). The only differences 
would be the # in front of the keyword and a #end instead of a {} block.


> And: Wouldn't it be better that the control 
> variable(s) in a for-loop is local to the for-loop?

Hmm, I'm not sure here...I think it would be a good idea when considered 
alone, but no other variables are local to a loop or conditional. As far 
as I know, #local only affects include files and macros. Having a single 
exception made for the #for(;;) loop might not be a good idea.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38cb0321@news.povray.org>, "TonyB" 
<ben### [at] panamac-comnet> wrote:

> >Like what? I really don't know what you mean...
> >Do you want a goto statement or something?
> 
> 
> <cringe> <shudder>

:-)
Don't worry, I am definitely not suggesting that a #goto feature be 
added.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Ken wrote:

> Strangely the GOTO command is one of the few in Qbasic I ever understood
> how to use successfully... Imagine that !

Well, under Qbasic, the use of GOTO is probably much more needed.

Switch to something like Java, or Smalltalk, or lisp...

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Chris Huff wrote in message ...
>I still can't remember off hand whether no_shadow or shadowless is used
>for an object...the thinking in 3D was actually the easiest part for me.


I fixed that one in my personal version of POV -- either one can be used ;-)

Mark

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
>
>There is another alternative which is being discussed in 
>povray.off-topic which I am surprised hasn't been mentioned here: making 
>a new language, starting from the basics and ensuring a clean design, 
>probably similar to C(I suggested POV-CSDL, for POV C-like Scene 
>Description Language), and using a translator program to convert files 
>written in it to POV-Script files to be rendered. Programmer type people 
>

I was thinking about seperating the parser and the renderer, thus 
allowing multiple parsers, write you own parser using your own 
favourite programming paradigm. It could allow the ability to save 
a parsed script, so you could parse one day and render another, or pass 
the parsed file to someone else. Parse on one architecture, Render on 
another. Distributed rendering of animations by passing the parsed files 
of different times to different CPU's in a rendering farm.

Dave
-- 
Posted By NewsBe 1.6.3 Alpha
http://www.vargol.freeserve.co.uk/newsbe/ 
* I need a drink

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: From the viewpoint of a computer scientist (I'm one) this is a not a
: syntactically correct defiend for-loop. The variable of a for-loop
: belongs to the for-command and should be never _changable_ by the user. 

  Is there some reason to prevent the user from changing the loop index?
Why should flexibility of the language be delimited?

  As with all features: You don't have to use it if you don't want to. The
fact that a feature exists doesn't mean you have to use 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

Matt Giwer <jul### [at] ijnet> wrote:
: 	Introducing additional syntaxes raises more problems than it
: solves.

  I don't think so.
  A more compact and clearer syntax makes the code more readable and minimizes
the possibility of errors.
  For example, suppose you have this:

#declare XLoopIndex1 = 0;
#while(XLoopIndex1 < 100)
  ...
  (30 lines of code)
  ...
  #declare XLoopindex1 = nextValue();
#end

  When one reads the code he will most probably not remember the name of
the loop index after reading the 30 lines of code and the typing mistake
will most probably pass unnoticed. Povray will not issue any error since
there's no syntax nor semantic error. However, the parsing will perform an
endless loop.

  Compare it to this:

#for ( XLoopIndex1 = 0; XLoopIndex1 < 100; XLoopindex1 = nextValue )
  ...
  (30 lines of code)
  ...
#end

  Now since all the commands related to the loop index are at the same line,
noticing the typing mistake is more probable.
  Also understanding the functionality of the loop is much easier to see now,
since you don't have to search for the end of the loop to see how does the
loop index change.

  Also this new syntax would be very handy sometimes:

#do
  ...
#until(whatever)

  There really are times, where you want to execute the body of the loop at
least once before the ending condition is tested (for example the condition
is calculated in the body of the loop).
  With the current #while-loop you would have to calculate the condition
in two places: First before the loop, and then inside the loop. Copying the
same code to several places is not a good thing.

  In a similar way the +=, -=, etc. operators will allow to avoid copying of
code to several places (specially if the variable to modify is a very long
statement).

: 	Next, complex conditional if then else statements.

  What's this?

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

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

Ken wrote:
> 
> 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.
> 
>  Now many in the past have argued that it is too primitive for thier
> needs and suggest that it become more of an official programming
> language. They also suggest it should become more object oriented
> or stricter rules should be applied to the language from what it is
> now. Some say the syntax is too loose for all practical purposes.
> Some even suggest it should move to a binary format that needs to
> be compiled before being parsed (heaven forbid).
> 
>  I say the one thing that attracted me to POV-Ray was the fact that
> it's text based input was both easy to learn, was intuitive from the
> beginning, and I never had to learn a programmers language to use
> the program. I like the way that you can describe something in several
> ways to achieve the same results. In my opinion this loose and very
> flexible language makes it a very powerful program to use.
> 
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> Would you resent it or maybe even quit using the program completely ?

Ken, if I had to re-learn the language, then it would probably be a
fairly large inducement for me to change over to RenderMan. One of
the reasons I like POV-Ray is that it is much easier to use (and
has a quicker turnaround time, if you're using the procedural RI
API) than RenderMan. It's easier to get raytracing effects, too.
However, if everything I know about POV-Ray (and admittedly it isn't
as much as I'd like) were thrown out in the street, then I'd
look around.

Post a reply to this message

You are right.
  However I think there are some places where the use of goto (at least in
C and C++) is more or less reasonable:

- Case 1:

  for(cond1)
    for(cond2)
      while(cond3)
        if(skip) goto end_loops;

end_loops:
  ...

- Case 2:

recalculate_initial_values:
  make_some_calculations;
  for(cond1)
    for(cond2)
      while(cond3)
        if(wrong_values) goto recalculate_initial_values;

- Case 3:

  calculation1;
  if(error) goto end_calculations;
  calculation2;
  if(error) goto end_calculations;
  calculation3;
  if(error) goto end_calculations;
  calculation4;
  if(error) goto end_calculations;

  handle_results;

end_calculations:
  clean_up;


  However, I haven't needed the goto-statement in years, though (and I make
a LOT of C++ code). I can only deduce that usually goto is not needed.

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

Chris Huff <chr### [at] yahoocom> wrote:
: I think union could be used for this if the ability to bind variables 
: and macros to objects was added. I would also like to see a pointer-like 
: feature added(with checking for valid accesses, of course). I think this 
: is what you meant by "reference-type data types". Probably something to 
: think about for POV 4.0...(or 4.1) :-)

  Yes, a pointer type, but a limited one. More like a reference type in Java.

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

In article <38cb9a68@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   A more compact and clearer syntax makes the code more readable and 
> minimizes the possibility of errors.
>   For example, suppose you have this:
> 
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
>   ...
>   (30 lines of code)
>   ...
>   #declare XLoopindex1 = nextValue();
> #end
> 
>   When one reads the code he will most probably not remember the name of
> the loop index after reading the 30 lines of code and the typing mistake
> will most probably pass unnoticed. Povray will not issue any error since
> there's no syntax nor semantic error. However, the parsing will perform 
> an endless loop.

I suppose this is a good place to bring up another feature I have been 
thinking of. It has bothered me for some time that the same keywords 
that create variables are used to modify them, maybe a #set directive 
should be added. It would act exactly like #declare or #local, except it 
would produce an error if handed an undefined identifier. The keyword 
would always use the most local version of the identifier, of course, 
and local variables would stay local, and #declared variables would act 
as if you used #declare. This also would be backward compatible, 
#declare and #local could still be used to modify variables, it just 
would mean more typing, less clear code, and harder debugging.
That code would be rewritten:
#declare XLoopIndex1 = 0;
#while(XLoopIndex1 < 100)
  ...
  (30 lines of code)
  ...
  #set XLoopindex1 = nextValue();
#end
The #set would produce an error, since XLoopindex1 is not defined. And 
POV would not go into an infinite loop, and you could tell exactly what 
the problem was by looking at the error message.


>   Compare it to this:
> 
> #for ( XLoopIndex1 = 0; XLoopIndex1 < 100; XLoopindex1 = nextValue )
>   ...
>   (30 lines of code)
>   ...
> #end
> 
>   Now since all the commands related to the loop index are at the same 
> line, noticing the typing mistake is more probable.
>   Also understanding the functionality of the loop is much easier to see 
> now, since you don't have to search for the end of the loop to see 
> how does the loop index change.

This alone is a perfectly good reason for adding a #for loop, in my 
opinion.


>   Also this new syntax would be very handy sometimes:
> 
> #do
>   ...
> #until(whatever)
> 
>   There really are times, where you want to execute the body of the loop 
> at least once before the ending condition is tested (for example the 
> condition is calculated in the body of the loop).
>   With the current #while-loop you would have to calculate the condition
> in two places: First before the loop, and then inside the loop. 
> Copying the same code to several places is not a good thing.

I actually have run into this situation a couple times with POV. 
Debugging and extending two separate yet nearly identical chunks of code 
is *not* fun. This loop structure would probably be even easier to add 
then #for(), since it is basically a backwards #while() loop.


> In a similar way the +=, -=, etc. operators will allow to avoid 
> copying of code to several places (specially if the variable to 
> modify is a very long statement).

And maybe -- and ++ operators. I am really not sure about these, they 
don't exactly enhance readability except in highly compact code which 
you are unlikely to attempt in POV(all those # signs and #end's make the 
language too bulky to write highly compact code that is still readable). 
They probably would not be very useful, especially since I don't think 
separate prefix and postfix notations would be possible in the POV 
language(CSDL would be different, of course).


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

There is a #break statement for switch statements, and from the 
description, it doesn't seem like it would be too difficult to extend to 
#if statments and loops. Maybe even macros(have you ever wanted to jump 
out of a macro early?)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nieminen Juha wrote:

>   You are right.
>   However I think there are some places where the use of goto (at least in
> C and C++) is more or less reasonable:
>
> - Case 1:
>
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(skip) goto end_loops;
>
> end_loops:
>   ...
>
> - Case 2:
>
> recalculate_initial_values:
>   make_some_calculations;
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(wrong_values) goto recalculate_initial_values;
>
> - Case 3:
>
>   calculation1;
>   if(error) goto end_calculations;
>   calculation2;
>   if(error) goto end_calculations;
>   calculation3;
>   if(error) goto end_calculations;
>   calculation4;
>   if(error) goto end_calculations;
>
>   handle_results;
>
> end_calculations:
>   clean_up;

Of those, only case 3 looks like possibly decent use.  Case 1 and 2 look very
problematic.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Jon A. Cruz" wrote:
> 
> Ken wrote:
> 
> > Strangely the GOTO command is one of the few in Qbasic I ever understood
> > how to use successfully... Imagine that !
> 
> Well, under Qbasic, the use of GOTO is probably much more needed.
> 
> Switch to something like Java, or Smalltalk, or lisp...

I would rather fight than switch (I'll be that really dates me).

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

Chris Huff <chr### [at] yahoocom> wrote:
: There is a #break statement for switch statements, and from the 
: description, it doesn't seem like it would be too difficult to extend to 
: #if statments and loops.

  The #break-statement should NOT jump out of the current #if-statement, but
only out of the current #while-statement (and whatever else loop statement
this enhanced language would have).
  Why?
  Because usually you do this:

#while(whatever)
  ...
  #if(ending_condition)
    #break
  #end
  ...
#end

  It's obvious that if the #break just jumps out of the #if-statement, it
will be mostly useless.

  Unless...
  ... you could specify how many blocks do the #break jump out of. For
example:

#while(cond1)
  #while(cond2)
    #while(cond3)
      #if(cond4)
        #break(3)
      #end
    #end
  #end
  ...
#end

  Supposing that the #break also jumps out of the current #if-statement (and
it's counted as one block), the #break in this code will jump to the line
after the second last #end (ie. the line after the #while(cond2)-block,
marked with "...").

  Of course a simple #break that just jumps out of the current loop would be
mostly enough.

: Maybe even macros(have you ever wanted to jump 
: out of a macro early?)

  I don't know how this could be done. As far as I know, #macro is just
a text-replacement command. The macro call is just replaced with the body
of the macro with the parameters changed to their proper values.
  If you would #break a macro, it would mean that the body will literally be
broken, ie. with missing #end-statements (probably from the #if inside which
the #break was) thus causing problems to the parser.
  If macros were more like function calls, it would be more easier to add
a #return-statement.

  Now, that's an idea:

#function Abs(x)
  #if(x>=0)
    #return x
  #else
    #return -x
  #end
#end

  Hmm... Does this make sense? :)

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

>
> Of those, only case 3 looks like possibly decent use.  Case 1 and 2
look very
> problematic.

Java handles case 1 with a labeled break, doesn't it?

Johannes.

Post a reply to this message

In article <38cbd2ee@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   It's obvious that if the #break just jumps out of the #if-statement, it
> will be mostly useless.
> 
>   Unless...
>   ... you could specify how many blocks do the #break jump out of. For
> example:
...
>   Supposing that the #break also jumps out of the current 
>   #if-statement (and it's counted as one block), the #break in this 
>   code will jump to the line after the second last #end (ie. the line 
>   after the #while(cond2)-block, marked with "...").
> 
>   Of course a simple #break that just jumps out of the current loop would 
> be mostly enough.

Yes, that would be enough for just about anything. I guess I was 
thinking about Java-style multi-level breaks when I mentioned #if 
statements. I don't think they would really be needed in POV, but they 
might be a possibility in CSDL.


> : Maybe even macros(have you ever wanted to jump 
> : out of a macro early?)
> 
>   I don't know how this could be done. As far as I know, #macro is just
> a text-replacement command. The macro call is just replaced with the body
> of the macro with the parameters changed to their proper values.
>   If you would #break a macro, it would mean that the body will literally 
> be broken, ie. with missing #end-statements (probably from the #if 
> inside which the #break was) thus causing problems to the parser.

Wouldn't this problem with missing #end statements also occur with a 
loop? In both cases, there would probably be data in the parser that has 
to be reset.


>   If macros were more like function calls, it would be more easier to add
> a #return-statement.
> 
>   Now, that's an idea:
> 
> #function Abs(x)
>   #if(x>=0)
>     #return x
>   #else
>     #return -x
>   #end
> #end
> 
>   Hmm... Does this make sense? :)

I do like this better, since it works more like a function. But I am 
sure some people would consider it a needless complexity...maybe for 
CSDL though. :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: But I am sure some people would consider it a needless complexity...

  You are right. And I wonder why?
  If someone adds some new object, pattern or other feature, everyone praises
it and says "oohh... cool... great!". If someone even suggests adding something
to the syntax, everyone is immediately saying "no, no, no!".

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

Nieminen Juha wrote:
> 
> Chris Huff <chr### [at] yahoocom> wrote:
> : But I am sure some people would consider it a needless complexity...
> 
>   You are right. And I wonder why?
>   If someone adds some new object, pattern or other feature, everyone praises
> it and says "oohh... cool... great!". If someone even suggests adding something
> to the syntax, everyone is immediately saying "no, no, no!".

Like I said elsewhere you have a clear conflict between the Programmer
mentality and the User mentality. Programmers not only want to know how
it works but they also want to be able to force it to work as they want
it to.
  Users just want to be able to use it and don't care how it works. Users
want features that are easy to apply and the program takes care of the
details. Users want a big list of features to choose from without having
to do a big song and dance routine to get it to work.

Programming features are big song and dance routines !

That's how I see it anyway.

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

Nieminen Juha wrote:
> 
>  Now, that's an idea:
> 
> #function Abs(x)
>   #if(x>=0)
>     #return x
>   #else
>     #return -x
>   #end
> #end
> 
>   Hmm... Does this make sense? :)
> 

I like the idea of functions, but I suspect there would be a lot of
resistance to their introduction.
Why? they look rather like macros and people will get confused.  I'm not
saying people are dumb but a lot of POV users are not programmers and
might not appreciate the difference between macros and functions.

PoD.

Post a reply to this message

Sorry, I'm a coder. I can't do anything about 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

Ken wrote:
> 
> Gilles Tran wrote:
> 
> 
> Good point(s). What I also fear is that if the programming language
> is extended in POV-Ray to include OO programming, for () loops, and
> all of the other programming suggestions that have been addressed
> in this thread, is what is going to happen when some non programming
> literate POV-User comes to the news groups seeking help and some
> programmer type gives them an example in the form of these new
> features ? 

How many times have you seen someone ask 
"I have nested #while loops and the inner one doesn't work" ?
This is a problem that would go away with for() loops.

I fully agree that programming features are just a part of POV-Ray, but
who doesn't appreciate the efforts of people like Chris Colefax.  How
much more productive would such #include writers be with better tools?

I also don't think anyone is advocating that the POV-team drop
development of the render engine in favour of the programming interface,
we all want faster, more realistic  renders with more features ;^)

Cheers, PoD.

Post a reply to this message

Spend a minute thinking about the requirements for a POV-Ray L-system
(but make sure you're sitting down first)

PoD.

Post a reply to this message

PoD wrote:
> 
> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)
> 
> PoD.

Oops,
That should have been requirements for the syntax of POV-Ray L-system.

PoD.

Post a reply to this message

In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)

What about them?
I think it would be hard to understand unless you have experience with 
L-System scripts, but the POV syntax would be pretty simple. And a 
couple predefined objects and some macros for controlling l_system 
objects should probably be included...

Writing the actual l_system object would be much more difficult than 
deciding on a syntax.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> 
> > Spend a minute thinking about the requirements for a POV-Ray L-system
> > (but make sure you're sitting down first)
> 
> What about them?
> I think it would be hard to understand unless you have experience with
> L-System scripts, but the POV syntax would be pretty simple. And a
> couple predefined objects and some macros for controlling l_system
> objects should probably be included...
> 
> Writing the actual l_system object would be much more difficult than
> deciding on a syntax.
> 

Show me a simple syntax that lets you create a tree with different
textures for trunk, branches, twigs, leaves, fruit, flowers.
And has declarations of objects to use for the above.

I think that if the syntax was invented, then implementing it would be
simple.

PoD.

Post a reply to this message

Tor Olav Kristensen wrote:

> People can press whatever keys they like.
>
> So if you preferred not to hit that function key, then the computer
> wouldn't modify your work...

Okay, but what about 1, 2 and 3a? :-p

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message

Johannes Hubert wrote:

> >
> > Of those, only case 3 looks like possibly decent use.  Case 1 and 2
> look very
> > problematic.
>
> Java handles case 1 with a labeled break, doesn't it?
>
> Johannes.

Yes. Which is a bit different. Personally I try to avoid that also.
Among other things you might get a problem of buried meaning. Usually I
code first for correctness and clarity. Then if I get a performance
bottleneck, I go in, but only after measuring actual performance.

But also I usually don't do intense mathematical algorithms, so that may
be another factor.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Chris Huff wrote:

> In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
> wrote:

> >       So what is the difference other than a different syntax? The 123
> > ways to create a loop? They all do the same thing in the end.
> > Even step = 3 with I=I+3.

> >       Introducing additional syntaxes raises more problems than it
> > solves. With one elementary syntax that can do everything there
> > isn't nearly as much to read and a hundred fewer places for
> > parser differences to creep in.

> The only difference is syntax. But that is a meaningful difference.
> Although a for loop could also be implemented as a while loop, it can
> sometimes be easier to write and understand if written as a for loop. 

	Actually I would say it is usually more famliar which makes it
appear easier to understand. 
 
> And what do you mean by "a hundred fewer places for parser differences
> to creep in"? I don't think the modifications would be very extensive,
> and there is only one parser.

	I mean implementation differences. On an i++ while you can get a
debate started among purists as to while i < 5 should bail out or
4 or 5 in that should the < be checked before or after evaluating
and changing the variables in the loop. 

	You can get another debate on permitting i to be both integer
and float. 

	This stuff may be OBE since the late 70s when was being paid to
look into it perhaps due to the dominance of C or the later
developments of Wirth after Pascal. 

> >       Next, complex conditional if then else statements. Can GOTO be
> > far behind?

> Umm, we have if-then-else statements. And switch statements. And goto is
> a bad idea for many reasons.

	Without GOTO all branches are conditional to another routine.
Permitting GOTOs to exist after falling out of a routine simply
because it is sequencial is what we called spaghetti code. If you
have GOTO you have unconditional GOTOs. 

	They are nasty little buggers when they show up in late night
sessions. Never want to meet on in the dark. 

-- 
A free internet for free minds.

Post a reply to this message

Mark Wagner wrote:

> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.

	Does he use it in TWO algorithms? or just one? 

	And what is his overall opinion of it? 

	BTW: I think I went through that once and don't remember it.

	I do remember going through someone's Atari BASIC code once
trying to make sense of it. It was good. I even approached the
author with money for markeing if he could clean it up. 

	He said he could not clean up his own code as the GOTOs were
workarounds of things "too hard" to correct rigorously. And the
problem with that the possibility of added functionality was as
dependent upon his memory as his ability. 

	If his mind were off of it for a month, it was frozen code.

-- 
A free internet for free minds.

Post a reply to this message

Nieminen Juha wrote:
> 
>   You are right.
>   However I think there are some places where the use of goto (at least in
> C and C++) is more or less reasonable:

	To rephrase Case 1

> - Case 1:
 
label1:   for(cond1)
label2     for(cond2)
       while(cond3)
         if(skip) goto end_loops elseif (cond1) goto label1 
then goto label2;
 end_loops:

	Real quick and I won't swear to it, that should be look for kbd
'L' and then 'ogin' 

-- 
A free internet for free minds.

Post a reply to this message

> In all seriousness, object oriented would work very well for POV-Ray, since it
> models... objects!

Jon,

You havn't raised XML in this thread - I think it is quite an 
appropriate opportunity to talk about it.  People are used to
the HTML idea generally, but HTML has evolved into a bit of a
mess, so it may not be a great idea to suggest XML from this
viewpoint... (sigh)

Anyway, XML is a way of passing data which avoids the need
for a hard-coded parser in the application.  The "file format"
is editable, meaning that it can be extended quite easily
and that new tags for specific purposes do not crash parsers
that don't know what to do with the information.  Also,
somthing using XML would be familiar to anyone who's used
HTML or XML for something else. 

An example of what code may look like?

sphere { 
  <0, 0, 0>, 1
  pigment { Blue }
  translate -0.5*x  
}


Perhaps:

<POVSCENE>
  <SPHERE>
    <POSITION> 0,0,0 </POSITION>
    <RADIUS>   1.0   </RADIUS>
    <PIGMENT>
      <COLOR> BLUE </COLOR>
    </PIGMENT>
    <TRANSLATE> -0.5*x </TRANSLATE>
  </SPHERE>
</POVSCENE>

The question is, I suppose, whether all these TAGS would be 
intimidating to a new user, or someone who has spent a lot
of time learning the current scheme.

One thing to keep in mind is that editors could be a lot
smarter using XML than would be possible with a custom
file format.  It would be very easy to allow a tree-edit
style, rather than flat text.  It would also be easy to 
guarantee a well-formed scene without running it through
POV to see if it parses alright.

I guess that XML would imply something of a hybrid mode
of editing between flat text and 3D modelling, which could
possibly unify these two ways of doing things.  (I think
I could edit a tree-based editor without a mouse, but I
think a lot of the time I'd rather point-click and select
a colour, rather than typing "Orange", at the other extreme,
die hards that want to edit XML tags, are always free to
do so, without loosing the niceness of drag-and-drop, and
gatgets like that.)

What happens if we want to add new attributes to 
a sphere?  For example, for a gravity similation 
system we also want the mass of the sphere...
In this situation, you extend the definition for
POV XML, add a tag <MASS> which is allowed to
occur in the scope of <SPHERE>, and on the programming
side, add a field to store the mass and initialise
it from the XML intermediate data in the XML parser.
POVray without support for the <MASS> tag, simply
ignores it.

One implication is that there are probably other efforts
to figure out generic DTD's (XML based file formats) for
3D objects, which could form the basis for a POV DTD.
In fact, by making all of the POV specific stuff optional
extensions, you have a good chance of importing and
exporting without running you files through conversion
tools.

I'm no XML expert, but it seems to me that it should at
least be considered, considering the advantages of it.

A few limitations of XML that come to mind - the typing
scheme is limited to "weak typing" which means that really
any text can be inserted between tags, whether it's supposed
to be a floating point number, radius, vector, or whatever.
So POV would probably still barf sometimes.

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

> One implication is that there are probably other efforts
> to figure out generic DTD's (XML based file formats) 

Check out http://www.vrml.org/x3d.html, the working group
who are figuring out how to migrate VRML to XML.

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

Post a reply to this message

Matt Giwer wrote:

> Nieminen Juha wrote:
> >
> >   You are right.
> >   However I think there are some places where the use of goto (at least in
> > C and C++) is more or less reasonable:
>
>         To rephrase Case 1
>
> > - Case 1:
>
> label1:   for(cond1)
> label2     for(cond2)
>        while(cond3)
>          if(skip) goto end_loops elseif (cond1) goto label1
> then goto label2;
>  end_loops:
>
>         Real quick and I won't swear to it, that should be look for kbd
> 'L' and then 'ogin'

<shudder>

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Nieminen Juha wrote in message <38cb9a68@news.povray.org>...
>  Also this new syntax would be very handy sometimes:
>
>#do
>  ...
>#until(whatever)
>
>  There really are times, where you want to execute the body of the loop at
>least once before the ending condition is tested (for example the condition
>is calculated in the body of the loop).
>  With the current #while-loop you would have to calculate the condition
>in two places: First before the loop, and then inside the loop. Copying the
>same code to several places is not a good thing.


Adding this to the parser would be pure hell.  EVERY other code block in the
language ends with "#end", making it impossible to mismatch block the start
and end of a block.  However, a "#do...#until()" would allow constructs such
as:

#do
  /* Do something */
  #if(1 = 2)
    #until(a = 3)
  #end

or

#do
  /* Do something */
  #if(1 = 1)
    #until(a = 3)
  #end


The parser would need to be able to recognize this sort of construct and
then recognize that the first case will cause serious problems, but the
second one is fine.

Mark

Post a reply to this message

Nigel Stewart wrote:

> > One implication is that there are probably other efforts
> > to figure out generic DTD's (XML based file formats)
>
> Check out http://www.vrml.org/x3d.html, the working group
> who are figuring out how to migrate VRML to XML.
>

Arrrggg!!! Heelllppp!!!!

Run Away! Run Away!!!

Ok. sorry. it's not really all that bad. It's just that for many things,
VRML seems reaaaaaaaaaly ugly. Especially things like needing to
actually create a visible object before being able to reuse it, etc.

But, the big point of there being 3D XML efforts underway is a good one.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Nieminen Juha wrote:
> 
> Matt Giwer <jul### [at] ijnet> wrote:
> :       Introducing additional syntaxes raises more problems than it
> : solves.
> 
>   I don't think so.
>   A more compact and clearer syntax makes the code more readable and minimizes
> the possibility of errors.
>   For example, suppose you have this:
> 
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
>   ...
>   (30 lines of code)
>   ...
>   #declare XLoopindex1 = nextValue();
> #end

Make weird_indexname 
mark and copy weird_indexname

<CR><CR>

#declare weird_indexname - weird_indexname + whatever

	Then go back to the <CR><CR> and insert code. One does know what
one intends before writing one hopes. 

-- 
A free internet for free minds.

Post a reply to this message

Nigel Stewart wrote in message <38CC8967.69CBD4F9@nigels.com>...
>Perhaps:
>
><POVSCENE>
>  <SPHERE>
>    <POSITION> 0,0,0 </POSITION>
>    <RADIUS>   1.0   </RADIUS>
>    <PIGMENT>
>      <COLOR> BLUE </COLOR>
>    </PIGMENT>
>    <TRANSLATE> -0.5*x </TRANSLATE>
>  </SPHERE>
></POVSCENE>


This looks like the scene description language from DKBTrace:

OBJECT
 SPHERE <0 2 0> 1 END_SPHERE
 TEXTURE
  COLOUR RED 1 GREEN 1 BLUE 1
  PHONG 1
  DIFFUSE 0.1
  REFLECTION 0.9
 END_TEXTURE
END_OBJECT

OBJECT
 PLANE <0 1 0> 0 END_PLANE
 TEXTURE
  CHECKER
   COLOUR RED 1 GREEN 1 BLUE 1
   COLOUR RED 0 GREEN 0 BLUE 1
 END_TEXTURE
END_OBJECT

The equivalent POV code to this would be:

sphere{y*2, 1 pigment{rgb 1} finish{diffuse .1 phong 1 reflection .9}}
plane{y, 0 pigment{checker rgb 1, rgb <0,0,1>}}

Mark

Post a reply to this message

PoD wrote:

> I like the idea of functions, but I suspect there would be a lot of
> resistance to their introduction.
> Why? they look rather like macros and people will get confused.  I'm not
> saying people are dumb but a lot of POV users are not programmers and
> might not appreciate the difference between macros and functions.

	That is because they are macros. It just depends upon where the
result is put. 

	Everything in computing can be done with the minimalist set of
micro-code which actually gets down to four or five instructions
depending upon your side in the debate -- again, last I was
involved. Assembly calls microcode to deal with registers. 



-- 
A free internet for free minds.

Post a reply to this message

"Mark Wagner" <mar### [at] gtenet> wrote in message
news:38cc90a4@news.povray.org...
|
| The equivalent POV code to this would be:
|
| sphere{y*2, 1 pigment{rgb 1} finish{diffuse .1 phong 1 reflection .9}}
| plane{y, 0 pigment{checker rgb 1, rgb <0,0,1>}}

And with brace matching it's real nice, can't lose sight of what ends where.

Bob

Post a reply to this message