POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 : Re: Random POV-Ray 4 SDL proposal, #1 Server Time
26 Apr 2024 09:41:41 EDT (-0400)
  Re: Random POV-Ray 4 SDL proposal, #1  
From: William F Pokorny
Date: 13 Dec 2015 14:29:54
Message: <566dc732$1@news.povray.org>
On 12/12/2015 09:42 AM, clipka wrote:
 >

 From a users perspective I think the tendency is to wish for an SDL 
language close to the programming languages we currently use as learning 
new stuff to the point of being quick with it takes a lot of time. Much 
of my own povray use over time has come from hacks in other languages to 
generate existing SDL for whatever job - using TCL mostly of late - 
though I write native POV SDL too.

A good many software libraries tools provide and API in C/C++ (or create 
one with SWIG I've read) to enable a set of bindings from a tool to 
other languages of the day. I've never heard mention of such an API with 
POV-Ray.

I'd first recommend the developers continue whatever code restructuring 
is in flight to enable a clean API so bindings to language xyz, or 
running POV-Ray as a compiled C++ program as Jérôme suggested, is 
possible. Perhaps with a defined API or an API more easily determined 
automatically from a cleaner code base, bindings for various languages 
will then just spring up. ;-) Even if not, it seems like we'd be better 
set up to create any new POV-Ray SDL at such a time.

I do think a POV-Ray specific SDL is a good idea as probably that SDL 
will always be the only completely enabled language interface. Further, 
it permits a standard interchange language for methods and techniques 
among users.

I generally like your random SDL proposal, but expect the difficulties 
will be in the details of any new SDL implementation.

Is the eventual aim also to enable SMP during parsing?

Other comments in line below.

Bill P.

> The POV-Ray 3.x SDL is, at its core, a language to describe static
> hierarchical data structures in a quite efficient manner, with a
> scripting language bolted on top later to also allow for dynamic
> creation of data.
>
> I think there's nothing fundamentally wrong with this approach;
> specifically, I think the data description aspect of a POV-Ray scene is
> so important that it is wiser to start with a data description language
> and bolt a scripting language on top of it, rather than start with a
> scripting language and extend it with data description elements (the
> latter is the path of evolution that led to JSON). Therefore, in this
> random proposal I will follow that same path.
>
.......
>
> This leaves us with the following scene description:
>
>      {
>        camera: {
>           up: [ 0, 1, 0 ],
>           right: [ 1.33, 0, 0 ],
>           direction: [ 0, 0, -1 ],
>           location: [ 0, 0, 5 ],
>           look_at: [ 0, 0, 0 ]
>        },
>        objects: [
>          light_source {
>            location: [ -100, 100, 100 ],
>            colour: #FFFFFF
>          },
>          sphere {
>            location: [ 0, 0, 0 ],
>            radius: 1,
>            texture: {
>              pigment: {
>                colour: #FFFFFF
>              }
>            }
>          }
>        ]
>      }

Here I am not getting the real purpose for objects: [] other than to 
enable us to drop the colons for light_source and sphere - something I 
think less clear than light_source: {} and sphere: {}.

.......
>
> As a matter of fact I'll define "@" as a prefix operator for string
> expressions, meaning "the content of the variable with the name". I'll
> use the following syntax to define variables for now:
>
>      #global {
>        "A variable name with blanks": 4711,
>        Foo: [ 0, 1, 2 ],
>        Bar: "Foo"
>      }
>      #local { ... }
>
> I can now use the variables as follows:
>
>      sphere: {
>        radius: @"A variable name with blanks"
>        center: @@Bar // look what I just did there
>      }

I like the idea of #global{} and #local{} blocks for defining variables. 
I wonder about @@+ when the references are not 1 to 1, or perhaps they 
must be? Thinking, for example, about three deep and Foo: ["MyX",...]

I'm also a little fuzzy on how we would define and reference predefined 
entities later by name. Would it be something like:

{
   camera00: {
     camera: {
       ...
     }
   }
   ...
   camera: { @camera00 ... }
}

?

.....

>
> There. Behold your new SDL, chilren of POV-Ray.
>
>

:-) Cool, I'm young again.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.