In article <3fe4f632$1@news.povray.org>,
 "Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:

> What I've read on these groups so far seems to suggest that POV-Ray 4 will
> be more flexible on the "modding" side, for example stuff like *real*
> plug-ins, not just include-files.

This seems to be an oddly persistent misconception...almost as bad as 
the "4.0 will be GPL" one. POV-Ray does not support plugins because 
there is no platform-independent way of loading them, and the plugins 
themselves would be platform dependent, making for a support nightmare. 
This will not change when POV 4.0 is released. It would be possible to 
load platform-independent bytecode files like Java does, but there's no 
real reason to do so...you might as well just generate the bytecodes 
from source, and loading precompiled bytecode would not add any 
capability. It would be slightly faster, but source compiling won't be a 
speed bottleneck like scene parsing currently is...and even now, only 
include files that do heavy processing cause any slowdown.


> The new number shows that it'll be a complete rewrite,

Because of it being a rewrite, it merits a full version increase. A full 
version number increase does not indicate that it's a rewrite, however, 
only that it's a major update.


> and if I recall correctly, there were numerous times when
> someone mentioned that the new texturing model in 4 might be completely
> different from what we have today, to make room for a much more flexible
> texturing.

Any redesign and rewrite of the code will make it far easier to add this 
sort of thing.


> Making POV-Ray faster might be nice, though I don't really know
> how that could be achieved. To me, it seems like the way things are done
> right now are as efficient as they can get with this model (bounding boxes,
> vista buffers, light buffers, etc), and I don't really expect a speed-up,
> though maybe certain aspect might be made faster (media, isosurfaces, but I
> don't know what I'm talking about here, I just know that they're slow most
> of the time :-).

There are some changes that can be made. Better bounding systems, 
cleaning up of some of the current hacks...multi-processor systems are 
becoming more common, support for multi-thread rendering would give a 
big speedup on those machines.


> As far as
> I'm concerned: as long as POV-Ray is as stable as it is now, I can't
> complain. Some guru will come along and add the next feature I need. :-)

How does an update to the proximity pattern sound? A blur pattern? Or 
how about an extension to functions which lets you get the surface 
normal and ray direction in pattern functions?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message