 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
As a starting point, I'll take an existing language that I consider
reasonably efficient at describing static hierarchical data structures:
JSON (defined in ECMA-404). For those who don't know it, this is what an
arbitrary JSON file looks like:
{
"firstName": "John",
"lastName": "Smith",
"isAlive": true,
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
"phoneNumbers": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "office",
"number": "646 555-4567"
}
],
"children": [],
"spouse": null
}
A simple POV-Ray scene described in this format might look like this:
{
"camera": {
"up": [ 0, 1, 0 ],
"right": [ 1.33, 0, 0 ],
"direction": [ 0, 0, -1 ],
"location": [ 0, 0, 5 ],
"look_at": [ 0, 0, 0 ]
},
"objects": [
{
"object_type": "light_source",
"location": [ -100, 100, 100 ],
"colour": "#FFFFFF"
},
{
"object_type": "sphere",
"location": [ 0, 0, 0 ],
"radius": 1,
"texture": {
"pigment": {
"colour": "#FFFFFF"
}
}
}
]
}
Notice how I chose to use the HTML-style colour format; this is a
comparatively random choice, probably because JSON lives in the same
ecosystem as HTML.
The first thing that strikes me is the fact that we have a vast number
of double quotes I, as a user, wouldn't want to have to type. As we'll
devising our own language anyway, we might therefore try to avoid them,
and I think we can accomplish this (even without breaking backward
compatibility to pure JSON) by addition of the following rule:
* If a string appears on the left-hand side of a name/value pair,
contains only uppercase letters, lowercase letters, digits and/or
underscores, does not start with a digit, and is neither "true" nor
"false" nor "null" (nor equivalent to any keyword we might add later),
the enclosing double quotes are optional.
Note that this mandates that we can't use character sequences of this
form for any other purpose.
We can also simplify our colour notation in a similar manner:
* If a string starts with "#", and the remainder of the string is
comprised solely of hexadecimal digits, the enclosing double quotes are
optional.
Also, the "object_type" thing bothers me; I therefore introduce /types/
to the language:
* An /object/ (in the JSON sense) may be preceded by a string specifying
its /type/.
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
}
}
}
]
}
I think this constitutes a reasonable format for static scene
description; it's about as concise as the current format.
Now for bolting on a scripting language:
First we need control structure keywords; we don't want them to collide
with our unquoted strings, so I'll borrow a feature from POV-Ray 3.x
SDL: I'll prefix them with "#". For starters, I'll use the following:
#if(CONDITION)
...
#elif(CONDITION)
...
#else
...
#end
#loop NAME
...
#if(CONDITION) #break NAME #end
...
#continue NAME
#end
That'll be all we really need; we can bolt on more later (though we need
to make sure we don't get collisions with colour names).
Next we need variables; again we don't want them to collide with our
unquoted strings, so I'll use just about the same trick, except that I
use "@" to refer to variables.
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'll also extend the language by introducing non-literal values,
allowing mathematical operations and other some such, but I'll not go
into details there for now.
We could now modify our scene as follows:
{
camera: {
up: [ 0, 1, 0 ],
right: [ @image_width / @image_height, 0, 0 ],
direction: [ 0, 0, -1 ],
location: [ 0, 0, 5 ],
look_at: [ 0, 0, 0 ]
},
objects: [
light_source {
location: [ -100, 100, 100 ],
colour: #FFFFFF
},
#local { i: 1, n: 10 }
#loop
sphere {
location: @i * [ 2, 0, 0 ],
radius: 1,
texture: {
pigment: {
colour: #FFFFFF
}
}
}
#local { i: @i + 1 }
#if (@i <= @n)
,
#continue
#else
#break
#end
#end
]
}
There. Behold your new SDL, chilren of POV-Ray.
Or don't. Make alternative suggestions, or proceed from here.
One possible change to the syntax could be the use of regular braces
around list items instead of square brackets to specifically denote
vectors, if only to make it more pleasant to read. (As for using angular
brackets for this purpose, I never liked that part of POV-Ray 3.x's
syntax in the first place; also, in specific cases it has the potential
to collide with the greater-than sign.)
I'd also love to add ranges to the set of types, using a syntax akin to
this:
[ 1 .. 20 ] // range from 1 to 20, both inclusive
( 1 .. 20 ) // range from 1 to 20, both exclusive
[ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
( 1 .. 20 ] // range from 1 exclusive to 20 inclusive
In general, I'd love the syntax to be geared more towards mathematical
notation, and I'd also like it to make use of Unicode mathematical
symbols as (entirely optional) syntactic sugar.
BTW, I don't consider the above syntax really good, most notably because
the possible location of control structures is poorly defined, which
makes the whole thing unsuited for a compiled language. It's really just
one random proposal thrown together in a matter of a few hours, in hopes
to kick off a more productive discussion about how the next generation
SDL might look like.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/12/2015 9:42 AM, clipka wrote:
> 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.
I like JavaScript, so JSON seems reasonable.
One quick note: you shouldn't use hex for colors because then you can't
perform precise calculations. Better to use float like we do now.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/13/2015 3:23 AM, Mike Horvath wrote:
> I like JavaScript, so JSON seems reasonable.
>
> One quick note: you shouldn't use hex for colors because then you can't
> perform precise calculations. Better to use float like we do now.
>
>
> Mike
In fact, I would rather just use JavaScript for everything.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmail com> wrote:
> One quick note: you shouldn't use hex for colors because then you can't
> perform precise calculations. Better to use float like we do now.
How about just translating it to the standard 5-D float vector at parse time, as
is done with the srgb keyword series in POV-Ray 3.7?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.12.2015 um 16:43 schrieb Cousin Ricky:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> One quick note: you shouldn't use hex for colors because then you can't
>> perform precise calculations. Better to use float like we do now.
>
> How about just translating it to the standard 5-D float vector at parse time, as
> is done with the srgb keyword series in POV-Ray 3.7?
My idea would be to use HTML colour format for colours in sRGB space,
and some other syntax to specify linear colours; internally, they'd both
be translated to a vector-like linear format, and math operations could
be done on them.
Colours would /not/ be treated as strings internally.
As for translating colours to "standard 5-D float vectors", that won't
happen:
(1) Vectors are vectors, and colours are colours. In my book, using one
and the same type for them is one of the biggest blunders in POV-Ray's
current SDL.
(2) The RGBFT format is another one of the biggest blunders in the
history of POV-Ray, and unfortunately it's more deeply entrenched in the
rendering engine. Wherever any transparency is involved, internal math
should use two RGB values, one representing the opaque component and
another the transmissive one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.12.2015 um 20:29 schrieb William F Pokorny:
> 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.
Obviously catering to this wish isn't possible for all the user base,
given how different the languages are they use. You mention Tcl, IIRC
others have mentioned python, then of course there's C and the vast
number of its offspring like C++, Java, C#, the recently mentioned
JavaScript etc., others may prefer Perl, maybe Lua -- you certainly get
the point.
Thus, as long as you think of POV-Ray as an application that reads an
input file and generates an image from it, what you wish for is not
going to happen for at least a portion of the user base -- unless of
course the new SDL will be very similar to the current one.
But it seems that your idea is heading in a different direction:
Providing POV-Ray not as an application, but as a library.
> 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.
It has been mentioned as an idea, and a goal to aim for. That's a start.
> 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 think it won't hurt to do some brainstorming now already: Defining the
new language might be a lengthy process, and if we start that process
only when the API is actually established, I think we're losing time
unnecessarily.
For the sake of designing an SDL, actually we need to know little of the
ultimate API: We need to know that there'll be a scene comprised of a
hierarchy of elements, each element having particular properties
depending on the type of element, with some of the properties being
ordered lists of elements. That's about it.
The current SDL has all those elements and properties hard-wired, but
that's far from necessary; to the contrary, it only creates a bloated
language and parser, with a lot of potential for inconsistencies.
> Is the eventual aim also to enable SMP during parsing?
I've thought about this one, but I'm not sure whether it is a good idea.
SMP comes with plenty of pitfalls, and makes the virtual machine and its
integration into the application more difficult.
Maybe at a later stage.
>>
>> {
>> 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: {}.
It's just a vehicle to shoehorn the data structure into what JSON can
accomodate.
If I used the notation
scene: {
light_source: { ... }
sphere: { ... }
}
it would mean that the scene will have one property named "sphere"
containing at most one sphere, another property named "light_source"
containing at most one light_source, and -- by extension -- one property
named "box" containing at most one box, one property named
"height_field" containing at most one height field, etc.
That's obviously not what we want.
This is actually one of the things that's been giving me the biggest
headaches: I'd prefer to have virtually the same syntax for specifying
the objects in a scene, and for specifying the texture of an object; but
while in the former case I actually want to build a multi-element list,
in the latter case I want to set a single-element property.
Thus, I can't let the language just define arbitrary data hierarchies
(like JSON), and translate those to actual scene elements in a
subsequent steps; instead, the process of defining the data hierarchies
must have some knowledge of the data elements being defined.
>> #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.
Isn't that neat?
It just came naturally when I thought about how, in this particular
language, the exact syntax of a "#declare" statement (which I later
decided should be "#global") should be, and I think I might carry over
that idea to other proposals.
> 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 not exactly sure I understand what you mean there.
If the "@" operator is applied to something that isn't a string, it bombs.
> 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 ... }
> }
Like in the current SDL, we'd use global or local variables, like so:
#declare { camera00: camera { ... } }
...
camera: @camera00
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> #local { i: 1, n: 10 }
> #loop
...
> #local { i: @i + 1 }
> #if (@i <= @n)
> ,
> #continue
> #else
> #break
> #end
> #end
You know something has gone very wrong when a for loop looks like that :-)
How about:
for i 1 10
{
...
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2015 um 12:55 schrieb scott:
>> #local { i: 1, n: 10 }
>> #loop
>
> ....
>
>> #local { i: @i + 1 }
>> #if (@i <= @n)
>> ,
>> #continue
>> #else
>> #break
>> #end
>> #end
>
> You know something has gone very wrong when a for loop looks like that :-)
No, it just means that the syntax is a bit on the minimalistic side ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> My idea would be to use HTML colour format for colours in sRGB space,
> and some other syntax to specify linear colours; internally, they'd both
> be translated to a vector-like linear format, and math operations could
> be done on them.
Personally, as someone who just likes to make nice-looking images and animations
(and not being a 'programmer' per se), the use of HTML color formatting seems
*much* less intuitive than our current vector format. For example, <1,.4,.7> vs.
something like FFDFB (I made up that last term!) With the vector approach, I
can write a 'first approximation' color quite easily if I want to, then tweak it
by eye. The hex(?) way of doing it requires either a lookup table, or else a
GOOD intuitive knowledge of that kind of coding approach and its visual results.
I suppose there are crack programmers who think in such terms, but I'm certainly
not one of 'em. ;-) (Long ago, I got into HTML coding-- before style sheets--
and even then I thought it 'odd' to have to specify colors in what seemed to be
such an arcane manner.)
>
> As for translating colours to "standard 5-D float vectors", that won't
> happen:
>
> (1) Vectors are vectors, and colours are colours. In my book, using one
> and the same type for them is one of the biggest blunders in POV-Ray's
> current SDL.
>
Here's a funny thing: I've always been under the impression that the original
developers actually *wanted* vectors and colors to use the same coding scheme,
explicitly. For ease of understanding and computation in the SDL. I.e., "A
vector is a color is a...." From a conceptual standpoint, such an arrangement
does make sense, to me.
Another question arises concerning dot-notation (i.e., pulling one of the color
components out of the color vector, for use.) I don't see how that would work
using the FFDFB approach. (I suppose it *could* simply be specified as
FFDFD.red, for example, with POV-ray's internal engine doing the hex-to-float
conversion invisibly. But again, that doesn't seem very intuitive from a user's
standpoint.)
I hope I haven't gotten into meaningless or extraneous details re: your
discussion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
