Warp <war### [at] tagpovrayorg> wrote:
> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > I have to say that I am not enamored with this idea. I see no need to
> > completely trash an SDL which has been in use for twenty years, and upon which
> > countless hours of work is based. I have no desire to completely retool all my
> > projects to use a new language.
> Having a new scripting language doesn't mean it's not possible to have
> backwards support for the current one.
Of course you can set backwards support with the #version keyword, but that
doesn't allow you to use the old syntax while leveraging the new features.
> > I am not opposed to extending the SDL with a built-in scripting language like
> > script-fu (just an example) it could be useful; but I see no need for a complete
> > change of syntax.
> The current scripting language is too rigid and awkward, IMO. After all,
> it is a hack over a hack over a hack, built up during the decades. It's also
> very slow to interpret. Adding even more hacks on top of it isn't such a
> great idea.
> Trying to embed a new scripting language inside the current SDL is only
> going to severely limit what that new language can do, as well as make
> things even more complicated than they are now (think about how much confusion
> user-defined functions cause currently).
> > That said, I have a few ideas for new features.
> > A skeleton/wireframe object which would consist of a set of control_points
> > defined as positions in space, perhaps using a keyword like relative_to which
> > would reference a list of other control points.
> > CSG objects could reference the skeleton/wireframe with a lock_to keyword which
> > binds the origin of the object to a specific control point such that when the cp
> > moves, the object moves with it.
> > introducing an aspect keyword which would have its own list of parameters such
> > that an object could not only be rotated using the rotate command, but could be
> > aligned with a vector such that when the vector was changed, the object would
> > shift, along with it while maintaining its alignment.
> A new scripting language would allow doing exactly those types of things
> without modifying the core engine of POV-Ray nor adding new keywords and
> new functionalities. (Basically you create new functionality by writing in
> the new scripting language.)
> > This is, however, not the central topic of my post. I was thinking of a method
> > by which the internal structures of the program could be extended with new
> > features via dropping extensions in a specified directory.
> Sounds exactly like "include" files, written using the hypothetical new
> scripting language.
I'm not going to try arguing this point, as I have no experience developing
programming languages, but I can't see how this would work. Again, however, I
am unfamiliar with the internals of POV.
Would this theoretical scripting language be able to provide me with the
necessary tools for general object collision testing?
Post a reply to this message