in news:60eda74b@news.povray.org clipka wrote:

> Heck, I've never claimed that my own proposal was really any good. I 
> just threw it out there to have _some_ starting point. For discussion
> at worst, or for further development at best.
> 

Lets go wild then. I don't like it. I like how the current SDL is 
sufficient. Fit for use. Although there's a lot I would leave out. 
#declare, #local be gone! Proper, simple, understandable namespaces and 
scoping with maybe a (exportable) global. All the #'s be gone. What's 
left then is quite clean. Oh ';' out, out out. Squiggels is enough and 
(),[],<>. Vectors are great.

Then there's a few little gripes "for (I, 0, dimension_size(ArrayX, 1)-
1)" for example. I know the dimension_... comes from the multidimensional 
arrays, but are they still needed when we have arrays of arrays? "for (I, 
0, size(ArrayX)-1)" or "for (I, 0, size(ArrayX[5])-1)".

So, no brand new syntax for me, but a cleaned up version as close as 
possible in functionality as the current one. No OOP. Would iterators, 
generators make sense? I doubt it. No async. Minimal to no functional 
stuff. Also something that relative easily can be converted from old to 
new (probably impossible given how the SDL can be 'abused').

Under the hood? I would like to have more access to all kind of variables 
POV-Ray calculates so we can create 'things' (textures) depending on 
those results.

Ok, now for the crazy one: Wasm. https://webassembly.org/
I like how the compiled functions in math.inc work through an include 
file. I like the ideas of adding more of those. 
I even more like the idea if we could write dynamic linked libraries, 
call them from POV-Ray using a compagnion include file. (something 
simmilar is done in SuperCollider c++ for the audio server and a *.sc 
file for the scripting side). 
Now, what if these wasm's can be used as 'dll's'. It would make them 
platform independent plug-in's. Reduction of maintenance. There are a lot 
of languages that can be compiled this way, proper toolchains et al.

For what? Not directly for interacting with the ray's, if possible at 
all. But for easy access to for example nurbs (Rhino OpenNurbs) of faster 
mesh generation or boning and IK and surface subdivison, 
http://math.lbl.gov/voro++. Simply put, more extensive and faster include 
files (for things you don't want in the core).
Or, the other way around. Could it be made possible to convert a parsed 
file into 3D printer data more easily, with checks for holes we don't 
need when tracing? OGL visualisations?

Ingo
-- 
https://ingoogni.nl

Post a reply to this message

Am 14.07.2021 um 11:35 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> ...
>> No worse than the current SDL, and better structured - that's all I'm
>> asking of a new SDL. Ideally with consistent syntax between scene
>> descriptions and functions, and maybe with a rigorous enough structure
>> to allow for a compiling rather than interpreting parser.
> 
> have you looked at Tcl/Tk yet, for inspiration?  has many (imo) natty features,
> nice, clean syntax, and byte-compiles.

Unless those features have a direct impact on the core principles of the 
language's syntax, I don't care much for them at this point. Also, I 
think it would be more productive to name those features that you like 
about it, rather than just (to put it into more blunt of a picture than 
adequate here) point in the general direction of the language and say, 
"I like some of the stuff that's in there, see if you can spot it".

As for nice, clean syntax - I would disagree.

At a very first glance, Tcl/Tk sounds like a promising basis: Its main 
purpose (nowadays) is also to describe hierarchical structures (albeit 
not geometric objects and surface properties, but rather GUI elements), 
with programmatic elements mixed in for good measure. Unfortunately, the 
Tk part (which is the description of GUI elements) was bolted on later, 
and in my opinion it shows. At its very core, Tcl is a command 
shell-style scripting language.

One of the results is that different Tcl statements may have their own 
individual quirky "micro-syntax". Just like all of POV-Ray's individual 
geometric primitive, pattern and what-have-you statements all have their 
own little "micro-syntax" quirks. Any commonalities between them are 
just superficial conventions. Which bothers me to no end.


In my opinion, the best approach to judge a language for suitability as 
the basis for a new SDL is to ask (and answer) the following three 
questions:

- "What is the 'grammar' of this language, i.e. the core principles that 
govern its syntax?"

And based on that:

- "How would a simple scene be described in this language?"
(A chrome sphere on a colorful checkered plane, with camera and all, and 
maybe a text object to showcase strings, should do as a first example.)

- "How would programmatic elements mesh with this syntax?"
(A simple example with a loop and a few conditionals should be a 
reasonable starting point.)


When I do that for Tcl/Tk, I find that the results look - in my mind - 
ugly AF.

Post a reply to this message

Am 14.07.2021 um 20:15 schrieb ingo:

> Lets go wild then. I don't like it. I like how the current SDL is
> sufficient. Fit for use. Although there's a lot I would leave out.
> #declare, #local be gone! Proper, simple, understandable namespaces and
> scoping with maybe a (exportable) global.

So there _is_ something you would add: Namespaces.

Also, for something that is "fit for use", there's quite a lot you would 
seem to change ;)

> All the #'s be gone. What's
> left then is quite clean.

But is it though?

Trim the `#` from the `#version` statement, and it clashes with the 
pseudo-variable `version`, for example. Trim the `#` from the `#local` 
statement, and it clashes with the `local` pseudo-dictionary.

You're asking for namespaces - you can look at `#` as the namespace for 
control statements.


(There's also one particular property the use of `#` has, that is 
invaluable at least for the current parser:

It helps a lot in speeding up the parsing of some control structures. 
For example, after encountering `#if()` with an expression that is 
false, the parser can simply skip from `#` to `#` in search for the 
matching `#else` or `#end`, because anything else is guaranteed to not 
natter. Likewise, after encountering `#macro(...)`, the parser can 
simply skip from `#` to `#` in search for the matching `#end`, because 
it will only parse the macro body once it is invoked.

Of course that may be less of an issue once we change the parsing 
strategy to scan and tokenize the file only once, and then work on the 
"pre-digested" token sequence.)


> Oh ';' out, out out. Squiggels is enough and
> (),[],<>. Vectors are great.
> 
> Then there's a few little gripes "for (I, 0, dimension_size(ArrayX, 1)-
> 1)" for example. I know the dimension_... comes from the multidimensional
> arrays, but are they still needed when we have arrays of arrays? "for (I,
> 0, size(ArrayX)-1)" or "for (I, 0, size(ArrayX[5])-1)".

Genuine multidimensional arrays are easier to set up:

     #declare Foo = array[10][10];

as opposed to:

     #declare Foo = array[10];
     #for (I, 0, 9)
         #declare Foo[I] = array[10];
     #end

Also, they guarantee that the size of the second dimension is constant, 
whereas arrays of arrays might have different sizes in the second dimension.

They are also more memory-efficient, especially if the last dimension is 
comparatively small.

And I guess they are also more efficient in terms of performance, 
although that might not show much in comparison to the general slowness 
of the current parser.


> So, no brand new syntax for me, but a cleaned up version as close as
> possible in functionality as the current one.

> No OOP.

I hope you'll be fine with structured data aggregates at the very least 
(think POV-Ray v3.8's dictionaries).

And since dictionary entries can be functions (or at least should be 
able to; not 100% if that currently works), and I'm determined to make 
functions more powerful (wouldn't you want to be able to write tiny 
little programs in functions, if only to more easily work with interim 
results?), OOP will probably enter the scene as a side effect.

If it weren't for the special syntax of macros (`#macro Foo() ... #end` 
instead of `#declare Foo = macro() ... #end`)

Also, my goal is to formalize the object, pattern and whatnot syntax 
more, which will feature OOP at least under the hood. And wouldn't it be 
nice to implement custom objects that look and feel just like the 
inbuilt ones, syntax-wise?

> Would iterators,
> generators make sense? I doubt it.

I'm not quite so sure. Unless we provide a goot set of container-style 
inbuilt data structures (which _are_ useful after all), people will 
start to use structured data aggregates to roll their own, and end up 
with the desire to use them in a nice elegant `for myElement in myArray` 
(or alike) loop. That'll be difficult to implement generically without 
the concept of an iterator.

The good news is that iterators are just a matter of proper 
implementation, once you provide OOP basics.

> No async.

Sure? It would allow users to leverage multiple CPUs even during parsing.

> Minimal to no functional
> stuff.

If you mean syntax to support functional programming, I agree. I can't 
wrap my head around that paradigm anyway, so I doubt I could design or 
even implement a language to support it properly.

If you mean powerful syntax for functions, I disagree. I do want at 
least the ability to easily compute interim results in functions.

> Also something that relative easily can be converted from old to
> new (probably impossible given how the SDL can be 'abused').

You're probably right there: It would be a pain to write a converter. 
Because it is a pain to write a parser for the current SDL in the first 
place.

> Under the hood? I would like to have more access to all kind of variables
> POV-Ray calculates so we can create 'things' (textures) depending on
> those results.

Ooooh... so maybe some OOP features after all?

Also: Can you be a _little_ bit more specific?

There's a lot of stuff POV-Ray calculates under the hood, but only a 
fraction thereof can reasonably accessed from SDL.

> Ok, now for the crazy one: Wasm. https://webassembly.org/
> I like how the compiled functions in math.inc work through an include
> file. I like the ideas of adding more of those.
> I even more like the idea if we could write dynamic linked libraries,
> call them from POV-Ray using a compagnion include file. (something
> simmilar is done in SuperCollider c++ for the audio server and a *.sc
> file for the scripting side).
> Now, what if these wasm's can be used as 'dll's'. It would make them
> platform independent plug-in's. Reduction of maintenance. There are a lot
> of languages that can be compiled this way, proper toolchains et al.

I don't think that will happen, at least not anytime soon. Allowing for 
arbitrary binaries to be plugged in can open up quite a can of worms, 
security issues being only one of them.

Also, I'm sure such plug-ins _will_ create intersections with the world 
of OOP.

> Or, the other way around. Could it be made possible to convert a parsed
> file into 3D printer data more easily, with checks for holes we don't
> need when tracing? OGL visualisations?

Possibly, eventually. Long road there. But that's less of a parser 
matter, and more of a render pipeline thing. We need to pull that apart 
in order to more easily provide SDL-level access to its elements.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Also, I
> think it would be more productive to name those features that you like
> about it, rather than just (to put it into more blunt of a picture than
> adequate here) point in the general direction of the language and say,
> "I like some of the stuff that's in there, see if you can spot it".


> One of the results is that different Tcl statements may have their own
> individual quirky "micro-syntax". Just like all of POV-Ray's individual
> geometric primitive, pattern and what-have-you statements all have their
> own little "micro-syntax" quirks. Any commonalities between them are
> just superficial conventions. Which bothers me to no end.
>
>
> In my opinion, the best approach to judge a language for suitability as
> the basis for a new SDL is to ask (and answer) the following three
> questions:
>
> - "What is the 'grammar' of this language, i.e. the core principles that
> govern its syntax?"

As I (and probably most of us) have never really dissected, analyzed, and
evaluated a computer language like that, let alone several - to be able to
compare and contrast - this is likely going to be tough issue to address.
Maybe provide an example or a link to exactly the kind of thing you're talking
about here.

> And based on that:
>
> - "How would a simple scene be described in this language?"
> (A chrome sphere on a colorful checkered plane, with camera and all, and
> maybe a text object to showcase strings, should do as a first example.)
>
> - "How would programmatic elements mesh with this syntax?"
> (A simple example with a loop and a few conditionals should be a
> reasonable starting point.)

Now, I can only chime in here with the things I've seen.
OpenGL and Shadertoy seem to have all/most of the things that we want, and
OpenGL is well established, and presumably geared specifically towards graphics.
;)
It seems like a fairly easy and relatively intuitive language for anyone who's
done "regular" basic programming, and played with some of the patterns and
isosurface/parametric stuff.   It seems to be compiled, fast, and have really
user-friendly function and vector features, which would be essential.

I've seen people program things in c++ and python, and I kinda hate it.
I've seen some stuff in Processing and P5JS, but only a very limited amount.
I've heard mention of Lua and Haskell...  :D

Some of things I like about the OpenGL and P5JS work, is that there's a looping,
continually updating output - somewhere - and I wish we had the capability to
have  "a running program that outputs graphics" in place of / in addition to the
2-step edit-then-render a single static image paradigm that we have.

I guess since the languages exist and there are plenty of examples, the syntax
issue can be left to folks better informed than I, but the last two questions
can be seen in action, where objects, light sources, shadows, reflection models,
geometry, and program control directives are all used to create a scene.

In my head, I'm envisioning that an interim "meta-POV-Ray" could be implemented,
where everything is written in user-accessible include files, and a "free for
all with rules" ensues, where people can "access the source code" (the include
files) and edit it to produce new objects, algorithms, reflection models,
geometries, and even object and command syntaxes.  People can then have their
own "anything goes" forks, but team contributions for serious consideration need
to adhere to certain established conventions.   Then a sort of natural evolution
could be allowed to play out, and the various strengths and weaknesses of each
approach could be tested by the community as a whole.

We could have whole algorithms to generate shapes and textures rather than
functions, persistent variables across renders, and a host of other things I
likely can't think of off the top of my head.

The interesting parts that I see about this approach, are that (lets take
Shadertoy as a specific example) the "core" of the application isn't
intermingled with the _things_ that the core handles.  It's a programming
language who's end product is primarily a colored pixel on the screen, but all
of the basic primitives lie outside of the core and are just macros of sorts.

As such, it's wide open to the user to do as they please with.  That takes a lot
of development pressure off the devs and lets users so inclined to code up
whatever cameras, lights, shapes, and patterns that they can think of.  It also
addresses one of the issues that constantly pops up on the forums about "Why
can't POV-Ray...", because then it's easy to point them to the include file
they're invoking for - let's say a shape.  It may be written with very
meaningful variable names or extensively commented, and the actual code that
makes the shape they are interested in is right there for them to see.  It's a
wonderful learning experience for people interested in computer graphics.

POV-Ray's pigment pattern equations are beautiful in their simplicity, and some
of the more complex ones are a wonder to behold.  I'm often sad that the logic
of the pigment patterns isn't up front in the documentation, because it gives a
new user a WAY to think about exactly how the magic on the screen happens.

Most of the people "out there" are POV-Ray _users_, and as you have pointed out,
may only use it as the last link in a software workflow chain.  Most of use
_here_ are "only" users, and not developers who have a good-enough grasp of the
source code and how it all fits together to get to the part that colors the
current pixel.  Something that is still usable but draws the more-than-casual
user into deeper quasi-developer territory would, in my opinion, help address a
lot of the things that we are struggling with.
Basic understanding of "how it all works"
Educating people with programming and mathematical aptitude to make parts of
POV-Ray their own and put on the developer hat.
Greater freedom to edit the source, and a nimbler evolution of future versions.
Less reliance on only 2 or 3 people who know how anything works to a great
enough degree to actually make or change something without breaking the rest of
it.
The addition of new features to POV-Ray, since greater experience with writing
"SDL" de facto translates to writing POV-Ray "source code".
In the case of Shadertoy, it's a browser-driven software, which makes it
inherently cross-platform.


Obviously, there are going to be problems with any of the points I made, and
some are likely painfully naive to the experienced software developer, and
especially to you and others who have a top-down view of the whole inner
workings of the source code and the interplay of all the dependencies - but I'm
just sharing my ideas in this rap session.  Sometimes some of them actually turn
out not to suck.  ;)

Post a reply to this message

Am 15.07.2021 um 02:12 schrieb Bald Eagle:


> OpenGL and Shadertoy seem to have all/most of the things that we want, and
> OpenGL is well established, and presumably geared specifically towards graphics.
> ;)

I have to ask what exactly you are referring to when you say "OpenGL". 
At its core, OpenGL is a library (or, more specifically, a library API): 
A collection of functions that can be called from various entirely 
different programming languages. The most "native" of those would be C/C++.

Are you perhaps referring to the shader language of OpenGL (GLSL)?

If you love GLSL, then I'm surprised you "kinda hate" C++.

Also, I'm not quite sure how a POV-Ray scene could map to GLSL. It seems 
to me like it would have to be described in as clunky a way as it would 
in C++.


In essence, most program languages have an imperative approach at the 
lowest level; to describe data, you have to instruct the computer to 
assemble it step by step, like so (pseudocode):

     Create a sphere S.
     Set the radius of S to 5.
     Set the center of S to <0,1,0>.

     Create a texture T.

     Create a pigment P.
     Set the pigment's pattern to 'checker'.
     ...
     Attach P to T.

     ...
     Attach T to S.
     Attach S to the scene.

Rather than using a descriptive approach, like so:

     The scene has the following objects:
     - A sphere, with the following properties:
       - a radius of 5.
       - a center of <0,1,0>.
       - a texture with the following properties:
         - a pigment with the following properties:
           - pattern 'checker'

While the difference may not seem obvious at first glance, it tends to 
make a huge difference in terms of how much repetitive stuff the syntax 
requires. For example, in C++ it might be written like so:

     Object S = new Sphere();
     S.radius = 5;
     S.center = Vector3(0,1,0);
     Texture T = new Texture();
     Pigment P = new Pigment();
     P.pattern.set('checker');
     ...
     T.addPigment(P);
     ...
     S.addTexture(T);
     Scene.addObject(S);

whereas in a descriptive language it might be as simple as:

     sphere {
       radius 5
       center <0,1,0>
       texture {
         pigment {
           pattern 'checker'
           ...
         }
         ...
       }
     }

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 14.07.2021 um 11:35 schrieb jr:
> > have you looked at Tcl/Tk yet, for inspiration?  has many (imo) natty features,
> > nice, clean syntax, and byte-compiles.
> ...
> At a very first glance, Tcl/Tk sounds like a promising basis: Its main
> purpose (nowadays) is also to describe hierarchical structures (albeit
> not geometric objects and surface properties, but rather GUI elements),
> with programmatic elements mixed in for good measure. Unfortunately, the
> Tk part (which is the description of GUI elements) was bolted on later,
> and in my opinion it shows. At its very core, Tcl is a command
> shell-style scripting language.

yes and no.  I'd argue that the interpreter is the core.  and that is designed
to be extended (with "package"s and other mechanisms), and designed to be
embedded, that is provide scripting support to an application.


> One of the results is that different Tcl statements may have their own
> individual quirky "micro-syntax". Just like all of POV-Ray's individual
> geometric primitive, pattern and what-have-you statements all have their
> own little "micro-syntax" quirks. Any commonalities between them are
> just superficial conventions. Which bothers me to no end.

would not, in the end, a database "backbone" allow to, bit by bit, reduce the
"chaos"? (for instance, the stuff provided in the many /include/ files, if
pre-processed and stored in a db, could then allow the parser to simply "paste"
the code actually used, on demand so to speak)


> In my opinion, the best approach to judge a language for suitability as
> the basis for a new SDL is to ask (and answer) the following three
> questions:
>
> - "What is the 'grammar' of this language, i.e. the core principles that
> govern its syntax?"
>
> And based on that:
>
> - "How would a simple scene be described in this language?"
> (A chrome sphere on a colorful checkered plane, with camera and all, and
> maybe a text object to showcase strings, should do as a first example.)
>
> - "How would programmatic elements mesh with this syntax?"
> (A simple example with a loop and a few conditionals should be a
> reasonable starting point.)
>
>
> When I do that for Tcl/Tk, I find that the results look - in my mind -
> ugly AF.

agree that "just translating" does not work too well.  and the fact that Tcl
does not provide "traditional" arrays is another drawback.  still (biased and
all) I think that owing to its design, a SDL/Tcl could make a "nice hybrid".


regards, jr.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> to allow for a compiling rather than interpreting parser.

I'm so glad I asked the question ! Now not only am I fully convinced by all of
your points ! But I
actually am pretty enthusiastic ! Thanks to the last line,  about your proposal:
compiled POV scenes, wow ! that sure is a great benefit. And just to make sure I
didn't get you wrong, this means some speed increase too, doesn't it?

Post a reply to this message

Am 16.07.2021 um 15:35 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> to allow for a compiling rather than interpreting parser.
> 
> I'm so glad I asked the question ! Now not only am I fully convinced by all of
> your points ! But I
> actually am pretty enthusiastic ! Thanks to the last line,  about your proposal:
> compiled POV scenes, wow ! that sure is a great benefit. And just to make sure I
> didn't get you wrong, this means some speed increase too, doesn't it?

When re-running one and the same scene a lot, say, in an animation? Yes, 
most certainly.

When looping a lot in a scene, even if you render it only once? Probably.

When using a lot of include files that you tend to use over and over 
again? Or rendering a scene again that is structured into many 
individual files, and you've changed only a single one of them? We could 
probably get some performance win for that scenario, too.


When rendering a monolithic still scene, with very few programmatic 
elements, just that one single time? No, most likely not.


So we should have a way for the user to tell the parser which files to 
compile, and which just to interpret.

Post a reply to this message