POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 Server Time
31 Oct 2024 19:39:24 EDT (-0400)
  Random POV-Ray 4 SDL proposal, #1 (Message 9 to 18 of 38)  
<<< Previous 8 Messages Goto Latest 10 Messages Next 10 Messages >>>
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

From: Saul Luizaga
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 8 Jun 2021 19:06:14
Message: <09d19d23-eda4-ca0a-6923-96a598314c48@netscape.net>
So... after 30+ year ago, here is the answer tomy question: when is 
POV-Ray 4 is going to go out? Me and many others, that were quickly met 
with belligerent: it's going to be when is done, now STFU about it and 
never ask the fucking question again in your life! Or be banned from the 
entire pov-ray newsgroup! Or something to that shock effect; but I feel 
other and I contributed my 2 cents to keep things, at least alive, if 
not greasing them a little, until they started going; hey, I pushed Warp 
to join as an active programmer, so your welcome bitches! LOL :-D


Post a reply to this message

From: Saul Luizaga
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 8 Jun 2021 19:11:17
Message: <748f24c6-f21c-da25-1c6b-8bca3fbb8417@netscape.net>
So... after 30+ year ago, here is the answer tomy question: when is 
POV-Ray 4 is going to go out? Me and many others, that were quickly met 
with belligerent: it's going to be when is done, now STFU about it and 
never ask the fucking question again in your life! Or be banned from the 
entire pov-ray newsgroup! Or something to that shock effect; but I feel 
other and I contributed my 2 cents to keep things, at least alive, if 
not greasing them a little, until they started going; hey, I pushed Warp 
to join as an active programmer, so your welcome bitches! LOL :-D


Post a reply to this message

From: Saul Luizaga
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 8 Jun 2021 22:47:43
Message: <397ceea6-0b23-9b24-91d8-c542853726f0@netscape.net>
So... after 30+ years


Post a reply to this message

From: Mr
Subject: Re: Random POV-Ray 4 SDL proposal, #1
Date: 9 Jun 2021 08:10:00
Message: <web.60c0ae692ab8183e16086ed03f378f2@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> As a starting point, I'll take an existing language

Okay, Maybe what follows is incompatible with this language I know nothing
about, so ignore my remarks in that eventuality because I do value that idea of
leveraging the best and closest standard if possible.


> 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: [
>         light_source {
>           location: [ -100, 100, 100 ],
>           colour: #FFFFFF
>         },
>         sphere {
>           location: [ 0, 0, 0 ],
>           radius: 1,
>           texture: {
>             pigment: {
>               colour: #FFFFFF
>             }
>           }
>         }
>       ]
>     }


The  first thing bothering me is the combination of colons and brace characters
in some places or maybe rather that it seems it can't be used the same  way
elsewhere?
Would we have to write camera: {
It would seem a little cluttered to have to use a : for just specifying the
opening of a block. do we have to ? ... why not:

       camera{
          up: [ 0, 1, 0 ],
          right: [ 1.33, 0, 0 ],
          direction: [ 0, 0, -1 ],
          location: [ 0, 0, 5 ],
          look_at: [ 0, 0, 0 ]
       },

Also for same reason, would the comma after the brace really be necessary ?



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

Fine,

>       center: @@Bar // look what I just did there

I'm not sure I understand, maybe that's why, but it looks a little barbarian to
my delicate profane eye :-) Does json force to specify like this instead of some
"object" dot lookup operator?

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

Yay ! great to see some direction, and a great start !

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

I believe readability would suffer and prefer your proposition versus curly
braces everywhere whith no rythmic to distinguish what's inside what though the
too-many-different-enclosing-signs margin is probably easily reached, so <>
could go away as far as i'm concerned

> 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

Personally I think this looks pretty cool! But again I'm no expert at all.

> symbols as (entirely optional) syntactic sugar.

Sounds awesome as well and a breath of fresh air for such a feature rich
program, it also goes well with the cypher obscure reputation of POV, except for
once it would have some real benefits, I assume, in code parsing computation
times ?  But with the prerequisites that they should have an explicit
alternative for when we don't know or have any internet to check for the code to
type. most people never enter a unicode special number their whole life. but
maybe the parsing times could really be worth that learning?

This brings to my mind the topic even outside of the mathematical field of some
unicode symbols or even some more common non ascii characters, sorry if too off
topic for lack of terminology and specialists concepts here, but my naive
expectations for POV sdl of my dreams :

a)It should strive to still look intuitive and elegant to non programmers,
preferably one & looks better than two or three && or @@  except where
conventions are long there in several mainstream languages like comments with
doubled chars // for many languages and some alternative doubled sign in many
more others.

b)May we try to keep it easy to type with less modifier keys across the two or
three most used keyboard layouts, since we don't want povers to have carpal
tunnel. (but probably the most cryptic unicode are easier to call by their id
number than some of the characters available of the keyboard layouts requiring
to type a space before they appear and one of two alt keys etc...

I'm getting lost in that stream of thoughts, wishes and good intentions, so I
should stop especially as I trust the experts around here a lot more !

Thanks for giving this a lot of thought!


Post a reply to this message

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

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