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