|
36 | Documentation | Definite Bug | Not applicable | Very Low | Low | GuMax | Closed | |
|
Task Description
After a recent update on the POV-Wiki the GuMax skin doesn’t recognize MediaWiki:Common.css entries.
|
|
35 | Documentation | Feature Request | All | Very Low | Low | problem parsing +i option in povray-3.7.0.beta.32 on li ... | Closed | |
|
Task Description
The commands:
povray +i /home/ronis/Nm=500/povray.00001.pov
or
povray +i/home/ronis/Nm=500/povray.00001.pov
fail with: povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and 1 hour(s) Failed to parse command-line option
Going to the directory and simply running: povray +i povray.00001.pov works.
I came across this by accident trying to get emac’s povray mode to work; apparently it passes the full path name to povray.
I don’t think there is a problem in 3.6.1
|
|
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.
|
|
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.
|
|
32 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | tiff file extention error | Closed | |
|
Task Description
The parser is failing to read the .tiff file extension from the input string...
bump_map { tiff "earth03_hf2.tiff" }
Results in file not found, but
bump_map { tiff "earth03_hf2" }
will find the file. It might be that it’s not a three character extension?
|
|
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>
}
}
|
|
30 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Custom progress information during parsing | Closed | |
|
Task Description
For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.
|
|
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.
|
|
28 | Frontend | Feature Request | 3.70 beta 32 | Very Low | Low | #debug message not displayed. | Tracked on GitHub | |
Future release |
Task Description
The #debug message stream is only being flushed when it hits a newline character, instead of after each #debug statement. This means that some final strings don’t show up.
#debug "This line prints,\n but this line doesn't."
|
|
27 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | Add texture support to background statement | Tracked on GitHub | |
Future release |
Task Description
Adding full texture statement support to the background statement (with a scale of 1/1) aligned with the image_map direction of an image would allow i.e. specifying an image as background easily.
|
|
26 | Geometric Primitives | Definite Bug | 3.61 | Very Low | Low | Artifacts rendering a cloth which has two-side textures | Tracked on GitHub | |
Future release |
Task Description
Dear PovRay maintainers and developers, congratulations for your great RayTracer!
We think that we have found a bug while we were rendering a piece of cloth.
In this piece of cloth were defined two textures, one for one side and one for the another side:
texture { mesh_tex0_0 }
interior_texture { mesh_tex0_1 }
these definitions in their original context.
We have found some artifacts in the final rendering, in concrete near some wrinkles, please, look at the attached file “render_artifacts.tga”, I have painted a big green arrow near the artifacts, maybe you’ll need to do a zoom to see them more accurately.
They are as though the texture of the other side was painted in the incorrect side.
Fortunately, we have a patch to fix this bug (thanks to Denis Steinemann, he made the implementation for PovRay 3.5, so I have adapted these changes to release 3.6.1)
Although we have found this bug in the Windows and Linux 3.6.1 releases, the patch was generated in Linux (using the source code release of “povray-3.6.1”).
To apply this patch, inside the parent folder of the directory “povray-3.6.1” execute:
patch -p0 < other_side_artifacts.patch
And the “povray-3.6.1” will be patched and you will get a console output like this:
patching file povray-3.6.1/source/lighting.cpp
patching file povray-3.6.1/source/mesh.cpp
patching file povray-3.6.1/source/render.cpp
We don’t know if this “hack” is enough smart to apply in the next release, but we think that it fixes the bug (the artifacts dissapear).
Best regards and thank you very much for your great RayTracer!
|
|
25 | Animation | Definite Bug | 3.70 beta 32 | Defer | Low | Pause sometimes fails when rendering animation | Tracked on GitHub | |
|
Task Description
There is an issue where the pause button in POVWIN will sometimes not work during an animation (primarily where the frame rate is high), and furthermore, POVWIN can then get into a state where it’s not possible to use the pause until it is re-started.
Newsgroup report.
|
|
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.
|
|
23 | Platform-specific | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | X Window preview might lock | Closed | |
3.70 release |
Task Description
Beta 32, compiled from source on Linux/Ubuntu, amd64.
The random “window display lock” is back. (as the previous “solution” was to get no window display usable, that’s not so bad).
What is it: sometime, when the rendering window is activated, povray just draw the frame of the window, paint it black, does not display anything else but seems to perform the rendering in separate threads. Whenever the mouse move over the frame of the window, it unlock the updating process and big parts of the rendered image pop up.
What it is not fine: if you do not move the mouse over the window, povray will just stall. This is more a problem for animation rendering, as getting the display might be a wanted bonus to monitor the rendering images, and you just fall into that lock: your expected night rendering could very well be suspended on the first frame. Moreover, the “move the mouse over” works only for local display. In previous beta (not yet checked with 32), with a remote display, there was no way to unlock povray.
|
|
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)
|
|
21 | Distribution | Definite Bug | 3.70 beta 32 | Very Low | Low | unix scripts have wrong version set | Closed | |
|
Task Description
In unix distribution these scripts
allscene.sh
allanim.sh
porfolio.sh
have the variable VERSION set to 3.6
|
|
20 | User interface | Feature Request | 3.70 beta 32 | Very Low | Very Low | render window behavior | Tracked on GitHub | |
|
Task Description
When changing the behavior of the render window, “Keep above main”, requires restarting the POV editor to take effect. It would be nice either to get a warning to restart, or to get it to work without restarting.
|
|
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.
|
|
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.
|
|
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
|
|
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}]
}
}
}
|
|
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>);
|
|
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}}
}
|
|
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.
|
|
12 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Very Low | facets pattern in normal map | Closed | |
3.70 RC6 |
Task Description
Using a facet pattern in a normal map results in a unspecified error in Evaluate_TPat at the render stage. This probably should be caught at parse time to give a more descriptive error and a line number.
Example:
sphere {
0, 1
texture{
pigment{rgb <1,1,1>}
normal {
facets
normal_map {
[0 bumps ]
[0.5 facets ]
[1 bumps ]
}
}
}
}
|
|
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.
|
|
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 }
|
|
9 | Parser/SDL | Feature Request | 3.70 beta 32 | Very Low | Low | Add support for tuning brightness of image-mapped sky s ... | Closed | |
3.70 RC4 |
Task Description
Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.
To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.
|
|
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.
|
|
7 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Re-implement Radiosity render abort/continue support | Tracked on GitHub | |
|
Task Description
For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.
To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.
|
|
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.
|
|
5 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | Integrate Subsurface Scattering with Radiosity | Closed | |
Future release |
Task Description
Subsurface scattering must be made radiosity-aware.
|
|
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.
|
|
3 | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Medium | Documentation needs to be updated for version 3.7 | Closed | |
3.70 release |
Task Description
The version 3.6 documentation needs to be updated to suit the changes for version 3.7.
|
|
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.
|
|
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.
|