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.


FS#133 - Subdivision support

Attached to Project: POV-Ray
Opened by Mike H (SharkD) - Tuesday, 15 June 2010, 23:03 GMT
Last edited by William F Pokorny (wfpokorny) - Monday, 10 April 2017, 13:51 GMT
Task Type Feature Request
Category Backend → Geometric Primitives
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Very Low
Priority Low
Reported Version 3.70 beta 37a
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


Someone built a version of Povray with internal support for automatic subdivision of meshes. See:


Would like to see this feature added natively to Povray.

This task depends upon

Comment by Samuel T. Benge (stbenge) - Sunday, 20 June 2010, 17:17 GMT

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

Comment by Thorsten Fröhlich (thorsten) - Friday, 02 July 2010, 05:03 GMT

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.

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 07 February 2011, 21:24 GMT

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

Comment by Christoph Lipka (clipka) - Monday, 07 February 2011, 22:18 GMT

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

Comment by William F Pokorny (wfpokorny) - Monday, 10 April 2017, 13:51 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #272.