Fa3ien wrote:
> andrel a écrit :
>> Interesting concept.
>> Trying to think of a situation where the presence of objects can only
>> be determined during a render...
>> Failing...
> 
> "trace" seems to me the most obvious example of "bi-directionality"
> between the rendering engine and the scripting language.
> 
> (yeah, it's not during a render, it's during parsing, but it relies on
> data (result of an intersection computation) which should be given by the
>  rendering engine)

Correct.

> Of course, that kind of feature could be extended to new possibilities, 
> such as the one evoked.
> 
> That's why, IMO, POV-Ray should been seen as a "rendering system", 
> instead of a "rendering engine fed by a script".

Exactly, though doing so on all levels is tricks with the current
implementation. I.e. that is why (isosurface) functions cannot access
declared arrays dynamically at render-time.

> This doesn't mean the rendering engine and scripting system can't be 
> separated at code level (being able to develop other complete or partial
> scripting languages would be great), but whatever interfacing system
> (bytecode, etc..) takes place MUST be able to manage that kind of
> bi-directonality.>

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.

	Thorsten

Post a reply to this message

Le 14.09.2007 17:13, William Tracy nous fit lire :
> Fa3ien wrote:
>> "C++ school" (where knowlegeable programmers would supervise
>> motivated, but less knowledgeable ones
> 
> Just curious, as someone who has never really looked at the POV code
> (yeah, I should really find this out myself): Is POV all C++ by now, or
> is there any actual C code left?
> 
Have a look for yourself when source available.
In 3.6, it's just C in C++ disguise.
No clean object classes, No metaclasses, no hierarchies.


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Have a look for yourself when source available.
> In 3.6, it's just C in C++ disguise.
> No clean object classes, No metaclasses, no hierarchies.

  3.7 might not be perfectly-designed C++ because it still drags so
much code from 3.6, but much better.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Le Forgeron <jgr### [at] freefr> wrote:
>> Have a look for yourself when source available.
>> In 3.6, it's just C in C++ disguise.
>> No clean object classes, No metaclasses, no hierarchies.
> 
>   3.7 might not be perfectly-designed C++ because it still drags so
> much code from 3.6, but much better.

:-)

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

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

"Jérôme M. Berger" <jeb### [at] freefr> wrote:
 > >  - Type 0 are tesselated dynamically during render time and the
 > > tesselation results are discarded immediately once the intersections
 > > are found. In particular, I noticed that POV accessed the u_order
 > > and v_order variables and repetitively called the DeCasteljau
 > > subdivision functions during intersection computations...

I see.

     -- Warp

Post a reply to this message

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

Nicolas George wrote:

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

That's basically the same as

object { Thingy
         #if (Big)
                scale 6
        #else
                scale 2
        #end
        }
but that's not what I meant. In POV SDL it is possible to put an "#if #end"
construct just about any place to include/exclude bits of code.
Maybe this is a better example

color_map{
        [0, Red]
        #if (ManyColors)
        [0.5, White]
        #end
        [1, Blue]
        }

2 remarks
Please no special characters ($#) before whatever, and
"$big ? 2 : 6" is not exactly readable to a newbe
-- 
Ger

Post a reply to this message

Zeger Knaepen wrote:

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

If vars are defined as float then why the need to define them as such? On
the other hand, integers are much faster so why not use both?

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

-- 
Ger

Post a reply to this message

> If vars are defined as float then why the need to define them as such?

you can also have other types, like String, or Vector, and so on

> On the other hand, integers are much faster so why not use both?

integers won't be faster, because they will always have to be converted to 
floats internally...
... I think... :)

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

According to me, POV-SDL has two aspects:
  declarative features to describe objects in scenes
  programmatic features such as loops, macros, includes, etc ...

My opinion is that POV is VERY efficient in the declarative aspect, and less
in the progrmmatic one. I can't see how it would be more compact and easy
than

sphere
{
    0, 1
    pigment
    {
        crackle scale 0.2
        color_map {[0.1 color 0.1*Red] [0.15 color 0.5*Green][1 Blue]}
        scale 2*y
    }
    normal {bumps 0.15 scale 0.05}
    finish {specular 0.3 roughness 0.01]
    scale <1.2, 0.5, 1>
    translate 10*z
}

But POV lacks programmatic features like recent langages have that make them
more efficient in programming, reusability, modularity, readability, etc ...
The effort should be made first on these rather than how to declare a sphere
in the scene, or how should the brackets be, curly or square, which are very
secondary concerns. One should remind the history of ray-tracing and that of
POV.

I totally agree that it is time now to go one step further, and that POV-Sdl
needs refurbishing here, enhancement there, redefinitions and complements
(compliments also ... :o)).

In addition, the isosurfaces are one of the most powerful object type you
can ever think of in ray-tracing (blobs are also powerful, but they lack
desiging tools and the are under-employed).

To finish, I can't imagine making 'reasonably advanced' scenes without a
minimum of programming skills and a minimum of geometry knowledge. For
example, the first thing you must have in mind is the order of
translations/rotations for you objects. However, gurus are always there to
work out complicated algorithms for you, provided the language allows them
to make it reusable, and you to reuse it.


    Bruno

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:46ef0157$1@news.povray.org...

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


    "If it ain't broke, don't fix it?"

     Just a thought Chris.


       ~Steve~



> -- Chris

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message 
news:web.46f167e9e7dc7428eb26baae0@news.povray.org...
> But POV lacks programmatic features like recent langages have that make 
> them
> more efficient in programming, reusability, modularity, readability, etc 
> ...
> The effort should be made first on these rather than how to declare a 
> sphere
> in the scene, or how should the brackets be, curly or square, which are 
> very
> secondary concerns.

agreed, but my point was mainly that things that are already good should not 
be changed.  curly brackets are one of those things :)
I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a 
very bad idea to change the POV-SDL into a BASIC-like syntax, or a 
Python-like syntax (whatever you make, DON'T make it whitespace-sensitive! 
PLEASE! :))

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

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:

> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a
> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
> Python-like syntax (whatever you make, DON'T make it whitespace-sensitive!
> PLEASE! :))

I like curly brackets over square brackets too, and agree about whitespace.
Charles

PS Woohoo! I haven't been able to log onto the web-interface in some time.
I can actually chime in!

Post a reply to this message

On Wed, 19 Sep 2007 19:38:18 +0100, St. wrote:

>     "If it ain't broke, don't fix it?"
> 
>      Just a thought Chris.

I wasn't the only one who had that thought, it seems.  :-)

Seriously, though, I agree with this - if there's functionality to add to 
SDL I'm all for that, but changing the format of things like object 
definitions is going to require people relearn the language - if that's 
going to happen, there ought to be a very good reason for doing so other 
than "we wanted a different syntax".

Taking what people are used to and changing it even *with* good reason 
tends to be met with a lot of resistance.  (As I work for Novell, just 
ask anyone who has used NetWare forever how they like running Open 
Enterprise Server on Linux for a prime example of the resistance to 
change phenomenon).

Jim

Post a reply to this message

On 19 Sep 2007 15:50:26 -0400, Jim Henderson <nos### [at] nospamcom> wrote:

>Taking what people are used to and changing it even *with* good reason 
>tends to be met with a lot of resistance.  (As I work for Novell, just 
>ask anyone who has used NetWare forever how they like running Open 
>Enterprise Server on Linux for a prime example of the resistance to 
>change phenomenon).

That's one of the major reasons I'm still running NetWare 6.

Post a reply to this message

On Wed, 19 Sep 2007 16:04:39 -0400, Kyle wrote:

> On 19 Sep 2007 15:50:26 -0400, Jim Henderson <nos### [at] nospamcom> wrote:
> 
>>Taking what people are used to and changing it even *with* good reason
>>tends to be met with a lot of resistance.  (As I work for Novell, just
>>ask anyone who has used NetWare forever how they like running Open
>>Enterprise Server on Linux for a prime example of the resistance to
>>change phenomenon).
> 
> That's one of the major reasons I'm still running NetWare 6.

Even evidence in here. :-)

Still got a 6.5 server running under VMware, but OES2 is looking much 
better than OES1 <g>.  Heck, I started with 2.15....But that's probably a 
povray.off-topic discussion. ;-)

(And now, back to your regularly scheduled discussion)

Jim

Post a reply to this message

David Buck wrote:
[snip]
> 
> Discussion is welcome.
> 
Something that I think has not been mentioned in this discussion so far 
(unless I accidentally skipped it):
One of the interesting things of POV is that it is a great environment 
to learn maths. Often you want to position two objects in such a way 
that they touch each other or such that the combined surface is 
continuous or... You can do this by trial and error, but soon you'll end 
up motivated to learn how to solve a particular second order equation or 
some equation involving sin() or tan().
Whatever direction a new SDL is going to take, it would be great if the 
simplest subset could (still) be used in a high school math class. The 
only thing we then need is someone to write something like 'Mindstorms 
for high school students'.

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a
> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
> Python-like syntax

hey, how about pretty much no syntax at all?

(union (plane y (pigment (checker 0 1)))
         (sphere 0 1
                 (texture (pigment (rgb x))
                          (finish (phong 0.8 30)))))
(light-source white (* 5 #(-1 1 -1)))
(camera (z -3) 0)

well, except for Lots of Irritating Silly Parentheses, that is... :)

Post a reply to this message

Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
> Zeger Knaepen wrote:
> 
> If vars are defined as float then why the need to define them as such? On
> the other hand, integers are much faster so why not use both?
>
Integer operations are not faster than floating point ones, this is due to the 
arithmetic coprocessor that is integrated in all processors since the advent of 
the Pentium. In fact, the oposite is almost always thrue for any multiplication, 
division and modulo. It was even the case for the 286, 386 and 486 whenever you 
also had an arithmetic coprocessor installed on your machine.

-- 
Alain
-------------------------------------------------
Don't cry because it is over, smile because it happened.

Post a reply to this message

nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a
>> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
>> Python-like syntax
> 
> hey, how about pretty much no syntax at all?
> 
> (union (plane y (pigment (checker 0 1)))
>          (sphere 0 1
>                  (texture (pigment (rgb x))
>                           (finish (phong 0.8 30)))))
> (light-source white (* 5 #(-1 1 -1)))
> (camera (z -3) 0)
> 
> well, except for Lots of Irritating Silly Parentheses, that is... :)
> 
> 
> 
Makes me think of Lisp! TONS of parenteses ;-)

-- 
Alain
-------------------------------------------------
Experience hath shewn, that even under the best forms of government those
entrusted with power have, in time, and by slow operations, perverted it
into tyranny.
Thomas Jefferson

Post a reply to this message

Jim Henderson wrote:
> Seriously, though, I agree with this - if there's functionality to add to 
> SDL I'm all for that, but changing the format of things like object 
> definitions is going to require people relearn the language - if that's 
> going to happen, there ought to be a very good reason for doing so other 
> than "we wanted a different syntax".

I don't think it is necessary to change object definitions. That's not to
say there may not be another means to create them programmatically if you
happen to be generating a scene from an algorithm, but the basic definition
syntax for objects, cameras, etc, could reasonably stay the same.

As has been mentioned elsewhere in this thread, SDL is really two things: a
scene description language and a scripting language. It started with the
pure SDL and the scripting was added later. Therefore it's not unreasonable
 to suggest that scripting can be changed without changing the core object
syntax.

-- Chris

Post a reply to this message

>> Zeger Knaepen wrote:
>>
>> If vars are defined as float then why the need to define them as such? On
>> the other hand, integers are much faster so why not use both?
>>

actually, I didn't

Post a reply to this message

On Thu, 20 Sep 2007 08:05:22 +1000, Chris Cason wrote:

> I don't think it is necessary to change object definitions. That's not
> to say there may not be another means to create them programmatically if
> you happen to be generating a scene from an algorithm, but the basic
> definition syntax for objects, cameras, etc, could reasonably stay the
> same.
> 
> As has been mentioned elsewhere in this thread, SDL is really two
> things: a scene description language and a scripting language. It
> started with the pure SDL and the scripting was added later. Therefore
> it's not unreasonable
>  to suggest that scripting can be changed without changing the core
>  object
> syntax.

No argument from me on this. :-)

Jim

Post a reply to this message

In article <46f198c1$1@news.povray.org>, ele### [at] netscapenet 
says...
> Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
> > Zeger Knaepen wrote:
> > 
> > If vars are defined as float then why the need to define them as such? 
On
> > the other hand, integers are much faster so why not use both?
> >
> Integer operations are not faster than floating point ones, this is due t
o the 
> arithmetic coprocessor that is integrated in all processors since the adv
ent of 
> the Pentium. In fact, the oposite is almost always thrue for any multipli
cation, 
> division and modulo. It was even the case for the 286, 386 and 486 whenev
er you 
> also had an arithmetic coprocessor installed on your machine.
> 
Tell that to the people that wrote Franctint (on a 486, Pentium or 
anything else). lol But seriously, even if they where marginally faster 
at one point, for specific situations, this isn't necessarily true now, 
nor applicable to what **this** program is doing. The results even in 
Fractint differed in some cases, depending on if you used the faster 
integers or floating point. One of the points of having POVRay behave as 
it does is "predictability" in what you get from it.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott nous apporta ses lumieres en ce 2007/09/19 23:13:
> In article <46f198c1$1@news.povray.org>, ele### [at] netscapenet 
> says...
>> Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
>>> Zeger Knaepen wrote:
>>>
>>> If vars are defined as float then why the need to define them as such? On
>>> the other hand, integers are much faster so why not use both?
>>>
>> Integer operations are not faster than floating point ones, this is due to the 
>> arithmetic coprocessor that is integrated in all processors since the advent of 
>> the Pentium. In fact, the oposite is almost always thrue for any multiplication, 
>> division and modulo. It was even the case for the 286, 386 and 486 whenever you 
>> also had an arithmetic coprocessor installed on your machine.
>>
> Tell that to the people that wrote Franctint (on a 486, Pentium or 
> anything else). lol But seriously, even if they where marginally faster 
> at one point, for specific situations, this isn't necessarily true now, 
> nor applicable to what **this** program is doing. The results even in 
> Fractint differed in some cases, depending on if you used the faster 
> integers or floating point. One of the points of having POVRay behave as 
> it does is "predictability" in what you get from it.
> 
If using a 486 or earlier, AND NOT using an arithmetic coprocessor, integer 
operations where much faster than floating point. Especialy the add and 
substract. Multiplications where only slightly faster.
Add in the coprocessor and, apart from int add and sub, floating point jumps 
ahead, largely ahead!
At that time, you could get slightly different results depending on the brand of 
your coprocessor: differing algorythm and rounding method, as well as intrinsic 
precision.


-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you stop using a protractor to 
measure angles because you can do it just by looking.
Taps a.k.a. Tapio Vocadlo

Post a reply to this message

"Zeger Knaepen"  wrote in message <46f15701$1@news.povray.org>:
> 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 believe you somewhat missed my point. The sample code I just posted is not
just a random suggestion of syntax: it is perfectly valid Perl code: if
someone writes the few functions it uses, it will parse and run perfectly.

My point is to show that, although it is not possible to keep exactly the
same syntax as the current one, it is possible to use a real programming
language while keeping the syntactic noise very low.

And please note that a part of your remarks comes from habit rather than
real syntactic superiority.

The advantages of using a real programming language are obvious: the time of
PoV developers is better spent improving the rendering features than
reinventing support for data structures and control loops.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas George wrote:
> My point is to show that, although it is not possible to keep exactly the
> same syntax as the current one, it is possible to use a real programming
> language while keeping the syntactic noise very low.

If we're going to re appropriate an existing language, maybe we could
look at some of the functional languages (Lisp, ML, etc.).

I don't normally like functional programming, but it does strike me as a
good match for describing scenes.

- --
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you're starting to find
these quotes more unsettling than funny.
    -- Alex McLeod a.k.a. Giant Robot Messiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8rd4cCmTzQ++ZncRApKuAKChyuD1k3G5lniHBDOogM290T3pewCgshxV
BQzVutm/DGb4E6YAvPlo0P0=
=ylrj
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
>> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>>> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would
>>> be a
>>> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
>>> Python-like syntax
>>
>> hey, how about pretty much no syntax at all?
>>
>> (union (plane y (pigment (checker 0 1)))
>>          (sphere 0 1
>>                  (texture (pigment (rgb x))
>>                           (finish (phong 0.8 30)))))
>> (light-source white (* 5 #(-1 1 -1)))
>> (camera (z -3) 0)
>>
>> well, except for Lots of Irritating Silly Parentheses, that is... :)
>>
> Makes me think of Lisp! TONS of parenteses ;-)
> 
	Look more closely at his last sentence. Especially the capital
letters... ;)

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG8r7md0kWM4JG3k8RAqIyAJ0a4iYBVeFjIefqqKMmEkbhy9+xwACgqZr4
nT0UHuDa7uYX5a4gVhN21bI=
=XaAF
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> If we're going to re appropriate an existing language, maybe we could
> look at some of the functional languages (Lisp, ML, etc.).

  Next you are going to suggest Haskell.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> William Tracy <wtr### [at] calpolyedu> wrote:
> > If we're going to re appropriate an existing language, maybe we could
> > look at some of the functional languages (Lisp, ML, etc.).
>
>   Next you are going to suggest Haskell.
>
> --
>                                                           - Warp

oh boy!  this is getting exciting!  I just hope someone doesn't mention java
or .net... and while haskell is rather nice, to get any performance with it
you need the friggin huge GHC compiler!

come on!  let's be realistic:  the SDL just needs a scripting language with
small foorprint, high performance and syntax and semantics flexible enough
to allow for easy DSL creation (SDL).  And this most likely mean AST
interpreters or similar.

I like Scheme but I understand there's not really any interpreter for it out
there that matches these requirements, and of course many people are put
down by the parentheses as much as are put down by python indented blocks
or perl's cryptic nature.  I guess Lisp macros are wonderful for DSL
building, which is a shame.

Python and Perl are pretty heavy by now.  Lua or Tcl are more lightweight.
Lua is a lot more modern and well supported than Tcl these days.  Anything
else which doesn't require a java VM or .NET?

As far as I understand, the purpose about this discussion is not really
about having a completely new SDL with new syntax, but mostly to alleviate
the need for a builtin and complex C parser maintained by povray
developers.  And of course, putting more power in the hands of those who
want more than basic SDL, ifs and loops by leveraging a complete and well
supported external programming language...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> As far as I understand, the purpose about this discussion is not really
> about having a completely new SDL with new syntax, but mostly to alleviate
> the need for a builtin and complex C parser maintained by povray
> developers.

  This would support a C(++)-like syntax, and may be as efficient as lua:

http://www.angelcode.com/angelscript/

-- 
                                                          - Warp

Post a reply to this message

andrel wrote:
> David Buck wrote:
> [snip]
>>
>> Discussion is welcome.
>>
> Something that I think has not been mentioned in this discussion so far 
> (unless I accidentally skipped it):
> One of the interesting things of POV is that it is a great environment 
> to learn maths. Often you want to position two objects in such a way 
> that they touch each other or such that the combined surface is 
> continuous or... You can do this by trial and error, but soon you'll end 
> up motivated to learn how to solve a particular second order equation or 
> some equation involving sin() or tan().
> Whatever direction a new SDL is going to take, it would be great if the 
> simplest subset could (still) be used in a high school math class. The 
> only thing we then need is someone to write something like 'Mindstorms 
> for high school students'.
> 
There is a lot more that I would want to say, but I find this format of 
discussing in a subthread a bit confusing. I am not sure if a wiki is 
the right solution, but I'd really like a discussion forum where we 
could combine remarks by subject.
Can someone set something up somewhere?
If not, I might feel forced to sift through this mess again to collect 
all arguments and put them on a simple html page, but be aware that that 
one will be highly biased and not changeable by others ;)

Post a reply to this message

Jérôme M. Berger nous apporta ses lumieres en ce 2007/09/20 14:41:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alain wrote:
>> nemesis nous apporta ses lumieres en ce 2007/09/19 17:10:
>>> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>>>> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would
>>>> be a
>>>> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
>>>> Python-like syntax
>>> hey, how about pretty much no syntax at all?
>>>
>>> (union (plane y (pigment (checker 0 1)))
>>>          (sphere 0 1
>>>                  (texture (pigment (rgb x))
>>>                           (finish (phong 0.8 30)))))
>>> (light-source white (* 5 #(-1 1 -1)))
>>> (camera (z -3) 0)
>>>
>>> well, except for Lots of Irritating Silly Parentheses, that is... :)
>>>
>> Makes me think of Lisp! TONS of parenteses ;-)
>>
> 	Look more closely at his last sentence. Especially the capital
> letters... ;)
> 
> 		Jerome
It makes for a nice alternative for LISP, but not what the creators had in mind ;-)
Similar to:
I Built a Monster
It's Beter Manualy

The legend tell that those where from peoples working in THAT compagny...

-- 
Alain
-------------------------------------------------
   I went to a massage parlor. It was self service.
   	Rodney Dangerfield

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> William Tracy <wtr### [at] calpolyedu> wrote:
> > If we're going to re appropriate an existing language, maybe we could
> > look at some of the functional languages (Lisp, ML, etc.).
>
>   Next you are going to suggest Haskell.
>
> --
>                                                           - Warp

BTW, just saw this in reddit:

http://www.nobugs.org/developer/htrace/index.html

though it's just a toy raytracer from 2001...

Post a reply to this message

andrel wrote:
> Can someone set something up somewhere?

Can someone recommend specific Wiki software?

It'd need to support external authentication (to link in to the POV user
registration system), and captchas or other anti-spam measures.

Anyone have any experience with this?

Alternatively if someone here wants to undertake to maintain an official
POV wiki and has some experience in site management, let me know and I'll
set them up with some webspace on the povray.org server and let them loose.

-- Chris

Post a reply to this message

On Mon, 24 Sep 2007 17:47:45 +1000, Chris Cason
<del### [at] deletethistoopovrayorg> wrote:

>Can someone recommend specific Wiki software?

Some time ago, I set up MediaWiki at work for use as a company-wide wiki.  It's the
same one used for Wikipedia.  It works very well.  At the time, it was the best one
out there.  This may still be
the case...

http://www.mediawiki.org/


>It'd need to support external authentication (to link in to the POV user
>registration system), and captchas or other anti-spam measures.

I believe there are extensions written for MediaWiki that support these requirements.

Post a reply to this message

As with Kyle, I have some experience with MediaWiki - I've set it up a 
few times and we use it at work.  I'm rubbish at the stylesheets and 
whatnot, but authentication and whatnot should be fairly easy to get 
going.  What type of database is used on the backend to hold the user 
information?

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> As with Kyle, I have some experience with MediaWiki - I've set it up a
> few times and we use it at work.  I'm rubbish at the stylesheets and
> whatnot, but authentication and whatnot should be fairly easy to get
> going.  What type of database is used on the backend to hold the user
> information?
>
> Jim

Is this undertaking going to coincide with the SDL object/code repository
that was discussed sometime back?
Charles

Post a reply to this message

On Mon, 24 Sep 2007 19:50:34 -0400, Charles C wrote:

> Is this undertaking going to coincide with the SDL object/code
> repository that was discussed sometime back?
> Charles

Personally, I couldn't answer that, but I don't see why such a wiki 
couldn't include a collection of examples.

Jim

Post a reply to this message

why not go super-simple?

lighting {4pm, August 12, Milan, Italy, outdoors}
city{detail=fine}

camera{Canon AE-1, F2.8, 1/100th
	filters{anti-glare, polarized}
}

car{Bentley, color Red, very shiny}

woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}




nemesis wrote:
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a
>> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
>> Python-like syntax
> 
> hey, how about pretty much no syntax at all?
> 
> (union (plane y (pigment (checker 0 1)))
>          (sphere 0 1
>                  (texture (pigment (rgb x))
>                           (finish (phong 0.8 30)))))
> (light-source white (* 5 #(-1 1 -1)))
> (camera (z -3) 0)
> 
> well, except for Lots of Irritating Silly Parentheses, that is... :)
> 
> 
>

Post a reply to this message

Bryan Valencia wrote:

> why not go super-simple?
> 
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
> 
> camera{Canon AE-1, F2.8, 1/100th
> filters{anti-glare, polarized}
> }

What if you don't have a Canon?

> 
> car{Bentley, color Red, very shiny}
> 
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
> 
> 

-- 
Ger

Post a reply to this message

andrel wrote:

> Can someone set something up somewhere?
> If not, I might feel forced to sift through this mess again to collect 
> all arguments and put them on a simple html page, but be aware that that 
> one will be highly biased and not changeable by others ;)

Ok, some of the discussion is summarized at:

http://members.chello.nl/a.c.linnenbank/newsdlforpov.html

Post a reply to this message