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