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