POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 Server Time
28 Mar 2024 15:56:43 EDT (-0400)
  Random POV-Ray 4 SDL proposal, #1 (Message 5 to 14 of 38)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 13 Dec 2015 14:10:56
Message: <566dc2c0$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: Random POV-Ray 4 SDL proposal, #1
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

From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 13 Dec 2015 15:59:53
Message: <566ddc49@news.povray.org>
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

From: scott
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 14 Dec 2015 06:55:55
Message: <566eae4b$1@news.povray.org>
>          #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

From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 14 Dec 2015 14:01:28
Message: <566f1208$1@news.povray.org>
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

From: Kenneth
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 15 Dec 2015 05:20:00
Message: <web.566fe81c2ab8183e33c457550@news.povray.org>
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

From: ingo
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 15 Dec 2015 06:12:04
Message: <566ff584$1@news.povray.org>
Op 2015-12-12 om 15:42 schreef clipka:
> 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.

How much of a "language" does POV-Ray actually need? How bare-bone can a 
human readable fast parsing textual interface be? For example, when I 
craete scene's in Python I enroll all loops so POV-Ray has not to do it 
and the parsing speeds up quite a lot.

Could it work, a bare-bone SDL and a pre-processor in a good scripting 
language, so all libraries of that are also usable?

(the pre-processor could then be made to also output other scene formats 
OpenGL, WebGL etc)

Ingo


Post a reply to this message

From: scott
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 15 Dec 2015 06:55:55
Message: <566fffcb$1@news.povray.org>
> 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.

I think clipka's point is that you would use the vector format with the 
linear colour identifier, and the hex format with the sRGB identifier. 
That makes perfect sense to me, because if you're tinkering with 
something like <1,.4,.7> you probably want that to be a linear colour 
(ie green is 40% of maximum brightness) - unless you can do the sRGB 
conversions in your head :-)


Post a reply to this message

From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 15 Dec 2015 10:25:00
Message: <web.56702fb32ab8183ead6fa18f0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> I hope I haven't gotten into meaningless or extraneous details re: your
> discussion.

Not at all. I consider it valuable feedback.

As for "a colour is a vector", one thing that bothers me very much about this is
that, although it matches the typical representation in computer graphics, the
physics of colours is quite different, and performing colour maths in a
3-dimensional coordinate space is just a very poor approximation of physical
reality. The relevant buzzword is "spectral rendering".

Making the colour type intimately related to the vector type ties down POV-Ray's
colour math to the RGB world, and hinders the development of modified versions
that support spectral rendering.


Post a reply to this message

From: clipka
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 15 Dec 2015 10:35:00
Message: <web.567031f82ab8183ead6fa18f0@news.povray.org>
ingo <ing### [at] gmailcom> wrote:
> Op 2015-12-12 om 15:42 schreef clipka:
> > 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.
>
> How much of a "language" does POV-Ray actually need? How bare-bone can a
> human readable fast parsing textual interface be? For example, when I
> craete scene's in Python I enroll all loops so POV-Ray has not to do it
> and the parsing speeds up quite a lot.
>
> Could it work, a bare-bone SDL and a pre-processor in a good scripting
> language, so all libraries of that are also usable?
>
> (the pre-processor could then be made to also output other scene formats
> OpenGL, WebGL etc)

In a distributed rendering environment, it may be preferable to avoid
"unrolling" complex scenes to reduce network load.

Also, true pre-processor languages are prone to result in an overall syntax that
is difficult to analyze at edit-time.


Post a reply to this message

<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>

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