Jim McElhiney wrote:
> 
> [...]
> Not even sure how the POV team works these days,
> i.e., who keeps the ball for making new official patches, or
> (for that matter) whether or not anyone is interested in my bug fixes.

In case of bug fixes i'm pretty sure the Team is interested in including
them in the next official release (3.51).  If you have more elaborate
changes this will be greatly appreciated for MegaPOV (3.51 is a bugfix
release so there will be no new features).

While you are here - something that has wondered some of us lately is how
the 1600 sample ray directions which are hardcoded in the program are
originally generated.  There have been some affords to generate a better
distribution (and the possibility to use more than 1600 rays).

> If you build your own versions, and if you're interested, I can suggest a
> VERY quick hack (not a real bug fix) which will fix one big error.
> In radiosit.cpp, around line 844 where it calls ot_index (there is only
> one call), the second parameter is (and always has been) wrong.
> (it is correct for top level light collection only, but does not allow
> for the situations where the error bound gets adjusted on the fly,
> which happens with recursion depth and with low-radiosity-contribution
> points)
> I'm working on the exact expression, (depends on the implemention
> of other things, such as recursion limit depth), but if you just take the
> value
> there and multiply it by 3 or 4 your images will look better, by
> avoiding some discontinuities in shading.
> This will make results more correct and *very* slightly slower.
> (it will make searches in the octree a bit slower, by considering
> a few extra nodes, but that's pretty quick integer stuff, not like
> tracing more rays).

Sounds interesting, i will try it.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message