|
2 | Platform-specific | Compatibility Issue | 3.61c | Low | High | POV-Ray 3.6x does not work properly in Vista | Closed | |
3.62 |
Task Description
There are a number of problems with the Windows version of POV-Ray under Windows Vista. To resolve these, the setup program needs to be re-written and the location of internal files changed.
|
|
22 | Parser/SDL | Definite Bug | 3.6 | Very Low | Medium | Known 3.6-only bug related to Splines and Token countin ... | Closed | |
3.65 |
Task Description
3.6x only bug with easy/known fix. Error message: “Identifier expected, incomplete function call or spline call found instead.” caused by token counter variable using the wrong special value. The symptom occurs when using a lot of splines. See this thread for details.
(I am using a self-compiled special build because I use a lot of splines in 3.6 but would rather use an official 3.6)
|
|
24 | Geometric Primitives | Definite Bug | 3.70 beta 32 | Very Low | Critical | isosurface, bounding box & threads | Closed | |
3.70 beta 33 |
Task Description
Linux beta 32, 64bits, compiled from sources.
povray -w800 -h600 +a0.3 +kfi1 +kff78 -L/usr/local/share/povray-3.7/scenes/incdemo -Ii_internal.pov +WT5 +R4 +AM1 +MB1
Important issue: +WT5 +MB1
Seems Fine for +WT1 +MB1 Also fine for +WT5 +MB9
The intersection with the containing box displays some two-shades of grey random checkered patterns. Size of square looks like size of renderering thread. Position too.
Impacted frames (of 78): 01, 02, 03, 30, 48, 74, 76.
|
|
34 | Configure/Build | Possible Bug | 3.70 beta 32 | Very Low | Critical | configure: error: Could not link against boost_thread-b ... | Closed | |
3.70 beta 33 |
Task Description
I’ve been trying to upgrade povray 3.6.1 to 3.7-beta-32. I’ve configured with no additional arguments, and the configure dies with:
checking whether to build the boost thread library from sources... no checking for boostlib >= 1.35... yes checking whether the Boost::Thread library is available... yes checking for exit in -lboost_thread... no checking for exit in -lboost_thread-boost_thread... no configure: error: Could not link against boost_thread-boost_thread !
I figured that the problem was with my boost installation (1.35) and upgraded boost to 1.39; the problem remains. I tried to see if exit was defined in libboost_thread and/or libboost_thread-boost_thread and it isn’t. Just to be sure that my currrent setup works for the released version, I rebuilt/reninstalled 3.6.1, which went without problem.
I’m on a slackware-12.2 box, using gcc-4.4.0.
|
|
1 | Backend | Definite Bug | 3.70 beta 32 | Very Low | Medium | Mesh not smooth in 64-bit beta 32 | Closed | |
3.70 beta 33 |
Task Description
Beta 32 is failing to render a mesh2 smoothly on 64-bit XP - output shows flat triangles rather than smoothed triangles. Issue is not present in 32-bit build.
Reported in http://news.povray.org/49e51489%241%40news.povray.org. Demo image rendered using standard chessmesh scene.
|
|
13 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | 4k files crash | Closed | |
3.70 beta 33 |
Task Description
Files of exactly 4k length can cause a full crash exception when opened.
|
|
14 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Medium | coincident transparency issue | Closed | |
3.70 beta 33 |
Task Description
Overlapping partially transparent objects can result in speckled shadows. Rays shouldn’t leak through the coincident areas, they should return one of the two textures. This was correct in 3.6.
#declare testmat = material { texture {
pigment {color <1,0,0> transmit 0.5}
}};
camera { location <1.0, 2.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <1.0, -0.2, 0.0>
angle 30 }
light_source {<-10, 10, -5> color rgb <1, 1, 1>}
plane {y,-1 pigment{rgb <1,1,1>}}
union {
sphere {<0.0,0,0>,0.5 material{testmat}}
sphere {<0.1,0,0>,0.5 material{testmat}}
sphere {<0.2,0,0>,0.5 material{testmat}}
sphere {<0.3,0,0>,0.5 material{testmat}}
sphere {<0.4,0,0>,0.5 material{testmat}}
sphere {<0.5,0,0>,0.5 material{testmat}}
}
|
|
15 | Geometric Primitives | Definite Bug | 3.70 beta 32 | Very Low | Medium | julia fractal, trace and inside cause crash | Closed | |
3.70 beta 33 |
Task Description
Using trace or inside with a julia fractal causes a crash.
#declare Test = julia_fractal {
<-0.083,0.0,-0.83,-0.025>
quaternion
cube
max_iteration 8
precision 20
};
#declare Norm = <0,0,0>;
#declare Hit = trace(Test,<0,0,-10>,z,Norm);
#declare Center = inside(Test,<0,0,0>);
|
|
16 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Medium | reflective texture map crash | Closed | |
3.70 beta 33 |
Task Description
Reflective texture maps can cause a stack overflow crash.
sphere{0,1
texture{
bozo
texture_map{
[0 pigment{rgb 0}]
[1 pigment{rgb 0} finish{reflection 1}]
}
}
}
|
|
18 | Distribution | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | read only files in distribution | Closed | |
3.70 beta 33 |
Task Description
Array.inc and subsurface.pov are in read only mode, they probably should have normal permissions.
|
|
31 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Medium | function pattern in image map | Closed | |
3.70 beta 33 |
Task Description
Function use in image maps is broken.
The following should result in a white and green checkered unit square, but is transparent.
camera {
location <0.0, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
background {rgb <1,1,1>}
light_source {
<-30, 10, -30>
color rgb <1, 1, 1>
}
plane {y,-1 pigment{checker rgb <1,0,0> rgb <1,0.5,0.5> }}
plane {y,-0.99
pigment {
image_map {
function 10,10 {
pigment {checker rgb <0,1,0>, rgb <1,1,1> scale 0.1}
}
once
}
rotate <90,0,0>
}
}
|
|
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)
|
|
11 | Configure/Build | Compatibility Issue | 3.70 beta 32 | Very Low | Low | Need to rename Rect to avoid clash with OSX | Closed | |
3.70 beta 33 |
Task Description
The Rect data type needs to be renamed to avoid a clash with a Mac OSX declaration. It was originally called Rectangle, but this clashed with a Windows declaration. Something more POV-specific should be used, e.g. PovRect.
|
|
17 | Texture/Material/Finish | Possible Bug | 3.70 beta 32 | Very Low | Low | square blotches in transparency | Closed | |
3.70 beta 33 |
Task Description
There can be square (32×32) blotches in partially transparent objects.
global_settings {
max_trace_level 10
}
camera {
location <-30,10,5>
look_at <0,0,0>
angle 25
}
light_source {
<-100,30,70>
rgb 1
}
difference { // make a dome
sphere { <0,0,0> 5 } // ball
sphere { <0,0,0> 4.9 } // hollow interior
box { <-6,-6,-6> <6,1,6> pigment { rgb <0,0,0> }} // chop off bottom half
pigment { rgbt <1,1,1,0.675> }
}
box {
<-6,-6,-6>, <6,0.99,6>
pigment { rgb <1,1,1> }
rotate <0,45,0>
} // sit it on a box
|
|
33 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Low | parse accepting invalid vector float components | Closed | |
3.70 beta 33 |
Task Description
The parser is missing extra period characters when it parses a float as a vector component.
#local sample = <0.0.0.1,0,0>;
Doesn’t generate an error, but should.
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
92 | Geometric Primitives | Definite Bug | 3.70 beta 36 | Low | High | Sphere_Sweep Bug | Closed | |
3.70 beta 37 |
Task Description
This item may need to be merged with item FS#81. This is another sphere sweep bug, though they are of different spline types.
The code is
#include "colors.inc"
camera {
location <0, 0.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
#declare i_start = 0;
#declare i_stop = 3;
#declare i_step = 0.05;
#declare i_inc = i_start;
sphere_sweep {
linear_spline // linear curve
(i_stop - i_start)/i_step + 1, // number of specified sphere positions
#while(i_inc<=i_stop)
#declare y_coor = 0.23*sin(7.1*i_inc);
<i_inc, y_coor, 0>, 0.05
#declare i_inc = i_inc + i_step;
#end
pigment{color Orange}
}
|
|
94 | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | High | Unexpected refraction angle in interfaces with changing ... | Closed | |
3.70 beta 37 |
Task Description
I’ve tried to model this setup: http://kschwebke.webng.com/povray/ior-interfaces/drawing.png with the following SDL: http://kschwebke.webng.com/povray/ior-interfaces/rs2.pov.txt
A small overlap between the two transparent solids is needed, because a gap would lead to total reflection. The camera in the test scene looks in the direction of the ray in the setup drawing. The setup is surrounded with angular markers, so one can easily read the final resulting looking angle.
POV-Ray 3.6.1 renders the expected result (~53° in the center of the screen): http://kschwebke.webng.com/povray/ior-interfaces/rs2-35.jpeg
POV-Ray 3.7.0b35a (compiled Unix source) renders a different (and in my opinion wrong) angle (~67°), however – for the very same scene file: http://kschwebke.webng.com/povray/ior-interfaces/rs2-37b35a.jpeg
I’ve started a discussion about this issue in povray.beta-test: http://news.povray.org/povray.beta-test/thread/%3Cweb.4bba4677730ab9f3e8c084b40%40news.povray.org%3E/
All linked documents are also attached.
|
|
95 | Photons | Definite Bug | 3.70 beta 36 | Low | High | Photons are over-attenuated by semi-transparent surface ... | Closed | |
3.70 beta 37 |
Task Description
The code to attenuate transmitted photons according to surface texture was apparently duplicated during refactoring of the source code for version 3.7. Behavior has changed from 3.6 to 3.7 (beta.36) accordingly, as can be demonstrated with the following scene:
global_settings {
assumed_gamma 1.0
max_trace_level 10
photons { spacing 0.02 }
}
camera {
right x*image_width/image_height
location <0,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
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>]
}
}
}
plane {
y, 0
texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.5
fade_power 1001
fade_distance 0.9
fade_color <0.5,0.8,0.6>
}
}
#declare M_PseudoGlass2=
material {
texture {
pigment {rgbf <0.8,0.2,0.2,0.8>}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.0
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,0.3>
material { M_PseudoGlass2 }
photons { target 1.0 refraction on reflection on }
}
|
|
19 | Texture/Material/Finish | Feature Request | 3.70 beta 32 | Very Low | Low | AOI pattern | Closed | |
3.70 beta 37 |
Task Description
Adding an AOI pattern is asked for fairly frequently.
|
|
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).
|
|
88 | Image format | Definite Bug | 3.70 beta 36 | Very Low | Low | File output code does not properly handle negative colo ... | Closed | |
3.70 beta 37 |
Task Description
File output code for virtually all file formats performs gamma correction on unclipped color values, which leads to issues when color values happen to be negative for some reason and gamma does not happen to be an integer value such as 1.0 or 2.0. As a consequence, subsequent steps (clipping and converting to integer) apparently produce compiler-dependent results. Compiled with Microsift or Intel compilers, POV-Ray seems to write zero brightness in such cases, while compiled with g++ 4.4 (and possibly other compilers) it seems to write full brightness instead.
(See thread news://news.povray.org:119/4ba819f6@news.povray.org for examples.)
The proper solution should be to apply gamma correction after clipping.
|
|
89 | Image format | Definite Bug | 3.70 beta 36 | Very Low | Low | PPM output garbled for bit depths other than 8 bits | Closed | |
3.70 beta 37 |
Task Description
When choosing PPM output with a bit depth other than 8 bits per color channel (e.g. +FP16), POV-Ray messes up the colors (see thread news://news.povray.org:119/4babb48f$1@news.povray.org)
|
|
100 | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | Low | cutaway_textures | Closed | |
3.70 beta 37 |
Task Description
When using cutaway_textures the differenced part traces black. Simple scene file attached.
|
|
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?
|
|
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).
|
|
90 | Parser/SDL | Definite Bug | 3.70 beta 36 | Very Low | Very Low | POV-Ray accepts additional patterns after "slope" | Closed | |
3.70 beta 37 |
Task Description
The following code is erroneously accepted by POV-Ray (tested with 3.7.0.beta.36):
pigment{
slope { x }
checker
}
The result is a checker pattern.
Apparently there is an EXIT statement missing in the slope-pattern parsing code in parstxtr.cpp.
|
|
104 | Image format | Definite Bug | 3.70 beta 37 | Medium | Critical | Output file gamma broken for File_Gamma=1.0 | Closed | |
3.70 beta 37a |
Task Description
Setting File_Gamma=1.0 produces unexpectedly bright output files for most output file formats, as if File_Gamma was set to 2.2 instead.
The underlying problem is a bug that, when File_Gamma is set to exactly 1.0, causes the encoding gamma function to be undefined, which was not meant to happen in current versions, and instead was reserved for future versions to signal that a file-format-specific default encoding gamma should be used. The image file output handlers already support this, most of them choosing the sRGB transfer function, giving roughly the same output as setting File_Gamma=2.2.
As a preliminary workaround, users may want to set File_Gamma=1.02 (any value smaller than 0.99 or greater than 1.01 should do).
|
|
113 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Low | High | Multi-layered reflections broken | Closed | |
3.70 beta 38 |
Task Description
Reflections in multi-layered textures are broken in 3.7 betas, as can be demonstrated with the following scene showing two reflective hemispheres on a checkered plane:
camera {
location <1.0, 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>
}
default {
finish { diffuse 0 ambient 0 specular 0 }
}
// ----------------------------------------
plane { // checkered floor
y, -1
texture
{
pigment { checker color rgb 1 color blue 1 }
finish{ diffuse 0.8 ambient 0.1 }
}
}
// left hemisphere
intersection {
sphere { 0, 1 }
plane { x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 } }
}
}
// right hemisphere
intersection {
sphere { 0, 1 }
plane { -x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 1.0 } }
}
}
Note that the reflection parameters of the left, multi-layered hemisphere sum up to 1.0, i.e. the same value as used in the single layer in the right hemisphere.
The first attached file (test_3.6.2.png), rendered with POV-Ray 3.6.2, shows the expected output: Both hemispheres appear to have the same reflectivity.
The second attached file (test_3.7.0.beta37a.png), rendered with POV-Ray 3.7.0.beta.37a, shows a much brighter left (multi-layered) sphere.
As it turns out, in order to get the expected result with POV-Ray 3.7.0.beta.37a, the reflectivity of each layer must be divided by 3, 2 and 1, respectively (which obviously does not sum up to 1.0):
...
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 / 3 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 / 2 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 / 1 } }
}
...
|
|
97 | Other | Possible Bug | 3.70 beta 36 | Very Low | Low | Forward-slash pathnames not fully supported in Windows ... | Closed | |
3.70 beta 38 |
Task Description
The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.
|
|
101 | Include files | Feature Request | 3.70 beta 36 | Very Low | Low | woodmaps.inc dependency | Closed | |
3.70 beta 38 |
Task Description
woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1
|
|
103 | Image format | Definite Bug | 3.70 beta 37 | Very Low | Low | JPEG output does not conform to baseline JFIF standard | Closed | |
3.70 beta 38 |
Task Description
POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.
As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.
|
|
107 | Parser/SDL | Definite Bug | 3.70 beta 37 | Very Low | Low | Failed to parse INI file, over network | Closed | |
3.70 beta 38 |
Task Description
I can no longer run a Myfile.ini over a network, on a different computer.
Possiblely related to:
http://bugs.povray.org/task/97 FS#97 (Forward-slash pathnames not fully supported in Windows version)
- Cannot open INI file ‘\\STEPHEN-POVRAY\Bishop3d\Objects\Industrial_enclosure\Telco_enclosure_extra.ini’. Failed to start render: Failed to parse INI file
|
|
110 | Sample scenes | Definite Bug | 3.70 beta 37a | Very Low | Low | Sample Lathe Scenes no Longer work in 3.7 | Closed | |
3.70 beta 38 |
Task Description
The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.
<3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
Although it works in version 3.6, only in 3.7 does a render time error ocurr.
Scene source should be adjusted to the following
<3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
|
|
111 | Parser/SDL | Definite Bug | 3.70 beta 37a | Very Low | Low | Remove_Bounds=off / -UR does not work properly | Closed | |
3.70 beta 38 |
Task Description
Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.
|
|
112 | Image format | Definite Bug | 3.70 beta 37a | Very Low | Low | OpenEXR alpha is only written when it shouldn't be | Closed | |
3.70 beta 38 |
Task Description
OpenEXR output currently writes an alpha channel when Output_Alpha=off (-UA), and does not write an alpha channel when Output_Alpha=on (+UA), i.e. doing it just the wrong way round.
|
|
116 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Very Low | Low | assertion fails when using "filter all" with small-pale ... | Closed | |
3.70 beta 38 |
Task Description
When using “filter all VALUE” with an image_map using a 4-bit (16-color) paletted bmp image, debug builds of POV-Ray fail with an assertion.
According to code analysis, other paletted image formats with <256 palette entries are also likely to be affected; similar assertion fails can be expected when using the “filter INDEX, VALUE” feature on such files with an index exceeding the palette size. “transmit” shows the same flaws.
|
|
122 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #ELSEIF statement | Closed | |
3.70 beta 38 |
Task Description
Request an #ELSEIF statement in POV SDL.
|
|
135 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | Right-click menu when clicking on editor tab | Closed | |
3.70 beta 38 |
Task Description
When right-clicking on a tab in the editor window a list of options should appear, such as:
* Close * Close all but this * Save * Save as * Print
See Notepad++, EditPad Lite, and Firefox for examples.
|
|
137 | Include files | Feature Request | 3.70 beta 37a | Very Low | Low | atand function | Closed | |
3.70 beta 38 |
Task Description
There already exist atan, atan2 and atan2d functions, why not atand?
|
|
29 | Image format | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Medium | Re-implement image output to STDOUT | Closed | |
3.70 beta 39 |
Task Description
Versions of POV-Ray prior to 3.7 had the ability to write the image output as a stream to STDOUT. This was particularly useful in unix as it allowed POV-Ray output to be directly piped to other processes.
The introduction of SMP and the associated non-linear generation of pixels complicates stream output to the extent that it is not currently available in v3.7.
At a minimum 3.7 must at least be able to write the completed image to STDOUT after a render - this is not an optimal solution but is better than nothing. Ideally however once entire lines are complete (most likely this will occur in batches due to the block nature of the render subdivision) these lines will be written immediately to STDOUT (after possibly being processed through the appropriate image format routines).
NB currently the image format routines are not invoked until the entire render is completed, so to do this would be a significant modification. However if we limit real-time stream output to “simple” non-compressed formats (e.g. PPM), it would not be overly difficult, and from the point of view of Unix-like operating systems (where the piping feature is most useful), if the data is in PPM format it can easily be transformed into anything else.
|
|
144 | Image format | Compatibility Issue | 3.6 | Very Low | Medium | povray compatibility issue with png-1.4 | Closed | |
3.70 beta 39 |
Task Description
source/png_pov.cpp included in povray-3.6.1 contains calls to an internal function of libpng (png_write_finish_row) which was removed from the public interface quite a while ago, so linking fails.
Also, in the 1.4 releases of libpng, the info_struct “trans” member was renamed to trans_alpha. This causes a compilation error in the same file.
A suggestion for the solution: a) remove the png_write_finish_row prototype and function call b) add something like: #if PNG_LIBPNG_VER < 10400 #define trans_alpha trans #endif and change cmap[index].Transmit = 255 - r_info_ptr→trans[index]; to cmap[index].Transmit = 255 - r_info_ptr→trans_alpha[index]; (two occurrences).
|
|
155 | Runtime error | Definite Bug | 3.70 beta 38 | Very Low | Medium | Not able to run --benchmark | Closed | |
3.70 beta 39 |
Task Description
Compiled on linux (revision #5066), ./configure COMPILED_BY=”###” –disable-io-restrictions
the command: povray –benchmark
is failing: Failed to parse INI file
povray –version
povray: this pre-release version of POV-Ray for Unix expires in 27 day(s) and 5 hour(s) POV-Ray 3.7.0.beta.38
This is a time-limited beta test version which expires 31 Dec 2010. General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2010 Persistence of Vision Raytracer Pty. Ltd.
Built-in features:
I/O restrictions: disabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.4.3
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
157 | Include files | Definite Bug | 3.70 beta 37a | Very Low | Medium | Warnings when parsing include file provided by distribu ... | Closed | |
3.70 beta 39 |
Task Description
Include file golds.inc still provides warnings when parsed, a shame for a standard include file. (colors.inc is ok, I did not test the other includes)
File '/usr/local/share/povray-3.7/include/golds.inc' line 118: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 119: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 129: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 130: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 140: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 141: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 151: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 152: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 162: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 163: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
|
|
158 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Antialias Gamma reporting error | Closed | |
3.70 beta 39 |
Task Description
value is erroneously clipped to the range 0..1 before being displayed
|
|
162 | Geometric Primitives | Definite Bug | 3.6 | Very Low | Low | Character 101 (0x65) not found in /usr/share/fonts/true ... | Closed | |
3.70 beta 39 |
Task Description
The text object isn’t working with /usr/share/fonts/truetype/freefont/FreeSans.ttf. Used to work - taken from an old .pov file of mine.
Rebuilt from http://www.povray.org/redirect/www.povray.org/ftp/pub/povray/Official/Unix/povray-3.6.tar.bz2
$ povray +ifonttest.pov +ofonttest.png
Persistence of Vision™ Ray Tracer Version 3.6.1 (g++ 4.4.3 @ x86_64-unknown-linux-gnu) This is an unofficial version compiled by: darxus [at] chaosreignscom
.....
File: fonttest.pov Line: 8 Parse Warning: Character 101 (0×65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf File: fonttest.pov Line: 8 Parse Warning: Character 115 (0×73) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf
Verification that the problem is not in the .ttf file, this works (imagemagick):
convert -background lightblue -fill blue -pointsize 48 -font /usr/share/fonts/truetype/freefont/FreeSans.ttf label:test fonttest.png
Problem verified when compiled from source on Ubuntu Lucid. Also exists in Ubuntu binaries from Lucid and Hardy.
|
|
10 | Parser/SDL | Feature Request | 3.70 beta 32 | Very Low | Medium | Add support for specifying input images' gamma pre-corr ... | Closed | |
3.70 beta 40 |
Task Description
Input image files may have been created with gamma pre-correction for some specific target gamma, which may vary from image to image. Some file formats like PNG or HDR support embedding gamma pre-correction information in the image file, but this information may be missing or faulty, and some formats don’t support it at all. Additionally, it may be desirable to tamper with an input image’s gamma for artistic reasons.
Therefore, I suggest adding a means to explicitly specify input images’ originally intended target gamma on a per-image basis, like:
image_map { jpeg "MyImage.jpg" assumed_gamma 1.8 }
|