|
288 | Geometric Primitives | Possible Bug | 3.70 RC7 | Very Low | Low | Tolerance problem with refraction in blobs in CSG inter... | Tracked on GitHub | |
|
Task Description
If a blob is intersected by something else, the composite object has incorrect refractions if it is too small (in absolute units). Having the same object constructed without a blob, the errors happen at much smaller scales. The errors don’t affect solid objects, just refractions.
An example shows a half-sphere, constructed as CSG sphere + plane, and identical half-pshere, constructed as CSG blob + plane. When the scale of the entire construction is changed, the refractions disappear first for the blob, and at 100x times smaller scale, also for the sphere. The right side shows the solid version, showing that the surface intersection test is ok, it’s just the refraction that fails.
The problem is not present when looking from the curved side (the blob side). So the ray that hits the blob, gets refracted correctly, but the ray that hits the intersecting plane first, and should then refract in the blob from the inside, doesn’t work. If in attached sphere, you exchange -y with y in clipping planes, everything is ok.
The scale when this happens is not very small - blobs of radius 0.02 already fail (noticed because in 1=1metre scale, blob raindrops on a glass plate didn’t have intersections when looking from the back).
Examples are named by factor=9,0.9,0.09,0.009 and you can see first the blob (top) refraction gets smaller and disappears, then later the bottom (sphere) also gets the same problem.
|
|
289 | Light source | Possible Bug | 3.70 RC7 | Very Low | Low | area_illumination with light fading and scattering medi... | Tracked on GitHub | |
|
Task Description
with reference to http://bugs.povray.org/task/46
still some issue with area illumination and light fading when interacting with media
seems light fade is not taken into account with scattering media. emission and absorption media seem to work fine. occurs with all scattering types.
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
#declare Light = 3; // light 1 = individual lights
// light 2 = standard area light
// light 3 = area light with area illumination
#declare Fade = 1; // light fading: 1 on, 0 off
#declare Media = 1; // media 1 = scattering
// media 2 = emission
// media 3 = absorption
#declare Type = 1; // scattering media type
#switch(Light)
#case(1)
#declare Ls = light_source {
0
1/7
#if(Fade) fade_distance 2 fade_power 2 #end
}
union {
object { Ls }
object { Ls translate .5*x }
object { Ls translate x }
object { Ls translate 1.5*x }
object { Ls translate -.5*x }
object { Ls translate -x }
object { Ls translate -1.5*x }
translate y
}
#break
#case(2)
light_source{
y
1
area_light 3*x, z, 7, 1
#if(Fade) fade_distance 2 fade_power 2 #end
}
#break
#case(3)
light_source{
y
1
area_light 3*x, z, 7, 1
#if(Fade) fade_distance 2 fade_power 2 #end
area_illumination on
}
#break
#end
cylinder { <0, .01, 0>, <0, 5, 0>, 2 pigment { rgbt 1 } hollow no_shadow
interior {
media {
#if(Media = 1) scattering {Type, 30 } #end
#if(Media = 2) emission 2 #end
#if(Media = 3) absorption 2 #end
density { cylindrical turbulence 1.5 scale <1, .14, 1> }
}
}
scale <.15, 1, .4> translate 4*z
}
plane { y,0 pigment { rgb .7 } }
plane { -z,-7 pigment { gradient y color_map { [.5 rgb 1][.5 rgb 0] } } }
union {
sphere { 0,.05 }
sphere { .5*x,.05 }
sphere { x,.05 }
sphere { 1.5*x,.05 }
sphere { -.5*x,.05 }
sphere { -x,.05 }
sphere { -1.5*x,.05 }
translate y
hollow pigment { rgbt 1 } interior { media { emission 10 } }
}
|
|
292 | Geometric Primitives | Unimp. Feature/TODO | 3.70 RC7 | Very Low | Low | Arbitrary containing object for isosurfaces | Tracked on GitHub | |
|
Task Description
A low priority thought for the future: isosurface now only allows contained_by to be a sphere or a box. It would be more intuitive to allow the same objects that are allowed in clipped_by and bounded_by (although it probably needs to be finite). It would enable allow much faster rendering in many cases:
1) There are a lot of cases when the sphere or a box are very bad in bounding - if an object has a hole, a torus may be better, and in many cases, cylindrical bounding would help a lot. 2) Sometimes, having a too large contained_by object includes far-away parts of the iso-function, and expose large gradients that you want to avoid. If a bounding object is better, you can decrease the max_gradient and speed up the render. 3) The isosurface is usually much more expensive to calculate than any normal bounding object, so it’s an improvement even if the intesection test is not as fast as bounding box. 4) A typical case: if you use texture-like functions to make the surface realistically rough, you know almost exactly what the bounding object is - it can be the original unmodified object. 5) For isosurface terrains, a preprocessing macro could create a rough mesh-like bounding object to contain the “mountains”, thus making everything faster. 6) In case you want clipping, having the contained_by set to the same object probably avoits calculating too many intersections.
The main modification is probably that the intersections of bounding objects can be split into more than one interval - but it’s probably worth it, the isosurfaces are usually a speed bottleneck.
|
|
293 | User interface | Possible Bug | 3.70 RC7 | Very Low | Low | POV-Ray Shown Twice in Windows Taskbar | Tracked on GitHub | |
|
Task Description
When rendering for some time, it occasionally happens that POV-Ray appears twice in the Windows taskbar. One button is the normal one, the other one does not open any window when clicked on and reads something like “99% complete” (see attached image), like the render window’s title, but obviously unrelated to it (probably the title the render window had shortly before?). After stopping the render, the odd taskbar button remains there until POV-Ray is closed.
Observed under Windows XP
POV-Ray 3.7.0.RC7.msvc10-sse2.win32
When applications are summarized into groups in the taskbar by Windows, the odd POV-Ray button is attached to the Windows Explorer group
Run with render priority set to “high”
Is this a Bug in Windows or in POV-Ray?
|
|
295 | User interface | Definite Bug | 3.70 RC7 | Very Low | Low | Minor GUI Bugs | Tracked on GitHub | |
|
Task Description
Here are two low-priority bugs in POV-Ray’s GUI, observed by me under Windows XP, which should be easy to fix I think:
In the “Insert” menu, there are sub-menus (e.g. “Radiosity and Photons”) in which there are menu seperators at the end of the popped-up menu bar.
The progress bar in the top-right corner of the editor window seems to be too large for the window (203px) and therefore clipped. As a result, progress seems to be 100% when it is not yet, e.g. at 90% progress. (Have not measured exactly.)
Both bugs are not severe at all, but it would be nice if they could be fixed. By the way, a second progress bar could be added to visualize the number of frames already rendered in an animation.
|
|
299 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Low | Object Properties Feature | Tracked on GitHub | |
|
Task Description
Up to POV-Ray 3.7 RC7 it has not been possible so far to declare custom properties for POV-Ray’s objects, which would be especially useful for complex objects defined in include files.
Currently, if you want to have an object (e.g. a car) with certain variable parameters (e.g. colour, wheel rotation, ...) defined in an include file and the parameters set by a scene file which uses the include file, you have to choose one of the following approaches:
1. use a macro
#macro car(colour, wheelrot, ...)
...
#end
or, 2. check parameters declared before, e.g.
#declare car =
union {
#ifdef (colour)
#local colour_internal = colour;
#else
#local colour_internal = default_colour;
#end
}
The resulting object would be used in the following way:
#include "car.inc" // include file once
object {
car(rgb <1,0,0>, 0, ...) // macro approach
}
// other approach
#declare colour = rgb <1,0,0>;
#declare wheelrot = 0;
...
#include "car.inc" // include file every time you want to have a car object instance
object {
car
}
Needless to say, both approaches are not quite optimal.
The macro approach needs only one #include directive and name conflicts will (hopefully) not be a problem. However, one would have to look up the parameter order of the macro in the include file, in the worst case every time the macro is used.
The other approach needs as many #include directives as car objects shall be instantiated, there can arise name conflicts with other inculde files used in the scene, and a (potentially long) list of parameters has to be declared before each #include. On the other hand, with this approach for any value it is clear which information it gives, e.g. #declare colour = rgb <1,0,0> can easily be read as ‘set car colour to “red”‘.
My suggestion would be creating an SDL feature to
One step up could be to even declare object classes along with them.
This could look like this:
// include file code
class car { // alternatively (without classes) use #declare car = object { ...
property colour = rgb <1,0,0>; // with default colour
union {
...
}
}
// scene file code
car { // alternatively (without classes) use object { car ... }
colour rgb <0,0,1>
}
Note that this solution makes the declarations much more concise and easy-to-read. Especially in scenes with many includes and animation scenes where objects’ properties have to be manipulated according to sometimes complex functions, this would be very useful. Please also consider that such user-defined objects can have dozens of properties.
|
|
302 | Other | Possible Bug | 3.70 RC7 | Very Low | Low | confusing error message when .ini file cannot be parsed | Tracked on GitHub | |
|
Task Description
When a command-line parameter in an .ini file cannot be parsed (such as “+a.3”), POV-Ray reports a “Problem with setting”, quoting the command line, rather than indicating that the problem occurred in an .ini file. This leads the user to think that the problem is with the command line itself, unnecessarily confusing him.
|
|
306 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | High | finish subsurface block before global_settings subsurfa... | Tracked on GitHub | |
3.71 release |
Task Description
The following scene causes a crash:
sphere {
<0,0,0>, 1
finish { subsurface { translucency 1.0 } }
}
global_settings {
subsurface { }
}
|
|
309 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | Warning Message Missing | Tracked on GitHub | |
3.71 release |
Task Description
Draw_Vistas, Light_Buffer, and Vista_Buffer (plus associated switches) do not issue warning when used, even tho code has been disabled.
|
|
310 | Editor | Feature Request | 3.70 RC7 | Very Low | Low | Editor should remember bookmarks | Tracked on GitHub | |
|
Task Description
Now the editor remembers only the cursor positions of the loaded files when starting a new PR session. It would be more friendly to remember whether the window was split or not, as well as the bookmarks.
|
|
311 | User interface | Possible Bug | 3.70 release | Very Low | Low | Elepsed time error on very long renders | Tracked on GitHub | |
3.71 release |
Task Description
On a very long render, around day 24, the elapsed time display becomes incorrect, showing 4294967272d 4294967272h 4294967272m 4294967272s.
Found on Windows 7 64 bits and reproduced on Windows 7 32 bits. NOT reported on other platforms.
|
|
319 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | Add interior to #default directive | Tracked on GitHub | |
|
Task Description
When working with predefined materials, it would be useful to have something like:
#if (!Use_photons)
#default { interior { caustics 1 } }
#end
#include "my_predefined_materials.inc"
Default medias or IORs could also be useful.
|
|
323 | User interface | Possible Bug | 3.70 release | Very Low | Very Low | Tooltip for render speed status bar has wrong unit | Tracked on GitHub | |
|
Task Description
Tooltip popup for render speed always displays as “Pixels per Second” rather than matching status bar. I’ve noticed it in 3 renders so far. Most of my renders are fast enough not to see any other unit besides PPS, but I should be able to reproduce again if necessary.
|
|
324 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | High | 3.7 mesh2 rendering artifact, regression from 3.6 | Tracked on GitHub | |
|
Task Description
Povray 3.7 has rendering artifact in meshes with polygons that meet at shallow angles. Please see the attached file.
The part of concern is the mesh2, which produces the partly-transparent faces of a shallow pyramid. The file result-3_6.png shows the output of povray-3.6, and the file result-3_7.png shows the output of povray-3.7. In 3.7, you can see a thin light-colored margin all around the base of the pyramid, especially thick under the top cylinder. In 3.6, this artifact is absent. For comparison purposes, I have inserted a “#version 3.6;” directive at the top of the file so that the output images are as close to each other as possible. However, the artifact is still present in 3.7 without this directive.
The attached scene file is only a small part of a much larger scene, where this artifact shows up in numerous very obvious places, where it doesn’t in 3.6. I have hunted in the documentation and online for ways to solve this problem, but haven’t found anything. Because of this, I am forced to stay with 3.6 for production use, which is quite unfortunate since I’d like to take advantage of the new features of 3.7.
|
|
326 | Other | Definite Bug | 3.70 release | Very Low | Low | restricted setting ignored in 3.7 | Tracked on GitHub | |
|
Task Description
Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.
Fixing this reveals some other issues:
%INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc , not /usr/local/etc
read+write paths are added to the read list only, so writing is impossible
See attached patch.
Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc .
Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.
|
|
327 | Parser/SDL | Feature Request | 3.70 release | Very Low | Low | Support for non-ASCII characters in filename strings | Tracked on GitHub | |
|
Task Description
pov 3.7 Can not identify the Chinese.I give the texture map filename in chinese,it turns out parse error.
|
|
328 | User interface | Definite Bug | 3.70 release | Very Low | Medium | Ascii char '=' in filenames causes command line parsing... | Tracked on GitHub | |
|
Task Description
The following command fails with parsing error: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.pov +W1000 +H1000
The following command succeeds: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.pov +W1000 +H1000
Any option that gets a filename as parameter will fail if it contains ‘=’.
It is a regression, as it worked fine with 3.6.
|
|
333 | User interface | Feature Request | 3.70 release | Very Low | Low | Make text in "about" alt+b dialog selectable with the m... | Tracked on GitHub | |
|
Task Description
When you press alt+b or access the “about” dialog in the Help menu it displays some text including software version number and list of contributors.
It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.
|
|
334 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | HLS colors | Tracked on GitHub | |
|
Task Description
It would be nice to be able to specify colors in HLS as well as RGB.
Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.
|
|
335 | Parser/SDL | Possible Bug | 3.70 release | Very Low | Low | macro works in variable but not in array | Tracked on GitHub | |
|
Task Description
This doesn’t work:
#declare pavement_object = array[2] {
object {trash_can_macro() scale 3/4 translate -x * 1/2},
object {potted_plant_macro(_CT_rand2) scale 3/4 scale 3/2 translate -x * 1/2}
}
This does work:
#declare trash_can_object = object {trash_can_macro()}; #declare potted_plant_object = object {potted_plant_macro(_CT_rand2)}; #declare pavement_object = array[2] {
object {trash_can_object scale 3/4 translate -x * 1/2},
object {potted_plant_object scale 3/4 scale 3/2 translate -x * 1/2}
}
Logically, I cannot see a reason for this to be so.
|
|
145 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Stack trace report on error | Tracked on GitHub | |
|
Task Description
In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.
Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.
Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.
Not sure how much of this is achievable in Povray.
|
|
75 | Geometric Primitives | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Medium | Replace POV_MALLOC with std::vector in shape code | Tracked on GitHub | |
Future release |
Task Description
In the files bezier.cpp, fpmetric.cpp, fractal.cpp, hfield.cpp, isosurf.cpp, lathe.cpp, poly.cpp, polygon.cpp, prism.cpp, sor.cpp, and sphsweep.cpp the use of POV_MALLOC can be replaced by std::vector quite easily because the containing class already is a C++ class. As this is a low hanging fruit for continued code cleanup, it should be done sooner rather than later.
|
|
183 | Texture/Material/Finish | Possible Bug | 3.70 beta 40 | Very Low | Low | cutaway_textures broken with child unions | Tracked on GitHub | |
Future release |
Task Description
When using cutaway_textures in a CSG object that has union children, results are not as expected; instead, surfaces in the union children that have no explicit texture will be rendered with the default texture instead. This is not the case for e.g. difference children.
Example:
#default { texture { pigment { rgb 1 } } }
camera {
right x*image_width/image_height
location <0,1.5,-4>
look_at <0,1,0>
}
light_source { <500,500,-500> color rgb 1 }
#declare U = union {
sphere { <0,-0.1,-1>, 0.3 }
sphere { <0, 0.1,-1>, 0.3 pigment { color red 1 } }
}
intersection {
sphere { <0,0,0>, 1 pigment { color green 1 } }
object { U }
cutaway_textures
rotate y*90
}
When declaring U as an intersection instead, the results are as expected, with the surface of the first sphere in U being rendered with the texture defined in the outer intersection.
|
|
206 | Other | Possible Bug | 3.70 RC3 | Very Low | Low | "Cannot open file" error when text output files specifi... | Tracked on GitHub | |
3.71 release |
Task Description
I created an INI file which specifies the Input_File_Name, Output_File_Name, and also the Render_File and the remaining four text outputs as double-quoted absolute paths on my disk. When I run the render, I get the following output:
Preset INI file is ‘C:\USERS\TPREAL\DOCUMENTS\POV-RAY\V3.7\INI\QUICKRES.INI’, section is ‘[512×384, No AA]’. Preset source file is ‘D:\Ruby\POV-Rb\ini\20110521_004037_Noix.ini’. Rendering with 2 threads. - Cannot open file. Render failed - CPU time used: kernel 0.06 seconds, user 0.02 seconds, total 0.08 seconds. Elapsed time 0.52 seconds.
And the render does not start. The five text output files are not even created, and where the output image should be, there is a file with extension pov-state. The render works as it should only when I remove all five lines defining the five text output files. The paths I specify for the files are correct (paths exist and files do not, no white-spaces or anything), read/write restrictions are disabled in POV-Ray. This used to work in 3.6 and does not work now in 3.7 RC3. The error happens no matter if I run the render using GUI or command line.
(Also please note that the error message is really not useful here, it does not say which file it failed to open, and not even if it was an attempt to open for read or for write.)
I’d be really glad if you could correct this as it’s a critical functionality for me. I’m generating the POV-Ray code automatically and I need to parse the text output automatically to return the status to the generator.
|
|
275 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | circular area lights exhibit anisotropy | Tracked on GitHub | |
Future release |
Task Description
circular area lights exhibit some anisotropy, being brighter along the diagonals than on average, as can be demonstrated with the following scene:
//+w800 +h800
#version 3.7;
global_settings{assumed_gamma 1}
plane{-z,-10 pigment{rgb 1} finish{ambient 0 brilliance 0}}
disc{0,z,10000,0.5}
camera{orthographic location z look_at 10*z up y*12 right x*12}
light_source{-10*z rgb 10 area_light 10*x 10*y 257 257 adaptive 4 circular}
|
|
287 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | area_illumination shadow calculation | Tracked on GitHub | |
Future release |
Task Description
not sure if this is something needing further work or an intended effect.
Shadows from and area light with area_illumination on seem to follow the same shadow calculation as a standard area light by giving more weight to lights near the center of the array. I would assume the shadows would be calculated similarly to individual lights in the same pattern as the array by evenly distributing the amount of shadow equally for each light. But this is not what I see.
The code sample below when rendered with scene 1 will show shadows grouped near the center from the area light with area_illumination. If scene 1 is commented out and scene 2 is uncommented then rendered, you will see evenly distributed shadows from individual lights. Area lighting with area_illumination I would assume should give a result identical to scene 2. If scene 1 is rendered with area_illumination off, the shadow calculation is exactly the same as with area_illumination on.
example images rendered on win32 XP
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb .7 } }
torus { 1.5,.1 rotate 90*x translate 4*z pigment { rgb .2 } }
plane { -z,-7 pigment { rgb .7 } }
/*
// scene 1
light_source{
y
1
area_light 3*x, z, 7, 1
area_illumination on
}
union {
sphere { 0,.05 }
sphere { .5*x,.05 }
sphere { x,.05 }
sphere { 1.5*x,.05 }
sphere { -.5*x,.05 }
sphere { -x,.05 }
sphere { -1.5*x,.05 }
translate y
hollow pigment { rgbt 1 } interior { media { emission 10 } }
}
// end scene 1
*/
// scene 2
#declare Light = light_source {
0
1/7
looks_like { sphere { 0,.05 hollow pigment { rgbt 1 } interior { media { emission 10 } } } }
}
union {
object { Light }
object { Light translate .5*x }
object { Light translate x }
object { Light translate 1.5*x }
object { Light translate -.5*x }
object { Light translate -x }
object { Light translate -1.5*x }
translate y
}
// end scene 2
|
|
301 | Other | Definite Bug | 3.70 RC7 | Very Low | Low | Fallback to default image size causes wrong values to b... | Tracked on GitHub | |
|
Task Description
When resolution is not specified (neither via POVRAY.INI nor via QUICKRES.INI nor via command line or custom .ini file), random values are displayed for image resolution in the Image Output Options message output. (The actual render will be performed at the default size of 160×120 pixels though.)
|
|
4 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | Integrate Subsurface Scattering with standard lighting ... | Tracked on GitHub | |
Future release |
Task Description
Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.
|
|
196 | Subsurface Scattering | Definite Bug | 3.70 RC3 | Very Low | Low | More SSLT Caveats | Tracked on GitHub | |
Future release |
Task Description
when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.
|
|
321 | Other | Definite Bug | 3.70 release | Very Low | Low | bounding threshold inconsistency | Tracked on GitHub | |
|
Task Description
User reported documentation inconsistency. Investigation led to the discovery of a bug in the setting of the current default value.
~source/frontend/renderfrontend.cpp reports the value “3” while ~source/backend/scene/scene.cpp sets a default value of “1”
Before for addressing this issue, are there any thoughts as to what the default value should be?
|
|
6 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Integrate Subsurface Scattering with Photons | Tracked on GitHub | |
Future release |
Task Description
Subsurface scattering must be made photon-aware.
|
|
8 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Improve Radiosity "Cross-Talk" Rejection in Corners | Tracked on GitHub | |
Future release |
Task Description
Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.
It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.
|
|
58 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | allow SDL code to detect optional features | Tracked on GitHub | |
|
Task Description
Some features are optional in custom builds of POV-Ray (I’m thinking about OpenEXR in particular); it would be nice to have a syntax for an SDL script to check for support of such features, so it may take some fallback action if the feature is not supported.
|
|
85 | Other | Feature Request | Not applicable | Defer | Low | Aspect ratio issues | Tracked on GitHub | |
Future release |
Task Description
Background
When rendering an image, there are actually three aspect ratios involved:
1) The aspect ratio of the camera, set with the up and right vectors.
2) The aspect ratio of the rendered image, set with the +W and +H parameters.
3) The aspect ratio of the pixels in the intended target medium. While this is very often 1:1, it’s definitely not always so (anamorphic images are common in some media, such as DVDs).
The aspect ratio of the camera does not (and arguably should not, although some people might disagree) define the aspect ratio of the image resolution, but the aspect ratio of the image as shown on the final medium. In other words, it defines how the image should be displayed, not what the resolution of the image should be.
This of course means that the aspect ratio of the target medium pixels has to be taken into account when specifying the image resolution. If the target medium pixels are not 1:1 (eg. when rendering for a medium with non-square pixels, or when rendering an anamorphic image eg. for a DVD), the proper resolution has to be specified so that the aspect ratio of the displayed image remains the same as the one specified in the camera block.
This isn’t generally a problem. It usually goes like “my screen is physically 4:3, so I design my scene for that aspect ratio, but the resolution of my screen is mxn which is not 4:3, but that doesn’t matter; I just render with +Wm +Hn and I get a correct image for my screen”.
However, problems start when someone renders an image using an image aspect ratio / pixel aspect ratio combination which does not match the camera aspect ratio. By far the most common situation is rendering a scene with a 4:3 camera for a screen with square pixels but with a non-4:3 resolution (most typically 16:9 or 16:10 nowadays). The image will be horizontally stretched.
In a few cases the effect is the reverse: The scene (and thus the camera) has been designed for some less-typical aspect ratio, eg. a cinematic 2.4:1 aspect ratio, but then someone renders the image with a 4:3 resolution. The resulting image will be horizontally squeezed.
In a few cases this is actually the correct and desired behavior, ie. when you are really rendering the image in an anamorphic format (eg. for a DVD). However, often it’s an inadverted mistake.
Some people argue that this default behavior should be changed. However, there are also good arguments why it should not be changed. Some argue that POV-Ray should have more features (at the SDL level, at the command-line level or both) to control this behavior.
There are several possible situations, which is why this issue is so complicated. These situations may include:
- The scene author doesn’t really care what aspect ratio is used to render the image, even if it means that additional parts of the scenery become visible or parts are cropped away when using a different aspect ratio than what he used.
In this case the choice of camera aspect ratio should be up to the person who renders the image, and thus selectable on the command-line. However, he should have an easy choice of how changing the aspect ratio affects the image: Should it extend the viewing range, or should it crop part of it, compared to the original?
And this, of course, while still making it possible to render for an anamorphic format.
- The author wants to support different aspect ratios, but he wants to control precisely how it affects the composition of the image. Maybe he never wants anything cropped away within certain limits, but instead the image should always be extended in whichever direction is necessary due to the aspect ratio. Or maybe he wants to allow cropping the image, but only up to a certain point. Or whatever.
In this case the choice of camera aspect ratio should be up to the author, and thus selectable in the scene file, while still allowing some changes from the command-line.
- The author designed his scene for a precise aspect ratio and nothing else, and doesn’t want the image to be rendered in any other aspect ratio. Maybe he used some very peculiar aspect ratio (eg. something like 1:2, ie. twice as tall as wide) for artistic composition reasons, and wants the image rendered with that aspect ratio, period.
Perhaps the author should be able to completely forbid the change of camera aspect ratio in the command-line.
Of course anamorphic rendering should still be supported for targets with a different pixel aspect ratio.
Possible solution
This solution does not necessarily address all the problems described above perfectly, but could be a good starting point for more ideas:
Add a way to specify in the camera block minimum and maximum limits for the horizontal and vertical viewing angles (and if any of them is unspecified, it’s unlimited). Of course for this to be useful in any way, there should also be a way to change the camera and pixel aspect ratios from the command line.
The idea with this is that the author of the scene can use these angle limits to define a rectangular “protected zone” at the center of the view, using the minimum angle limits. In other words, no matter how the camera aspect ratio is modified, the horizontal and/or vertical viewing angles will never get smaller than these minimum angles. This ensures that the image will never be cropped beyond a certain limit, only extended either horizontally or vertically to ensure that the “protected zone” always remains fully visible regardless of what aspect ratio is used.
The maximum angles can be used for the reverse: They ensure that no scenery beyond a certain point will ever become visible, no matter what aspect ratio is used. This can be used to make sure that unmodelled parts of the scene never come into view. Thus the image will always be cropped to ensure this, depending on the aspect ratio.
I’m not completely sure what should be done if both minimum and maximum angles are specified, and the user specifies an aspect ratio which would break these limits. An error message could be a possibility. At least it would be a way for the author to make sure his scene is never rendered using an aspect ratio he doesn’t want. He can use these angle limits to give some leeway how much the aspect ratio can change, to an extent, or he could even force a specific aspect ratio and nothing else (by specifying that both the minimum and maximum angles are the same).
So in short:
- Add a “minimum/maximum horizontal/vertical angles” feature to the camera block. These can be used to define a “protected zone” in the image which must not be breached by command-line options.
- Add a command-line syntax to change the camera aspect ratio (which automatically obeys the “protected zone” settings). Could perhaps give an error message if the command-line options break the limits in the scene camera.
- Add a command-line syntax to specify a pixel aspect ratio other than 1:1. This can be used to render anamorphic versions of the image on purpose (iow. not by mistake).
This can probably be made backwards-compatible in that if none of these new features are used, the behavior could be the same as currently (or at least similar).
|
|
86 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Add support for more RNG types | Tracked on GitHub | |
Future release |
Task Description
The current 32-bit linear congruential generator used as RNG in POV-Ray is sometimes quite limited for some purposes and in a few cases its poor quality shows up (as has been demonstrated more than once in the newsgroup). Thus it would be nice if POV-Ray offered additional, higher-quality random number generators, besides the current one (which should probably remain for backwards compatibility). These RNGs could include algorithms like the Mersenne Twister and the ISAAC RNG, both of which have very decent quality and have an enormous periods (while at the same time being very fast).
After a long discussion, the following syntax for specifying the RNG type and seed (which may be larger than 32 bits) has been suggested:
seed(<value>) | seed(<type>, <value> [, <values>])
For example:
#declare Seed1 = seed(123); // Use the current RNG, with seed 123
#declare Seed2 = seed(1, 123); // Identical to the previous one
#declare Seed3 = seed(2, 456, 789, 123); // Use RNG algorithm #2,
// with a large seed (96 bits specified here)
A C++ implementation of the ISAAC RNG can be found at http://warp.povusers.org/IsaacRand.zip
|
|
87 | Geometric Primitives | Feature Request | Not applicable | Defer | Very Low | Add new feature: Reference object | Tracked on GitHub | |
Future release |
Task Description
When you instantiate an object several times, eg:
object { MyObj translate -x*10 }
object { MyObj translate x*10 }
POV-Ray will copy that object in memory, at least for most types of objects. Not for all of them, though. Most famously if MyObj is a mesh, it won’t be copied, but only a reference to the original will be used, thus saving memory. (There are a few other primitives which also don’t cause a copy, such as bicubic_patch and blob, but those are naturally not so popular as mesh, so it’s a less known fact.)
AFAIK the reason why referencing (rather than copying) is not used for all types of objects is rather complicated, and mostly related to how transformations are applied to these objects. For example if the object being instantiated is a union, the translates above will be (AFAIK) applied to the individual members of the union rather than to the union object itself.
Copying, however, can be quite detrimental in some situations. For example if you have a huge union, and you want to instantiate it many times, the memory usage will be that many times larger (compared to just one instance). This is sometimes something which the user would not want, even if it made the rendering slightly slower as a consequence. (In other words, better to be able to render the scene in the first place, rather than running out of memory.)
Redesigning POV-Ray so that all objects would be referenced rather than copied would probably be a huge job, and in some cases a questionable one. There probably are situations where the current method really produces faster rendering times, so redesigning POV-Ray so that it would always reference instead of copy, could make some scenes render slower.
So this got me thinking about an alternative approach: How hard would it be to create a special object which sole purpose is to act as a reference to another object, without copying it? This special reference object would act as any regular object, would have its own transformation matrix and all that data related to objects, but its sole purpose is to simply be a “wrapper” which references an existing object. It could be, for example, like this:
object_ref { MyObj translate -x*10 }
object_ref { MyObj translate x*10 }
The end result would be exactly identical as earlier, but the difference is that now MyObj behaves in the same way as a mesh (in the sense that it’s not instantiated twice, but only once, even though it appears twice in the scene), regardless of what MyObj is.
In some cases this might render slightly slower than the first version (because POV-Ray has to apply the transformations of the object_ref first, after which it applies whatever transformations are inside MyObj), but that’s not the point here. The point is to save memory if MyObj is large.
An object_ref would behave like any other object, so you could do things like:
#declare MyObjRef = object_ref { MyObj };
object { MyObjRef translate -x*10 }
object { MyObjRef translate x*10 }
(The only thing being instantiated (and copied) here is the “MyObjRef” object, not the object it’s referring to, so that actual object is still stored in memory only once.)
In some situations it might even be so that referenced objects actually render faster than if the objects were copied because references increase data locality, lessening cache misses.
I believe this could be a rather useful feature and should be seriously considered, unless there are some major obstacles in implementing it.
|
|
91 | Texture/Material/Finish | Feature Request | 3.70 beta 36 | Defer | Low | Slope pattern applied to object is not transformed afte... | Tracked on GitHub | |
Future release |
Task Description
There is an big issue with the slope pattern: when the object it is applied to is instanced (again) with a transformation (in particular a rotation, as a translation would not impact.. but a shear might), the colours of the surfaces are changed.
object { p translate -5*x }
object { p rotate 220*y+20*x translate 3*x }
Nobody would expect the object to be different in appearance. If slope {} is replaced with wood, all is fine. (as for others textures, i guess)
IMHO, the slope vector need to be adjusted for the later transformation(s) (so as to compensate the issue of using the Perturbed Normal vector).
This should not impact the AOI/FACING (experimental) patterns, as AOI definition is pretty clear about duplicating & transform if you think about it a bit, as well as FACING: for these two, it is expected to either use the ray(current point of view) or a fixed 3D point as reference. At the limit, discussion about moving the 3D point of FACING might also be opened to interpretation.
AOI/FACING are in task #19
|
|
99 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Very Low | Refactor engine (front- & back-end) code for Unicode su... | Tracked on GitHub | |
Future release |
Task Description
Front- & Back-end code should be refactored for full Unicode support in scene files and strings.
|
|
129 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | Hash arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
|
|
133 | Geometric Primitives | Feature Request | 3.70 beta 37a | Defer | Very Low | Subdivision support | Tracked on GitHub | |
Future release |
Task Description
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.
|
|
237 | User interface | Definite Bug | 3.70 RC3 | Defer | Very Low | Glitch in displaying rendered pixels and percentage | Tracked on GitHub | |
|
Task Description
When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal are first displayed like this: Rendered 126202 of 360000 pixels (35%) Then on the second stage the output text becomes shorter and you see Rendered 25344 of 360000 pixels (7%)%) The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.
I’m running Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu) compiled for the Arch Linux package.
|
|
242 | Other | Feature Request | All | Defer | Very Low | Algorithm to fix the so-called shadow line artifact | Tracked on GitHub | |
|
Task Description
The so-called shadow line artifact (http://wiki.povray.org/content/Knowledgebase:The_Shadow_Line_Artifact) which affects objects with a ‘normal’ statement as well as smooth meshes and heightfields can be really annoying sometimes. Currently the only way to remove it is to make the object shadowless, which isn’t a good solution except in very special cases.
This algorithm could remove the artifact: If the actual normal vector of the object points away from the light source (its dot-product with the light vector is negative) but the perturbed normal points towards it (dot-product positive), then ignore the first shadow-test intersection with the object itself.
There are alternative ways of implementing an equivalent functionality:
- Don’t check the condition (if it’s too difficult to check due to how the code is designed) but always ignore the first intersection with the objects itself. This will work properly with closed surfaces but not with open ones, so it might need to be a feature for the user to turn on with a keyword (similar to eg. ‘double_illuminate’).
- Alternatively, don’t ignore the first intersection, but instead ignore the “opposite side” of the object’s surface (again, possibly only if a keyword has been specified). In other words, if we are rendering the outer side of the object, ignore its inner side when shadow-testing, and vice-versa.
- Perhaps simply add a feature to make surfaces one-sided (similarly to how they can be made so in OpenGL and similar scanline rendering systems). In other words, the inner side of a surface is completely ignored everywhere, making the object virtually invisible from the inside. The advantage of this feature would be that it can have uses other than simply removing the shadow line artifact.
|
|
243 | Geometric Primitives | Unimp. Feature/TODO | All | Defer | Low | Sphere sweep behaves wrong when scaled | Tracked on GitHub | |
Future release |
Task Description
The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.
The effect is present for all three types of splines.
I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.
I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.
|
|
245 | Other | Feature Request | All | Defer | Low | POVMS message queue can fill up with GB of data for ver... | Tracked on GitHub | |
Future release |
Task Description
With very fast renders and very large output files, the message queue can fill up because the producers are not limited by IO, while the consumer performance is limited by disk IO. Consequently, the message queue can fill up to exhaust all available memory. The solution is to build in some better control of pending output data in the message queue on the producer side. This will also pave the way for message communication over slow links (i.e. a network).
|
|
264 | Photons | Unimp. Feature/TODO | 3.70 RC6 | Defer | Low | Improve precision of photon direction information | Tracked on GitHub | |
|
Task Description
In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:
latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)
For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using
LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;
dirCode = LatBase[latCode] + lngCode;
For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.
|
|
272 | Other | Feature Request | 3.70 RC6 | Defer | Very Low | Minor change, significant speedup in cubic polynomial s... | Tracked on GitHub | |
3.71 release |
Task Description
While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.
In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).
solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.
I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).
These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].
This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.
The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).
|
|
281 | Geometric Primitives | Feature Request | 3.70 RC7 | Defer | Low | Bug in rendering of Bézier patches | Tracked on GitHub | |
Future release |
Task Description
In version 3.7.0.RC7.msvc10.win64, there is a bug in rendering Bézier patches in which four points (along one edge) are all the same point.
The rendering can be seen here: http://i.imgur.com/eq2UIXR.png [Edit: See attachment for the rendering]
As you can see, there is a visible unwanted artifact in the corner of each patch. The two patches shown are essentially the same, except with the 4×4 matrix of vertices transposed (just to demonstrate that simply transposing it didn’t fix it).
Expected rendering is a smooth surface without the artifact.
Below is the code used to render the above example.
#version 3.7;
global_settings { assumed_gamma 1.0 }
camera {
location <45, 31, -10>
look_at <40, 21, 200>
right x*image_width/image_height
}
light_source {
<660, 300, -525>
color rgb 1
}
Example 1: First point in each row is the same point bicubic_patch { type 1 flatness 0.001 u_steps 4 v_steps 4 <32.2168, -23.78125, 0>, <34.4968, -23.78125, 0>, <35.2168, -23.78125, -0.72>, <35.2168, -23.78125, -3>, <32.2168, -23.78125, 0>, <34.4968, -22.10256, 0>, <35.2168, -21.57244, -0.72>, <35.2168, -21.57244, -3>, <32.2168, -23.78125, 0>, <33.9709, -21.55577, 0>, <34.52483, -20.85299, -0.72>, <34.52483, -20.85299, -3>, <32.2168, -23.78125, 0>, <32.30556, -21.50298, 0>, <32.33359, -20.78352, -0.72>, <32.33359, -20.78352, -3> rotate 180*x
scale 1.4 translate ←5, 0, 0> pigment { color <1, 0, 0> } }
Example 2: First row is all the same point bicubic_patch {
type 1 flatness 0.001
u_steps 4 v_steps 4
<32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>,
<34.4968, -23.78125, 0>, <34.4968, -22.10256, 0>, <33.9709, -21.55577, 0>, <32.30556, -21.50298, 0>,
<35.2168, -23.78125, -0.72>, <35.2168, -21.57244, -0.72>, <34.52483, -20.85299, -0.72>, <32.33359, -20.78352, -0.72>,
<35.2168, -23.78125, -3>, <35.2168, -21.57244, -3>, <34.52483, -20.85299, -3>, <32.33359, -20.78352, -3>
rotate 180*x
scale 1.4
pigment { color <1, 1, 0> }
}
|
|
282 | Image format | Feature Request | Not applicable | Defer | Low | Unrendered region should be transparent, not black | Tracked on GitHub | |
Future release |
Task Description
When rendering only a region of a file, using the command-line options +sc/+sr/+ec/+er, the area of the image that is excluded comes out as black in the final PNG.
Expected behaviour is for it to be transparent.
|
|
296 | Geometric Primitives | Definite Bug | 3.70 RC7 | Defer | Medium | max gradient computation is not thread safe (isosurface... | Tracked on GitHub | |
3.71 release |
Task Description
It appears as a side effect of investigation of #294: the code in isosurf.cpp, inside bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)
if(gradient < temp)
gradient = temp;
is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)
It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)
|
|
300 | Other | Feature Request | 3.70 RC7 | Defer | Very Low | Reference Documentation Support | Tracked on GitHub | |
|
Task Description
As emerged as an idea during the discussion of FS#299, an SDL / POV-Ray editor feature would be useful that allows API documentation via formal comments, e.g. in include files:
/**
* Creates a car object.
* @param a
* description of param a
* ...
*/
#macro car(a,b,c)
...
#end
In addition to the ability of (auto-)generating a documentation file from such comments, an editor window feature would be convenient that allows popup display of a macro’s (object’s / parameter’s / ...) documentation section.
|