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