I've been thinking about things I would like to see in the next generation of
POV, so thought I might as well throw them out in the wild...

1. Separation between editor and renderer on Windows. I work a lot with
extremely large scenes and often find them run out of memory, especially if I
make a mistake with loop bounds in scripting. If this happens I have to kill the
renderer, which means I lose the editor as well. I think keep the renderer as
simple as possible. Make it purely command line, and have the editor invoke it
when necessary, much like an IDE/compiler relationship.

2. A two-stage render, kind-of similar to a compiler/linker approach with a
suitable binary intermediate file format. This would allow multiple-file
renders, allowing small changes to be made to one file without reparsing the
whole scene. Especially useful for large scenes. The program could of course do
both stages in one go by default, with a command-line flag for doing the first
stage only, much like most compilers.

3. Built-in distributed rendering. The current message-passing mechanism between
fronent and backend should be able to be extended to allow passing messages
between machines. It could communicate via TCP, even for local renders. The
volume of communication is minimal during rendering, so it wouldn't cause much
slowdown.

4. The SDL is a tricky one. A declarative language such as we have is great for
quick or static scenes, or for beginners, but very limited for advanced scenes
that require scripting or procedural generation. The current dynamic
capabilities have a definite "afterthought" flavour (of course, they were
initially). They also make parsing extremely difficult - I've tried doing this
for doing syntax highlighting and scene analysis but gave up and just stuck to
basic lexing. A proper procedural language would make the parser much simpler
and the language much easier to learn. Preferably one that can be written with a
parser generator (such as antlr4 or re-flex or something like that). If we went
down the path of generating intermediate files that the backend renderer would
"execute", then there could even be two languages that generated the same
intermediate file structure, allowing the best language for the job to be
chosen, or even mixed in one scene in different files.

5. GPU rendering has been brought up several times before. It would be nice, but
difficult. Lack of double-precision floating point support and limited memory
would almost negate any speed advantage.

Have fun picking holes! :-)

Post a reply to this message