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