 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So... after 30+ years
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
delete this message, I can't do it myself from Mozilla Thunderbird,
tried to unsubscribe and subscribe several times, tried several methods
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
delete this message, I can't do it myself from Mozilla Thunderbird,
tried to unsubscribe and subscribe several times, tried several methods,
it was a moment of insanity, sorry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
