The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Attached to Project: POV-Ray
Opened by Mike H - 2010-06-15
Last edited by William F Pokorny - 2017-04-10
Opened by Mike H - 2010-06-15
Last edited by William F Pokorny - 2017-04-10
FS#133 - Subdivision support
Someone built a version of Povray with internal support for automatic subdivision of meshes. See:
http://www.cise.ufl.edu/~xwu/Pov-Sub/
Would like to see this feature added natively to Povray.
I would love to see this implemented in 3.7! The size of the patch suggests it would not increase the .exe size appreciably. I would rather not have to rely on third-party includes to accomplish mesh subdivision in POV.
Why would this be a good feature to have?
1) small initial mesh size for distributing scenes
2) small initial mesh size for testing/previewing scenes
3) the patch can smooth any mesh, even without subdividing it
4) mesh creation in POV becomes possible for more people, since only basic meshes need to be created
5) it can crease the edges of any mesh
6) it supports uv_mapping
7) more shapes can be distributed with POV-Ray
8) it's pretty fast
I agree that subdivision is a nice idea to have, but not for 3.7, which is way to late in its release cycle to get new core features of this size.
I have a "small" issue with the current copyright/license of the subdivision code: it's ok for povray (future version included), but forbidden to other application (by default).
I believe it would corrupt the license of povray for source distribution. (how does the restriction survive in source distribution ?)
The license terms of that subdivision patch would be fine with the old POV-Ray 3.6 license, as that would forbid use of the code for anything other than POV-Ray (or a modified version thereof) anyway. (As a matter of fact, publishing any POV-Ray 3.6 derivative with code portions that don't go well with the old POV-Ray 3.6 license would itself be a violation of the 3.6 license).
However, the license is definitely incompatible with the AGPL we're aiming for with 3.7 (which to the best of my knowledge wouldn't per se prevent portions of POV-Ray code ending up in a coffee vending machine), and so ATM we can't just port that code. It would be a case of "ask the authors to re-license it under an AGPL-compatible license".
Now tracked on github as issue #272.