 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I understand that it's difficult to add new features with the pressures of a
full-time job to worry about, and it takes a very special sort of programmer to
be able to dig through the documentation to find just the right parts to modify
when doing a custom compile.
With this in mind, there is something I've been wondering for a long time, now:
Might it be possible since, if memory serves, version 4 will be a complete
rewrite anyway, that one of the improvements might be the ability to extend the
functionality with plugins?
I don't know how it would be accomplished, but it might allow features like
mechanics simulations, inverse kinematics and general collision detection to
name a few, to be added with a minimum of fuss. And best of all, people wishing
to use these features need only to download the proper extensions, and not have
to worry about using different versions of the program.
Please tell me what you think of the idea.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye <Sha### [at] spamnomore hotmailcom> wrote:
> With this in mind, there is something I've been wondering for a long time, now:
> Might it be possible since, if memory serves, version 4 will be a complete
> rewrite anyway, that one of the improvements might be the ability to extend the
> functionality with plugins?
Well, it has been suggested that version 4 would have a completely
redesigned scripting language which will be significantly more expressive
and faster. If it ever sees the day of light, it will be possible to do
almost anything with it. (I envision it to be like a programmable shader,
but even more expressive and usable in even more situations.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > With this in mind, there is something I've been wondering for a long time, now:
> > Might it be possible since, if memory serves, version 4 will be a complete
> > rewrite anyway, that one of the improvements might be the ability to extend the
> > functionality with plugins?
>
> Well, it has been suggested that version 4 would have a completely
> redesigned scripting language which will be significantly more expressive
> and faster. If it ever sees the day of light, it will be possible to do
> almost anything with it. (I envision it to be like a programmable shader,
> but even more expressive and usable in even more situations.)
>
> --
> - Warp
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.
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.
Keeping in mind that I haven't had time to look at the code much.
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.
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. Such as GIMP and
Photoshop use, but perhaps more powerful. The extensions might be comprised of
a zip file containing a text file which references precompiled headers and
specifying the methods those headers access/extend. When loading, POV might
link to these extensions, so that scenes can use their features.
There's probably a more elegant method than the one described above, but I
haven't had time to think all the way around it yet.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> Would this theoretical scripting language be able to provide me with the
> necessary tools for general object collision testing?
I don't see why not. If it's as expressive as any regular programming
language, there shouldn't be any problem.
The advantage of such a scripting language is that you can do tons of
stuff (which aren't possible currently with POV-Ray) without having to
modify POV-Ray itself, and it will be completely portable (iow. it doesn't
depend on platform-specific code, dynamic linking, or the like).
(Of course the disadvantage is that, being an interpreted language, even
if byte-coded, it will be slower than native code. OTOH many features do
not need extreme speeds.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Would this theoretical scripting language be able to provide me with the
> necessary tools for general object collision testing?
I'd expect the new scripting language to provide no additional
functionality that cannot be done with the current SDL in /some/ way or
another already, except for providing a more powerful language to define
"function" patterns.
In that sense - no, general object collision testing will not be
possible with it.
However, the new language could be expected to be much faster to
execute, and provide new language constructs allowing much easier
handling of aggregate data, so that an approximated object collision
testing based on trace() or inside() tests might become viable at
reasonable quality and script coding effort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> I'd expect the new scripting language to provide no additional
> functionality that cannot be done with the current SDL in /some/ way or
> another already, except for providing a more powerful language to define
> "function" patterns.
If that would be the case, it would be very disappointing.
I would expect the new language to allow doing a lot of things that are
not currently possible. For example, it should allow creating a texture
that says "shoot a ray in this direction (which is calculated from the
intersection point, normal vector and possibly other parameters), return
all the data for the surface it intersects and the intersection point,
and use this as the color of the texture". (Just this alone would allow
a multitude of very diverse features, such as adaptive blurred reflections,
portal textures, ambient occlusion, and so on.)
> In that sense - no, general object collision testing will not be
> possible with it.
Given that collision testing is possible with the current SDL (even if
it would be laborious, awkward and slow), why wouldn't it be possible with
the new one?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
