Thorsten Froehlich wrote:
> The solution to the parse vs render time limits would be to make all
> features of a scene object replaceable by the user from within the language
> - i.e. even replace the intersection algorithm or the transformation
> computations. That would also put POV on-par with Renderman.

That would be rather neat.

Post a reply to this message

Fa3ien wrote:
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
> 
> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of implementation, etc...

I concur with the others - excellent idea.

-- Chris

Post a reply to this message

Christoph Hormann wrote:
> In short:  Simple tasks like a reflective sphere over checkered plane 
> need to be straight away to implement and to read - without knowing 
> about language concepts.  Like in the current SDL version of such a 
> simple scene the purpose of every token should be intuitively 
> understandable.  More complex features of the language would need to be 
> optional additions to this.

Putting this another way: POV-Ray's SDL grew from a simple means of
providing an object description to something that had many of the
traditional language constructs, while still retaining the ability to
define a scene in terms of objects with no 'programming' as such. This is a
Good Thing since it allows non-programmers to work with it and may have
been a significant factor in POV's acceptance.

Thus, I suspect it is desirable that any new 'official' SDL have the same
ability.

-- Chris

Post a reply to this message

Fa3ien wrote:
> Why not start some "laboratory" groups right now ?  I mean, public groups,
> where people could freely discuss many thing related to the future of POV-Ray,
> in a constructive manner.

I'm not opposed to this.

-- Chris

Post a reply to this message

William Tracy wrote:
> Yeah, I was curious if there were any actual .c files left. It sounds 
> like there isn't, but there's some code in the dark corners that only 
> halfway made it through the transition...

Even 3.6 has no .c files ... but 3.7 is much much (much) more object-
oriented. This was in part necessary due to the requirement to eliminate
(almost) all globals, as well as the fact that it's just easier to manage a
large codebase with you're dealing with encapsulated functionality.

-- Chris

Post a reply to this message

Chris Cason wrote:

> 
> Putting this another way: POV-Ray's SDL grew from a simple means of
> providing an object description to something that had many of the
> traditional language constructs, while still retaining the ability to
> define a scene in terms of objects with no 'programming' as such. This is
> a Good Thing since it allows non-programmers to work with it and may have
> been a significant factor in POV's acceptance.
> 
> Thus, I suspect it is desirable that any new 'official' SDL have the same
> ability.
> 
> -- Chris

Not even desirable, but, at least in my case, mandatory.
I know very little math and have no clue whatsoever about stuff like
isosurfaces and such, and absolutely no desire to learn a "real"[*]
programming language. What I do have however is a very good "internal eye"
which helps me see how I can create CSG-objects out of the primaries, box,
cylinder and sphere. With these limited resources I still manage to create
scenes with 100.000+ parts in it. I posted a mainboard render in 2005.


As an afterthought, while you guys are in the process of creating a new
language, please get rid of the "#" in front of some of the keywords. 
-- 
Ger

[*] With a real programming language I mean something that would resemble
C(++) or Object Pascal or ......

Post a reply to this message

Ger  wrote in message <46ef3fe7@news.povray.org>:
> Not even desirable, but, at least in my case, mandatory.
> I know very little math and have no clue whatsoever about stuff like
> isosurfaces and such, and absolutely no desire to learn a "real"[*]
> programming language.

I take the discussion somewhat in the middle, and maybe what I will write
has already been written:

There is not really a contradiction between a ""real" programming language"
and being able to write as simply as basic PoV SDL. For example:

use Colors;

scene [

  camera [
    location => [ 2, 5, -3 ],
    look_at => [ 0, 0, 0 ]
  ],

  light_source [
    [ 0, 10, -2 ],
    White
  ],

  union [
    box [
      [ -1, -1, -1 ], [ 1, 1, 1 ],
      pigment => Red
    ],
    sphere [
      [ 0, 1.5, 0 ], 0.5
      pigment => Yellow
    ]
  ]

]

I grant you that there is a little bit more comas than in original PoV SDL,
but on the whole, it is no more difficult to learn and to write.

Well, unless I am mistaken, this is perfectly valid Perl.

Post a reply to this message

Nicolas George wrote:

> 
> I take the discussion somewhat in the middle, and maybe what I will write
> has already been written:
> 
I may have put it into too strong words, but things like isosurfaces and
functions are gibberish to me


> There is not really a contradiction between a ""real" programming
> language" and being able to write as simply as basic PoV SDL. For example:
> 
> use Colors;
> 
> scene [
> 
>   camera [
>     location => [ 2, 5, -3 ],
>     look_at => [ 0, 0, 0 ]
>   ],
> 
>   light_source [
>     [ 0, 10, -2 ],
>     White
>   ],
> 
>   union [
>     box [
>       [ -1, -1, -1 ], [ 1, 1, 1 ],
>       pigment => Red
>     ],
>     sphere [
>       [ 0, 1.5, 0 ], 0.5
>       pigment => Yellow
>     ]
>   ]
> 
> ]
> 
This looks perfectly doable.

The contradiction between POV SDL and ARPL (A Real Programming Language) is
the possibility to do something like this

object { Thingy scale 2 #if(Big) * 3 #end }


> I grant you that there is a little bit more comas than in original PoV
> SDL, but on the whole, it is no more difficult to learn and to write.
> 
> Well, unless I am mistaken, this is perfectly valid Perl.

-- 
Ger

Post a reply to this message

Ger  wrote in message <46f1440d@news.povray.org>:
> This looks perfectly doable.

Thanks.

> The contradiction between POV SDL and ARPL (A Real Programming Language) is
> the possibility to do something like this
> 
> object { Thingy scale 2 #if(Big) * 3 #end }

Not necessarily:

object [ $thingy, scale => $big ? 2 : 6 ]

Post a reply to this message

"Nicolas George" <nicolas$george@salle-s.org> wrote in message 
news:46f1088f$1@news.povray.org...
> use Colors;
>
> scene [
>
>  camera [
>    location => [ 2, 5, -3 ],
>    look_at => [ 0, 0, 0 ]
>  ],
>
>  light_source [
>    [ 0, 10, -2 ],
>    White
>  ],
>
>  union [
>    box [
>      [ -1, -1, -1 ], [ 1, 1, 1 ],
>      pigment => Red
>    ],
>    sphere [
>      [ 0, 1.5, 0 ], 0.5
>      pigment => Yellow
>    ]
>  ]
>
> ]

I prefer the current syntax actually. All the commas after ] seem completely 
redundant, the keyword scene is a nice idea if it would be possible to 
define multiple scenes in one file, but it should be optional.
The line "use Colors;" seems completely out of place for two reasons: first, 
Colors what? Colors.inc ? Colors.pov ? ..? second, considering the rest of 
the syntax, wouldn't something like "include [colors.inc,textures.inc]" be 
more consistent?

I also don't like the change from curly brackets to square brackets.

Actually I think a new SDL should look more or less the same as the old one, 
ie. a C-like syntax, but with some new things, like cleaner syntax, OO, ...
For example: instead of '#declare X=1;' you would have something like 'float 
X=1;' (I don't think there's need for both int and float, since, afaik 
internally it's all floats).

However, there are many things in the current SDL that I actually like, 
although they might be considered weird by programmers.
For example, maybe it would be cleaner to have something like:

Camera ActiveCamera = new Camera();
ActiveCamera.location = new Vector(0,0,1);
ActiveCamera.lookAt = new Vector(0,0,0);

But it's a lot easier, especially for non-programmers, the way it is now:

camera {
    location z
    look_at 0
}

But well, I suppose making a cleaner, stricter syntax will always lead to 
having a more difficult to learn syntax :(

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message