|
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
|
|
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).
|
|
84 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | A for-loop construct | Closed | |
3.70 beta 37 |
Task Description
Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.
The only remaining question would be the syntax.
IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:
#for(<identifier name>, <initial value>, <final value> [, <step>])
<loop body>
#end
Example:
#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
#debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
#debug concat(str(Counter, 0, 0), "\n")
#end
I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).
Of course this raises a couple of questions:
1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:
2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:
// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
#debug concat(str(Counter, 0, 0), "\n")
#if(Counter = 3) #local Counter = 8; #end
#end
Alternatively the counter variable could be read-only.
Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).
|
|
83 | Source code | Possible Bug | 3.70 beta 36 | Very Low | Very Low | redundant code in pvengine.cpp | Closed | |
3.70 beta 37 |
Task Description
In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:
3997 case KEYWORD_LOOKUP_MESSAGE :
3998 hh_aklink.pszKeywords = (LPCSTR) lParam ;
3999 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000 hh_aklink.pszKeywords = "" ;
4001 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002 hh_aklink.pszKeywords = "" ;
4003 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004 hh_aklink.pszKeywords = "" ;
4005 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006 hh_aklink.pszKeywords = "" ;
4007 HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008 return (true) ;
This duplication appears pretty much useless to me - or am I missing something?
|
|
82 | Other | Possible Bug | 3.70 beta 35a | Very Low | Low | correction to Shapes.pov | Closed | |
|
Task Description
When I try to re-render the insert menu bitmaps,on the Windows version 3.7b36 there is an error with the Shapes.pov file. line 474: Parse Error: Unexpected additional ‘.’ in floating-point number
line 474 is:
<2.6, 0>, <3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>
The second vector has two decimal points Change to <3.6,.9>
|
|
81 | Geometric Primitives | Definite Bug | 3.62 | Very Low | Medium | sphere_sweep generating artifacts | Tracked on GitHub | |
|
Task Description
I’m running POV-Ray for (64 bit) Windows v3.62 on (64 bit) Windows Vista
This pov file:
#include "colors.inc"
#include "metals.inc"
light_source { <6, 9, -21> color White }
camera { location <0, 0, -3> look_at <0, 0, 0> }
sphere_sweep {
cubic_spline
6
<-2.0, 0, 0> 0.05
<0.000,0,0> 0.2
<0.025,0,0> 0.2
<0.050,0,0> 0.2
<0.075,0,0> 0.2
<3.0,0,0> 0.2
pigment { color White }
}
Produces two strange artifacts: A disk at the center of the sweep, and a faint “halo” or veil which shows as 4 faint hyperbolas centered around the origin.
I have tried tweaking tolerance (for no other reason than I saw that someone else was tweaking it to solve a problem) but this does not seem to change things.
For a look at MY result when I run this, view this image:
Alain reports the same behavior in the latest version: “It’s still there with the latest version: 3.7 beta 35a.” This MAY move the status to “confirmed”, but I can’t do that
Someone else says that changing the scale (!) “solves” the problem by moving the disk and the halo offscreen, but that sounds like a bad idea to me.
-Jeff Evarts, first-time POVRay bug reporter
|
|
80 | Parser/SDL | Possible Bug | 3.70 beta 35a | Very Low | Medium | Bad behavior for missing image file | Closed | |
|
Task Description
The following SDL code
sphere {0, 1 pigment {image_map {png "missing.png"}}
yields “render failed” in 3.7b25 and the position of the error is not highlighted in source code, giving no clue what went wrong. In 3.6 this yields “Parse Error: Cannot open PNG file”.
|
|
79 | Source code | Feature Request | 3.70 beta 35a | Very Low | Low | Full-Featured Test-Scene to check the correctness of po... | Tracked on GitHub | |
Future release |
Task Description
Hi,
it would be nice if there exists a test scene (not a benchmark) which has a high coverage of povray source and can be used as correctness validation of povray. It schould be produce an image which can be compared to a golden reference image.
It may be also possible to create a regression test suite which does automatic comparision of the render results.
|
|
78 | Photons | Possible Bug | 3.70 beta 35a | Very Low | High | Wrong rendering of BeamTest-Scene in 3.7.beta.35a | Closed | |
3.70 beta 37 |
Task Description
Hi,
following scene will not be rendered correctly in 3.7.beta.35a:
http://lib.povray.org/collection/beamtest/cousin%20ricky%201.1/beamtest.html
maybe it is a configuration problem or it is a real bug.
|
|
77 | Geometric Primitives | Definite Bug | 3.70 beta 35 | Very Low | High | Cone is not on good place when first base point is lowe ... | Closed | |
|
Task Description
Cone is not on good place when first base point is lower then end cap point. Example:
cone { <0, 0, 0>, 2, <0, 1, 0>, 1 } - good
cone { <0, 0, 0>, 1, <0, 1, 0>, 2 } - bad
This is on 3.7 beta 35 version.
|
|
76 | Other | Feature Request | 3.6 | Very Low | Medium | Povray returns incorrect exit code when aborting render | Closed | |
3.70 release |
Task Description
If you abort a render with ^C, Povray exits with a ‘success’ error code.
To test:
povray scene.ini
(^C to abort it)
echo $?
Right now 0 is returned (’success’). A non-zero value should be returned (’failure’).
This is particularly important for scripting, where command lines like:
povray scene.ini && halt
...can be used. I only want the halt to be executed if the scene renders successfully. If I change my mind and ^C it, I don’t want the machine to shut down!
|
|
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.
|
|
74 | Texture/Material/Finish | Possible Bug | All | Very Low | Medium | image_maps within pigment_maps are not rendered correct ... | Closed | |
|
Task Description
Hello,
when I use an image_map within a pigment_map (for example only a half of a box gets the image_map), the image_map is not rendered correctly.
For example when I have this box (scene and images are attached)
box {
0, 1
pigment {
gradient z
pigment_map {
[0.4 image_map { png "test.png" } ]
[0.4 color Cyan ]
}
}
}
So on the front you should see the image of test.png (in the attached scene it’s just red). But on some pixels of the front you see the cyan color of the distant half of the cube.
Rendering the scene mutliple times produces the same result.
Rendering the scene at 200×150 is sufficiant.
povray +W200 +H150 scene.pov
I tested it with 3.6.1 and 3.7.0 beta 32 on Linux
|
|
73 | Parser/SDL | Definite Bug | 3.70 beta 34 | Very Low | Medium | Blend map cannot get 256 entries | Closed | |
3.70 beta 35 |
Task Description
Reported by cshake + pov @ gmail . com in p.beta-test, 14th december 2009
I wrote a simple script to convert fractint color maps to povray color_maps so I could use ApoMap to make nice fractal colors for pov, but I ran into “Parse Error: Blend_Map too long.” The map has entries from 0/255 up to 255/255 (inclusive). I looked up the documentation which says that color_maps can have from 2 to 256 entries, and this is exactly 256 entries. I’m posting this in beta-test because I assume that the documentation is correct for v3.6, and that a previous version can handle 256 entries.
|
|
72 | Platform-specific | Possible Bug | 3.70 beta 34 | Very Low | Low | Editor not saving preferences | Closed | |
|
Task Description
Windows 7, Home Premium 64bit In Options/Editor Window/Editor Preferences/Language Tabs saving a tab size of 4 does not work - on restart it reverts to the default of 8
In Options/Editor Window/Editor Preferences/Misc saving a Line numbering style of Decimal and a Start number of 1, does not work, on restart the defaults are restored.
|
|
71 | User interface | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Low | raise warning when command line option has no effect | Tracked on GitHub | |
|
Task Description
Warnings should be raised when a command line option has no effect, for example...
pvengine +am
is legal, but without the number after it, it has no effect.
pvengine +am7
should be an error, and also raises no warnings.
|
|
70 | Photons | Unimp. Feature/TODO | 3.70 beta 34 | Low | High | load/save photons should be controlled via command line | Tracked on GitHub | |
|
Task Description
Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.
|
|
69 | Other | Compatibility Issue | Not applicable | Very Low | Low | #version fails to raise error | Closed | |
|
Task Description
Scenes starting with the incorrect syntax
version 3.7;
do not raise an error, instead they render a black screen with an empty scene warning. #version should fail with an error when the # is missing.
|
|
68 | Setup/Install | Possible Bug | 3.61 | Very Low | Low | Unix configure script does not accept newer libpng vers ... | Closed | |
|
Task Description
The configure script for unix uses a dumb string compare to test whether libpng version is 1.2.5 or higher, leading it to reject (for instance) libpng 1.2.27 and unnecessarily compile and statically link the older libpng version it comes with.
|
|
67 | Texture/Material/Finish | Definite Bug | All | Very Low | Low | alpha channel in image map is ignored for shadows | Closed | |
3.70 beta 37 |
Task Description
In the following scene, the mesh object will always cast a fully-opaque shadow, even if the image has an alpha channel:
camera {
location <0.5, 1.0, -1.0>
look_at <0.5, 0.0, 0.5>
}
light_source { <0, 30, 0> color rgb 1 }
mesh {
triangle { <0,0,0>, <1,0,0>, <1,0,1> uv_vectors <0,0>, <1,0>, <1,1> }
triangle { <0,0,0>, <1,0,1>, <0,0,1> uv_vectors <0,0>, <1,1>, <0,1> }
texture { pigment { uv_mapping image_map {png "FOOBAR.png"} } }
}
plane { y, -0.1 pigment { color rgb 1 } }
The following modification to the texture will give the expected results:
texture { uv_mapping pigment { image_map {png "FOOBAR.png"} } }
The problem can be observed with both POV-Ray 3.7 (tested with beta.34), as well as 3.6 (tested with 3.6.2).
|
|
66 | Texture/Material/Finish | Feature Request | 3.62 | Defer | Low | checker and cells pattern are slightly off-center | Closed | |
|
Task Description
In POV-Ray 3.6 (including 3.62), checker and cells patterns are off by 0.001 (1e-3) units, as can be demonstrated with this scene:
camera {
location <0.0, 0.0, -5.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
box { <-1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 0.2 translate <-0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 0.2 translate < 0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate < 0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { <-1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate <-0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
The same can be demonstrated for the cells pattern.
POV-Ray 3.7 beta 34 is “clean”.
|
|
65 | Parser/SDL | Feature Request | 3.70 beta 34 | Very Low | Low | Add support for vectors with functions | Tracked on GitHub | |
Future release |
Task Description
Being able to have functions operate on vectors would be pretty nice to have.
|
|
64 | Image format | Feature Request | Not applicable | Very Low | Low | Add "POV-Ray" metatags to images | Closed | |
3.70 beta 41 |
Task Description
Add metatags to output images identifying the file as having been created using POV-Ray.
|
|
63 | Geometric Primitives | Feature Request | Not applicable | Very Low | Low | Extend native support for 2D primitives | Closed | |
|
Task Description
Improve native support for 2D primitives. Ideally a 1:1 mapping of SVG primitives/shapes. They go a long way to making diagrams look a lot better. Having to create image maps based on externally created bitmaps slows the workflow down a lot!
|
|
62 | Geometric Primitives | Feature Request | Not applicable | Very Low | Low | Set and get font metrics | Closed | |
|
Task Description
Add a way to get and set font metrics.
Attached an image that shows what I’m talking about.
Thanks!!
|
|
61 | Other | Definite Bug | 3.70 beta 34 | Low | Medium | Dispersion does not give proper results | Closed | |
|
Task Description
Source code inspection during examination of issues with the scene published at http://povray.sitewww.ch/?p=177 show the following issues with current (beta.34) implementation of dispersion in POV-Ray 3.7:
While this still allows to use dispersion for artistic effect, it is neither physically realistic, nor does it match 3.6 behavior.
|
|
60 | Geometric Primitives | Definite Bug | 3.70 beta 34 | Very Low | Medium | Artifacts using prism in CSG | Tracked on GitHub | |
Future release |
Task Description
Using prisms in intersecion or difference CSG objects may cause artifacts in POV-Ray 3.6.2 as well as 3.7.0.beta.34, as demonstrated by the following code:
camera {
right -x
up y*image_height/image_width
location <-24,19,12>
look_at <0,0,0>
}
light_source { <100,200,100> color rgb 1 }
plane { y, -2 pigment { color rgb 1 } }
#declare KeyValue = 1.366; // pick any you like
difference {
prism {
linear_sweep -0.5,0.5, 4
<-3,20-17>,
<-3,KeyValue>,
<-6,-3>,
<-0,-5>
}
intersection {
cylinder { <-7,-0.51,1>, <-7, 0.51,1>, 4.0 }
plane { z, KeyValue }
}
pigment { color rgb 0.5 }
}
Apparently the surface of the other object becomes visible when it exactly coincides with a vertex of the prism; probably there is a failure of the inside() test for such values.
|
|
59 | Geometric Primitives | Definite Bug | 3.70 beta 34 | Very Low | High | Cone intersection test broken | Closed | |
3.70 beta 35 |
Task Description
The following scene, showing an almost cylindrical cone floating above a plane, renders fine in POV 3.6.2, but is obviously broken in 3.7.0.beta.34:
camera {
right x
up y*image_height/image_width
location <80,50,40>
look_at <0,0,0>
}
light_source { <500,500,500> color rgb 1 }
cone {
<0,0,30>, 11.303000, <0,0,-30>, 11.302999
texture { pigment { color rgb 1 } }
}
plane { y, -20 texture { pigment { color rgb 0.3 } } }
The error occurs even with the -MB option, indicating that the problem has nothing to do with bounding, but is in the cone intersection testing code.
|
|
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.
|
|
57 | Texture/Material/Finish | Definite Bug | 3.70 beta 34 | Very Low | Medium | Compressed TIFF image_map renders all transparent | Closed | |
|
Task Description
The attached TIFF file was created with IC using compression. When used in an image_map, POV-Ray 3.7.0.beta.34 on Windows XP x64 renders the image all transparent, while POV-Ray 3.6.2 renders the file fine. The same effect can be seen with LZW-compressed TIFF files created with Adobe Photoshop 6.0.
Uncompressed TIFF files created with either IC or Photoshop render fine in both versions of POV-Ray.
Stepping through the code of POV-Ray 3.7.0 shows that the same code path is taken regardless of compression, but the libtiff library returns different alpha channel values, indicating a problem in that library. POV-Ray 3.7 still uses libtiff 3.6.1, whereas the POV-Ray 3.6 branch has been updated to libtiff 3.8.2, which according to the change history includes a few alpha-related changes.
|
|
56 | Texture/Material/Finish | Possible Bug | 3.70 beta 34 | Very Low | Medium | Crackle pattern in some situations can cause runaway me ... | Closed | |
|
Task Description
(This happens as of beta 34)
The following scene will cause POV-Ray to allocate memory until all available memory is used, resulting in an Out of Memory error message:
#declare n1 = normal
{
crackle .5
scale 0.001
accuracy 0.0001
}
#declare n2 = normal
{
bumps 0
}
camera
{
location <0, 0.2, -1>
look_at <0.4, 0.3, 1>
focal_point <0.4, 0.3-.0, 1>
blur_samples 25
confidence .9
variance 0
aperture .05
}
light_source
{
<-10, 10,-5>, rgb 1.5
area_light x*2,y*2,7,7 orient adaptive 2
}
sphere{ <0, 0, 0>, 0.5 pigment {color rgbf <0.85,1,.95,1>}
interior
{
ior 1.5
fade_color rgb <0.0, 0.5, 0.0>
fade_power 2
fade_distance 10.5
dispersion 1.1
dispersion_samples 100
}
normal {
checker normal{n2} normal{n1}
scale 0.1
warp { spherical }
}
translate z*1
}
|
|
55 | Image format | Definite Bug | 3.70 beta 32 | Very Low | Medium | Output_Alpha=on doesn't work as documented | Closed | |
|
Task Description
I have installed POV-Ray 3.7 beta 34 on Windows 7 The setting ‘Output_Alpha=on’ doesn’t work as documented. With this setting the Background appear black and the scene is transparent.
Check with this Code:
camera {
location <3, 3, -3>
direction <0, 0, 2.9>
look_at <0, 0, 0>
right 1.0*x
}
light_source { < 3, 3, -3> color red 1 green 1 blue 1 }
sphere
{
<0,0,0> 0.8
pigment {color rgb<1,1,0>}
finish
{
ambient 0.2
diffuse 0.8
}
}
and with this ini file:
Input_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.pov
Output_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.tga
Output_File_Type=t
Output_Alpha=on
Bits_Per_Color=24
+W121 +H121
+a0.3
+q11
+a
|
|
54 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Low | Multi-textured blobs fail to increment trace level | Closed | |
|
Task Description
Trace level is not handled properly with blobs using per-component reflective or refractive textures, leading to lockups. Stepping through the code, it seems that POV-Ray fails to properly mark the blob object as increasing the trace level.
(Until this bug is fixed, the issue can be worked around in most cases by assigning a reflective texture to the blob as a whole.)
|
|
53 | Geometric Primitives | Definite Bug | 3.70 beta 32 | Very Low | Medium | Blob trace level | Closed | |
|
Task Description
It appears that reflective bounces from blobs are not incrementing the trace level, causing self- reflecting hall of mirror portions to stall renders.
|
|
52 | Parser/SDL | Possible Bug | 3.70 beta 32 | Very Low | Low | inside() function does not accept meshes despite valid ... | Closed | |
|
Task Description
The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.
(see news://news.povray.org:119/4a983716@news.povray.org)
|
|
51 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Critical | POV-Ray crashes hard on missing parenthesis | Closed | |
3.70 beta 35 |
Task Description
The following (bogus) SDL code causes POV-Ray 3.7 beta to crash hard with an access violation:
#include "fubar.inc"
Bar(42)
#macro FooBar() #end
//fubar.inc
#macro Foo(Fnord) #end
#macro Bar(Ignord) Foo(23 #end
|
|
50 | Runtime error | Possible Bug | 3.70 beta 32 | Very Low | Medium | Frequent segfaults with photon scenes | Tracked on GitHub | |
|
Task Description
I observe frequent segfaults with POV-Ray 3.7 betas when rendering scenes using photons:
Segfaults are sporadic but frequent (occurring in roughly 50% of all photon renders).
|
|
49 | Texture/Material/Finish | Possible Bug | 3.70 beta 32 | Very Low | Low | number_of_waves default value not properly initialized | Closed | |
|
Task Description
When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.
For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:
scenes\textures\finishes\arches.pov
scenes\textures\normals\normavg.pov
scenes\textures\finishes\arches.pov (again!)
|
|
48 | Geometric Primitives | Definite Bug | All | Low | High | CSG bounding box computation broken with shearing trans ... | Closed | |
|
Task Description
Bounding box computation for CSG intersection appears to be broken when one member is an arbitrarily transformed plane.
POV-Ray 3.6.2 has the same problem (can’t test for 3.6.1).
// +W640 +H480 +MB1
#include "transforms.inc"
camera {
location <-0.2, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
plane {
y, -1
pigment { color rgb <0.7,0.5,0.3> }
}
intersection {
sphere {
0.0, 1 }
plane { -x, 0 transform { Shear_Trans(x,y+x*0.3,z) } }
texture {
pigment {
radial
frequency 8
color_map {
[0.00 color rgb <1.0,0.4,0.2> ]
[0.33 color rgb <0.2,0.4,1.0> ]
[0.66 color rgb <0.4,1.0,0.2> ]
[1.00 color rgb <1.0,0.4,0.2> ]
}
}
finish{
specular 0.6
}
}
rotate -y*5
}
|
|
47 | Preview | Possible Bug | 3.70 beta 32 | Very Low | Low | Render Preveiw window can become disabled | Tracked on GitHub | |
|
Task Description
If a render is continued with the +c option and the render had completed, the render preview window will disappear and the show/hide render window button will be grayed. Even after the scene is modified and the command line options have been changed, the show/hide button will still be grayed.
Opening or changing to another scene and rendering will not restore the button, nor will rendering with +d. However, if a trace is started using -d, halted, then continued using +d (or allowed to finish completely with -d and a new one is started using +d), then the preview window is restored.
This behavior is different from 3.6.1, which correctly always showed the preview window (since +d is default) unless -d was specified.
|
|
46 | Light source | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | area_illuminate in area lights is not taking fade_dista ... | Closed | |
3.70 RC4 |
Task Description
It seems that the new area_illuminate flag for area lights does not take into account fade_power and fade_distance. The illumination falloff is still being calculated from the center of the light_source.
Here’s some relevant code:
camera{
location<0,10,-10>
look_at 0
}
plane{y,0 pigment{rgb 1}}
light_source{
y*.1,100
area_light x*10, z*1, 8, 8
jitter
area_illumination
fade_power 2 fade_distance 1
}
|
|
45 | Distribution | Possible Bug | 3.70 beta 32 | Very Low | Low | Check & update sample scenes | Closed | |
3.70 release |
Task Description
Some sample scenes are no longer up-to-date, causing warnings, and should be fixed. For instance, the advanced/benchmark scene still includes “Buffer_Output=Off” and “Buffer_Size=0” in its .ini file. This should be checked systematically, and fixed as appropriate.
|
|
44 | Radiosity | Feature Request | All | Very Low | Low | Improve Normals Handling in Radiosity | Tracked on GitHub | |
Future release |
Task Description
Currently, radiosity does not make use of the fact that pertubed normals would theoretically just require a different weighting of already-sampled rays, leading to the following issues:
Honoring normal pertubations in radiosity leads to an increased number of samples, slowing down sample cache lookup.
The increased number of samples is generated from a proportionally higher number of sample rays, slowing down pretrace even further.
Low-amplitude pertubations tend to be smoothed out; “reviving” these is only possible by increasing the general sample density.
Handling of multi-layered textures with different normal pertubations is currently poorly implemented.
As a solution, I propose to store for each radiosity sample not only the resulting illumination for a perfectly unpertubed normal, but from the same set of sample rays also compute the illumination for an additional set of about a dozen standardized pertubed-normal directions, and interpolate among these when computing the radiosity-based illumination for a particular point that has a pertubed normal.
For backwards compatibility, this method of dealing with pertubed normals in radiosity might be activated by a different value for the “normal” statement in the radiosity block, say, “normal 2”.
|
|
43 | Editor | Definite Bug | All | Very Low | Low | Commas in path name | Closed | |
3.70 RC7 |
Task Description
In POV-ray 3.7 beta 33 under Windows XP, the editor’s MRU list incorrectly handles files that have a comma in the pathname. Only the part of the name before the comma appears on the MRU list, but the rest of the name is left off. Consequently, the file cannot be reopened via the MRU list. The file is also not reopened on launch if pov was closed with the file open. This also occurs in 3.6.1, I haven’t tried it under 3.6.2 yet.
Interestingly enough, a quick peek in the registry shows that both 3.6 and 3.7 are saving the entire path name correctly under HKEY_CURRENT_USER\Software\POV-Ray\v3.6\POV-Edit\Recent (or \v3.7\POV-Edit\Recent).
This seems to be limited strictly to the editor’s MRU list. The file can still be opened normally using the open dialog box. Calling POV-ray from the command line and using a file or path name with commas in it works correctly. Included files with commas in the path work correctly, and the Tools→Edit last rendered file/View last rendered file work correctly also.
To duplicate, save a file with a comma in the pathname (either in the directory name or the filename itself). Close the file, then attempt to reopen it using the MRU list in the file menu.
|
|
42 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | command line parameters are not parsed properly on Unix | Tracked on GitHub | |
|
Task Description
POV-Ray does not follow common practice on command-line handling; for instance:
povray +i"My File"
entered on a Unix shell would be passed to POV-Ray as
povray
+iMy File
(each line representing a distinct parameter here), which POV-Ray would further dissect, interpreting it as
povray
+iMy
File
To achieve the desired effect, one would actually have to quote the string twice:
povray +i"'My File'"
which the shell would translate to
povray
+i'My File'
which POV-Ray would interpret as
povray
+iMy File
In both cases, this is obviously not what a Unix user would expect.
The further dissecting of individual command-line parameters may have had its valid roots in the peculiarities of DOS’ command-line handling, but to my knowledge all major contemporary operating systems follow a concept akin to Unix, passing a list of parameters instead of a monolithic command line, and burdening the respective command shells with the task of dissecting command lines into parameters.
Therefore I suggest to disable this anachronistic feature in favor of contemporary standards; a compiler flag might be used to allow for easy re-enabling of the feature, for compiling POV-Ray on exotic targets.
- edit -
It has been pointed out that the described behaviour differs from 3.6, so I’m promoting this to a bug and changing the title.
|
|
41 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | improve command-line parsing error messages | Tracked on GitHub | |
|
Task Description
POV-Ray 3.6, upon encountering problems when parsing command line and/or .ini file options, would quote the offending option in the error message.
POV-Ray 3.7 currently just reports that there is some problem with the command line, without providing any details. I suggest changing this, as the information may be helpful at times.
|
|
40 | Platform-specific | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | Compilation on freebsd | Closed | |
3.70 beta 33 |
Task Description
Reported for freebsd 7.2 (current production version, true for previous version, unknown for 8.0 in beta now)
freebsd does not provide CLOCK_PROCESS_CPUTIME_ID (even if CLOCK... is posix).
As a consequence, compilation of the unix-source is currently not possible for freebsd target.
Might be a simple selection for Change 4356 ? (assuming a relevant test in ./configure) (getrusage() seems available on freebsd, but does it provide the pieces of information needed, I do not know that code good enough to assert that)
|
|
39 | Distribution | Definite Bug | 3.70 beta 32 | Very Low | Medium | "cats" and "life" sample scenes broken | Closed | |
3.70 release |
Task Description
The following files were garbled in changelist #4648 by stripping all line terminators, making the files unusable:
.../scenes/advanced/cats/cattext.inc
.../scenes/animations/life/blink4.inc
.../scenes/animations/life/walker.inc
Line terminators of these files were already problematic in previous versions of the file, having been CR-only.
The following files changed with #4648 should be reviewed closely as well, as they were previously CR-only, too, and at least some of them exhibit some peculiarities regarding line and/or file terminators:
.../scenes/animations/pentmap/pentmap.ini
.../scenes/animations/pentmap/pentmap.pov
.../scenes/animations/slinky/slnk.ini
.../scenes/incdemo/metals/metals.doc
.../scenes/incdemo/stones/stones.doc
.../scenes/incdemo/woods/morewood.doc
.../scenes/incdemo/woods/woods.doc
.../scenes/textures/pigments/skies/skies.doc
|
|
38 | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | POVDocGen extension | Closed | |
3.70 release |
Task Description
Develop MediWiki extension to extract documentation sets from the POV-Wiki.
|
|
37 | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Find Documentation Editors | Closed | |
3.70 release |
Task Description
Recruit version 3.7 documentation editors from the users community.
|