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