In article <pan### [at] NOSPAMml1net>,
 Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:

> 1. Overlay textures.

I think the layered texture syntax in general needs reworking. This and 
a mechanism for stripping all textures from an object, and perhaps a way 
of operating on specific sub-objects.


> 2. Faster scene file parsing

Switching from direct parsing to an interpreted opcode system would 
greatly speed parsing of complex code. However, doing it right could be 
difficult. It would mean very extensive changes to the language. The end 
result will probably be an interpreted language with a very flexible 
preprocessor, basically equivalent to the existing scriping language.


> 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.

This becomes less necessary with #2. Also, having them in an include 
file rather than built into the POV-Ray executable means users can look 
at and modify them, and they can be updated or added to separately from 
the main program. Some language extensions could allow them to be used 
as a built-in feature would be.


> 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?

This one comes up every so often...it'd be really complex to do, the 
data structures can be very complex. However, dumping the instructions 
for creating the object might be possible.


> 5. Lathe/prism hybrid. 

An interesting idea...generating a mesh would be fairly simple, and it 
might be possible to trace it directly.


> 6. Progressive Render
>     A lightwave plugin called 'fprime' gave me this idea. Basically a 
>     scene is rendered first without things like anti-aliasing, 
>     radiosity, photons, etc, and then the renderer uses intelligent 
>     algorithmns to determine where those would have an impact, and 
>     continually adds those details in. Basically you would allow the 
>     render to continue until the desired quality is acheived, at which
>     point it would be stopped. This would be handy when dealing with 
>     deadlines, as the scene could begin rendering when finished, and
>     then improved by the renderer up until the deadline, at which point
>     the render as stopped and you take the result.

Not really practical, at least not in the way you describe. It would be 
either extremely slow or outrageously memory consuming, or both. 
Lightwave probably uses some form of scanlining for this, and just 
refines lighting maps...POV can not do this, being a raytracer and not 
using light maps.
However, it would be possible to continuously update antialiasing, or to 
do a low quality render, refine the radiosity and photon data, and then 
do a higher quality render.


> 7. Spline curves
>     What I mean by this is taking a 2d curve, as used in a prism, etc,
>     and drawing it 'along' a spline. Useful for making troughs, gutters,
>     many organic things, etc, especially if a start scale and end 
>     scale could be specified.

You're talking about spline sweeps? They're already possible...just 
build a mesh using the built-in splines.


> 8. A C(++) API
>     This is another way of acheiving some of the above speed-related 
>     goals. Allowing creating a pov-scene by linking against the API,
>     giving code that builds a binary to render the scene. The ultimate
>     for CPU intensive stuff.

Not practical. There is no standard way of loading object code on 
different platforms, and the code itself would have to be compiled for 
the platform the scene is to be rendered on. Including a compiler along 
with POV would be a lot of effort, and distributing precompiled code 
would create compatibility problems.


> 9. A larger included texture library
>     I'd really like to see some texture includes based on actual
>     material properties. Things like the exisiting golds.inc/metals.inc
>     are a good start, but more is always a good thing.

I agree, and a lot of the existing textures simply do not work well with 
modern scenes. For instance, things like high ambient values that make 
them look really bad when you have radiosity, or simply not using more 
realistic features added since the texture was created. It would be a 
huge amount of work, though. Perhaps a community project...


> 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 would be a bad idea...incompatibilities, trying to keep up with the 
latest version of the format used by the software, etc. However, the 
ability to load the geometry from some common, more generic formats 
would be useful. Doing more than just the geometry and perhaps UV-mapped 
textures would be difficult or impossible, because of differences in the 
way POV-Ray works and the features it offers.

-- 
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