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