Warp <war### [at] tagpovrayorg> wrote:
> > I don't think, however, that JIT-compiling would make any sense or be an option:
>
>   I don't see why not. Many scripting languages have that.

Damn it, Jim, POV is a raytracer, not a general-purpose IDE - and our human
resources are limited.

>   POV-Ray 4 was supposed to be a complete rewrite anyways. If it is, then
> it should be done properly.

If the intention is to do a *complete* rewrite, then why waste time on a 3.7,
which already is a major architectural overhaul?

>   A simple core engine (only things which require speed should be there),
> a simple script interpreter. Everything else as libraries written in the
> scripting language. Let the complexities be inside the libraries, not in
> the core engine.

No, Sir. We're talking about an application that is performance-hungry anyway,
so there should be a way to implement certain things in binary code, yet
separate from the core engine to keep that simple. Otherwise, we will sooner or
later end up with stuff that *does* need speed, and gets hacked into the core
just because there's no clearly defined way to interface binary stuff to it
properly.

Rather do it the other way round: Provide an interface for binary add-ons, then
implement the script language as such an add-on.

Scripting most parts of the software is ok when performance is not paramount,
like e.g. a web browser: You want it to be fast, but more importantly you want
it to be safe, comfortable etc., and you probably can't tell the difference
whether a page takes 0.5 or 0.6 seconds to load. You can tell the difference,
however, whether an animation takes 5 or 6 days to render.

>
> > This would presume that the SDL in fact provide an interface to define new
> > geometric entities. These would have to be render-time code.
>
> > I don't really think there is much use for such objects, and that instead giving
> > more flexibility to functions to be used in isosurfaces is the way to go.
>
>   I consider those sentences contradictory.
>
>   "There's no use for user-defined objects. Instead, we should enhance
> the properties of usef-defined objects (isosurfaces)."

Isosurfaces provide a simple, single-function interface to define objects.
Internally in POV, however, the interface is much different, and consists of
multiple methods: One to compute ray-object intersections, one to perform an
inside test, one to compute the surface normal for a given point, and so forth.
So when I hear "user-defined objects", I think of exposing *that* interface.

To me, isosurfaces are just that: Isosurfaces. A hard-coded shape that just
happens to be very flexibly parameterizable.

Post a reply to this message