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 () {

    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