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