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

"Matt Giwer" <jul### [at] ijnet> wrote in message
news:38CC8966.A65A6022@ij.net...
> 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'

Brrrr. Is that an intentional or unintentional example of horrible
programming with the help of goto?

Johannes.

Post a reply to this message

Matt Giwer <jul### [at] ijnet> wrote:
: 	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

  Actually 2 instructions are enough.

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

Mark Wagner <mar### [at] gtenet> wrote:
: #do
:   /* Do something */
:   #if(1 = 2)
:     #until(a = 3)
:   #end

: or

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


  Both of those should issue 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

Nigel Stewart <nig### [at] nigelscom> wrote:
: 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>

  Looks horrible.


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

Nigel Stewart wrote:

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

Please, NO!

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

In article <38CC8967.69CBD4F9@nigels.com>, nig### [at] eisanetau wrote:

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

Er, no offense, but that is extremely ugly syntax and just about 
unreadable. Add in looping, conditionals, variables(with arrays), and 
macros, and you have a real nightmare. It is going in the opposite 
direction I would like to see POV go. I think if this replaced 
POV-Script, people would go to other things instead, and if it was an 
option along with POV-Script, very few people would use it(even 
modellers would probably output in POV-Script for file size reasons).

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

Post a reply to this message

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

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

Implementation differences between POV and what? There is still only one 
parser currently available.
And we are talking about for loops, not the ++ operator. The ++ operator 
is well defined, no reason for debate over it, and most likely couldn't 
be applied to POV syntax without completely redesigning the variable 
syntax.
A #for(;;) loop is also well defined and quite possible with POV syntax.


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

Huh...what? POV doesn't have integer types, everything is a floating 
point number. And how would this be a debate?

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

Post a reply to this message