Tyler Eaves <tyl### [at] nospamml1net> wrote:
> 1. Overlay textures.
>     I'd like the ability of give an 'overlay texture' to a group
>     (e.g. union, object, etc) that would work as an additonal layered
>     texture above all the constituient objects textures. Useful for
>     adding things like dust, grease, moss, that kinda thing, without
>     having to go back an add to every object.

  This would certainly be useful.

> 2. Faster scene file parsing
>     I'm a computer programmer by trade, and I often do scenes that are
>     very 'programatic', with lots of 'while' loops, and the like, and
>     frankly, the POV-Ray scene parser is really slow. This is really
>     obvious with something like POV-Tree, and animations can really 
>     be an issue, especially on a relatively slow machine like mine
>     (950mhz Athlon). I'm not quite sure what to do to improve things,
>     but I would guess that the parser is working with the text directly
>     , and not some sort of bytecode, or similar.

  POV-Ray's scene parsing is certainly very slow. This is mainly for
historical reasons. The first versions of POV-Ray (up to 2.2 if I don't
remember completely wrongly) did not have any "scripting language" per se.
It was a pure scene description language, with no flow control commands,
and thus it really didn't need to be very fast. Thus it just parses and
interpretes the text directly.
  Flow control commands (#if, #while, #switch, #macro, etc) were added
afterwards because the need for them was overwhelming. However, they
were added on top of the old parser and are bound to its limitations.
  Optimizing the parsing needs a complete redesign of the parser. Probably
the best way is to do it the same way as perl does: Perl compiles the
source code to bytecode and then interpretes this bytecode, which makes
it pretty fast.
  I wouldn't be surprised if a future version of POV-Ray would do exactly
this. In fact, part of the current parser already does this: The function
parser/interpreter (this is the reason why functions are so fast compared
to eg. #macros).

> 3. Implementation of transforms.inc in C
>     This kinda ties into #2. I find myself using this file a lot,
>     and it would be nice if these functions were implemented natively.

  I tend to disagree with this. Specially if a future version of POV-Ray
has the abovementioned optimizations, the need for a core code implementation
of these features is lessened.

  There are actually more advantages than disadvantages in having features
implemented with the POV-Ray SDL: They are more flexible (you can change
or enhance them easily) and they don't clutter the core code of POV-Ray
(the larger the source code, the more bugs it will contain). It's also
easier for people to learn from them.
  The disadvantage is that you can't implement every imaginable feature
with the SDL because of its limitations (for example a renderman-style
shader engine would be something impossible to do with the SDL), and
naturally speed is an issue.
  The advantage of a core code implementation is speed. The disadvantage
is that the feature is then hard-coded, it can't be easily changed or
enhanced, and it adds to the clutter of the source code (adding the
probability of more bugs). It's also harder for people to learn from it.

> 4. Ability to dump a object to a binary format
>     This goes with 2. and 3. above. The desire here is to cut to the 
>     chase and provide an efficient way to save and load objects. Again, 
>     the idea here is to greatly reduce the speed hit for "recursive
>     objects". I don't think things like platform or version independence
>     are a big deal here, so maybe this wouldn't be too hard to code?

  If bytecode compiling/interpreting is implemented, then this feature
shouldn't be a problem.

> 10. Better support for 3d Object formats
>     I'd love to be able to to use things like Wings3D (or 3DS Max, etc)
>     objects in my POV-Scenes directly.
>     Maybe using a syntax like:
>     extern_object{wings3d "foo.wings"}

  This has maintainability problems. As you have noticed, new versions
of POV-Ray are not published every other week (and there are very good
reasons for this). New versions of popular 3D formats come out much more
often than new versions of POV-Ray. See the problem?

  Enhancing the SDL so that it can read and parse these file formats
would be a much better solution. SDL libraries are much easily updated
than POV-Ray itself. Besides, this solution is more generic, flexible and
thus better.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message