|
267 | Geometric Primitives | Definite Bug | 3.70 RC6 | Very Low | Medium | Bug in "sor" Primitive Leads to Random Black Artefacts ... | Closed | |
3.70 RC7 |
Task Description
Recently, I have been rendering an animation with POV-Ray 3.7 RC 6 using radiosity, photons and backside illumination. Many frames contained artefacts like in the attached image file. Trying to eliminate those artefacts I observed the following:
Rendering the same frame several times did not reproduce the artefacts or reproduced them differently. I.e., when I rendered a second (third, fourth, ...) time with +SF100 +EF100, the black space in the image was somewhere else or in some cases disappeared.
With radiosity turned off, no such artefacts have happened since, even in the scenes where they happened with radiosity turned on.
Turning off photons with radiosity still turned on did not remove the artefacts.
Rendering with one thread on one CPU core instead of two threads on two cores did not change anything except the rendering time.
Changing the radiosity settings I have not tried thoroughly, but at least raising or lowering count or error_bound does not seem to have any effect on this.
While POV-Ray was rendering, no other memory-intensive or CPU-intensive programs were running and POV-Ray itself did not report any error (just the usual warnings that some of the used features could change in future versions etc.). Render priotity was set to “high”.
|
|
261 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | mesh_camera distribution type 3 output image is placed ... | Closed | |
|
Task Description
Output images are 0.5 pixels too right and 0.5 pixels too down (mesh_camera_bug.pov).
The error is cumulative when image files are used again as texture (run 10 times mesh_camera_bug_reuse.pov).
This can be compensated by adjusting UV maps (mesh_camera_fix.pov and mesh_camera_fix_reuse.pov).
Tested with and without anti-aliasing.
|
|
255 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 should compute per vertex or per fac ... | Closed | |
|
Task Description
The documentation states mesh_camera 0 should produce 1 pixel per index but it currently seems to produce 1 lighting pixel per face.
This output seems fairly meaningless as using this data for vertex colours (presumably the intention for mesh_camera 0) would result in a flat shaded model.
Logically it would make more sense to output 1 pixel per vertex instead of 1 pixel per face. Another solution might 1 pixel per face index (as per documentation) although POV would need to record which indices had already been computed otherwise it could end up duplicating computation.
At the moment I’ve written a code workaround for my exporter which produces a special mesh but this is obviously a much more complex solution to a fairly simple problem.
|
|
254 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 output seems to be incorrect | Closed | |
|
Task Description
When using mesh_camera type ‘0’
The first line of the mesh output seems to be repeated resulting in incorrect light colour values.
If the first line of the texture is skipped then the values seem to be correct.
|
|
251 | Parser/SDL | Possible Bug | 3.70 RC6 | Very Low | Medium | Scene / include files of >2GB size may cause problems | Tracked on GitHub | |
3.71 release |
Task Description
Code inspection shows that we’re still using fseek() and ftell() in various places (including text file input), which can’t handle file positions of 2GB and beyond (except on 64-bit linux machines); those calls need to be examined and (where appropriate) replaced with the fseek64() macro we’re already defining (but currently not using), and a to-be-defined ftell64() macro.
One potential (untested) error scenario would be a scene file calling a macro that is defined at the end of a > 2GB long include file.
|
|
239 | Setup/Install | Definite Bug | 3.70 RC4 | Very Low | Medium | Owner and group of user's local configurations on insta ... | Closed | |
Future release |
Task Description
I reinstall a system, (so ~/.povray was not existant), and then installed povray from sources, as a normal user (excepted the installation step):
$ ./configure ... $ make $ make check $ sudo make install
I find these steps pretty much standard.
The problem I’m noticing is that the $HOME/.povray hierarchy get owned by root (hey, it’s *MY* directory !). There is a chown in the Makefile for the target files (povray.ini & povray.conf), as well as subtree but:
* povowner & povgroup are hard coded to 0 (I would expect a copy of the owner & group of $HOME, wouldn’t I ?)
For getting povowner, I would suggest `stat -c “%u” $HOME` For povgroup, `stat -c “%g” $HOME`
Are they portable enough ? (I could ask on Monday a Solaris system, but I do not have bsd and the other flavours of unix)
(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)
Side note: This is fine to install for the local user, but new later users could benefit also from a ~/.povray/3.7/ subtree ; what about also filling the /etc/skel (when available) ? (and in /etc/skel, root owner is fine!)
|
|
236 | Animation | Possible Bug | 3.70 RC3 | Very Low | Medium | Segmentation fault with animation of large image | Closed | |
|
Task Description
If the image is more than 1270 pixels wide or more than 720 pixels high, animation fails with a segmentation fault during the second rendered frame. This happens after parsing is complete and the .pov-state file is created. The last message line is the “[Rendering...]” line. (There is also a separate, but possibly related, issue that the output display does not work for these renders.)
On one occasion, POV-Ray hung, and I had to ctrl-Z kill -9 out of it.
On another occasion, instead of the segmentation fault, I got the message:
povray: xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed.
Aborted
There is no crash when -D is used.
I have not run an animation this large in Windows, so I don’t know if it’s a problem there.
Neither problem occurs in POV-Ray 3.6.1.
I used the following source code:
global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }
Operating system: openSUSE Linux 12.1 Hardware: HP Pavilion dv5030us Notebook PC (32 bits) RAM: 1GB Displays: 1280×800 built-in panel; 1680×1050 HP w2007 external monitor
Libraries
Boost 1.48.0 (Note: bzip2 and python dependent modules did not compile, and MPI support does not work.) Zlib 1.2.5 (LibXML 2.7.8) LibPNG 1.5.7 LibJPEG IJG 8d LibTIFF 3.8.2 OpenEXR 1.6.1 (IlmBase 1.0.1) SDL unknown
|
|
228 | Texture/Material/Finish | Possible Bug | 3.70 RC3 | Very Low | Medium | Emission Media does not show on Alpha background | Closed | |
|
Task Description
I tried to render a candle’s flame (an object with interior made of emission media) against an Alpha background. In 3.6, the “flame” appears as a bright object against the alpha background; but in 3.7, the flame disappears against the alpha (as the attached scene will make clear, the “flame” is still visible against opaque background objects). I used the settings “Output_Alpha=true Output_File_Type=N”.
If there is another (better?) way to achieve a similar effect, I am open to using a work-around.
|
|
213 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing check for ios failbit/badbit: endless loop whil ... | Closed | |
3.70 RC4 |
Task Description
Hello,
this bug report relates to this thread: http://news.povray.org/povray.beta-test/thread/%3Cweb.4e0064d9a3970d212b256d410%40news.povray.org%3E/
In /unix/unixoptions.cpp around line 817:
while ( !Stream.eof() )
{
// get and preprocess line
std::getline(Stream, line);
line = pre_process_conf_line(line);
++line_number;
// skip empty line
if(line.length() == 0)
continue;
[...]
}
`Stream.eof()` could never be true as well as `line.length()` always can be zero, leading to an endless loop. In my case, the problem occurred due to my ~/.povray/3.7/povray.conf being a directory instead of a file.
To fix the problem, one has to consolidate this loop by not only checking for eofbit, but also for failbit and badbit of `Stream`. The getline() method on a directory does not set the eofbit, but it sets fail and bad (test: http://codepad.org/RiZGo3ia). According to http://www.cplusplus.com/reference/iostream/ios/operatornot/ fail and bad can be checked for by `!Stream`. A simple `if (!Stream) break;` within the loop fixes the problem (patch file attached).
Are there more missing checks on iostreams like this in the code? :) They should definitely be fixed.
Furthermore, one could think about using the boost filesystem library to be able to distinguish files and directories to provide good error messages.
Hope that helps,
Jan-Philip Gehrcke
|
|
210 | Geometric Primitives | Definite Bug | 3.70 RC3 | Low | Medium | UV mapping broken for parametric | Closed | |
3.70 RC4 |
Task Description
UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.
In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.
camera {
location <0.0, 1.5, -3.0>
direction 1.5*z
right x*image_width/image_height
look_at 0
}
light_source { <-30, 30, -30> color rgb 1 }
#declare Param = parametric {
function { u*v*sin (15*v) },
function { v },
function { u*v*cos (15*v) }
0, 1
contained_by { box { -1,1 } }
accuracy 0.002
precompute 15 x,y,z
rotate 180*x
translate <0.3,0.5,0>
}
object {
Param
uv_mapping
texture {
pigment {
gradient x frequency 3
color_map {
[0 color red .5 ]
[1 color red 1 ]
}
}
}
}
object {
Param
uv_mapping
texture {
pigment {
gradient x frequency 7
color_map {
[0 color green .5 ]
[1 color green 1 ]
}
}
}
rotate y*180
}
POV-Ray 3.62 renders the scene properly.
As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.
|
|
209 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Medium | Weighted texture of CSG | Closed | |
3.70 RC4 |
Task Description
in change #3319, csg got a new computation for its weighted textures.
But I’m confused by the computation of the weight: (circa end of csg.cpp file)
COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);
I would have used a max() rather than a min().
It is transparent when there is only one texture, but:
should there be no texture (an error...): it would be a division by 0
should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n
Or did I get a confusion about min() ?
min(0,1) == 0 min(4,1) == 1
Using max would protect against the division by 0 and the right value when multiple textures are used.
Any thought ?
|
|
198 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing closing brace in function definition causes mem ... | Closed | |
3.70 RC4 |
Task Description
Given the following two statements, a missing closing brace in the function declaration fn should throw a parse exception; instead it causes a memory access violation when trying to use fn in the second delcaration:
#local fn = function {
pigment { image_map { png "MultiPassBlobs3.png" gamma 1 map_type 0 once }}
#local clr = fn(0,0,0);
|
|
195 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Medium | povray-3.7.0rc3 incompatible with NetBSD | Closed | |
|
Task Description
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe) 2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable. 3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix). 4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3. 5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is #ifdef HAVE_SYS_WAIT_H # include <sys/wait.h> #endif but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html. Backtrace is Program terminated with signal 11, Segmentation fault. #0 0x00000000004ac479 in boost::gregorian::date::date () (gdb) bt #0 0x00000000004ac479 in boost::gregorian::date::date () #1 0x00000000004d29f7 in boost::gregorian::date::date () #2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= () #3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= () #4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= () #5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName () #6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName () #7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName () #8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= () #9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>) at /archive/cvs/src/lib/libpthread/pthread.c:473 #11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
|
|
181 | Backend | Unimp. Feature/TODO | 3.70 beta 40 | Very Low | Medium | Unimplemented, altered or missing features to document ... | Tracked on GitHub | |
|
Task Description
This is a list of unimplemented features and things to fix with respect to 3.7 vs 3.6 compatibility. They either need to be fixed in code, or failing that, to be documented prior to release.
Create_INI works differently from 3.6. Prior versions of POV-Ray would write all options to the file, even if they were not supplied by the user (non-supplied options would take the default value). Currently in 3.7, only supplied options are written, because the front-end does not send unused options to the back-end. The proper fix for this would be to have a set of defines that establish the defaults all in one place (currently we rely on hard-coded values scattered around the code), and for the Output_INI_Option() function to look up and use the default when not supplied. As this is not likely to be done before 3.7 release, we need to document it as a temporary situation.
The following messages are marked as ‘currently not supported by code’ in povmsgid.h. We need to check where this comment is correct and if so the docs need to be updated to indicate this (for items that are already documented). Some items may be re-implemented later, and some may never be:
kPOVAttrib_TestAbort
kPOVAttrib_TestAbortCount
kPOVAttrib_VideoMode
kPOVAttrib_Palette
kPOVAttrib_DisplayGammaType
kPOVAttrib_FieldRender
kPOVAttrib_OddField
kPOVAttrib_AntialiasGammaType
kPOVAttrib_LightBuffer
kPOVAttrib_VistaBuffer
kPOVAttrib_DrawVistas
This bug should be edited to add/remove items as time goes by.
|
|
174 | Setup/Install | Definite Bug | 3.70 beta 39 | Very Low | Medium | I/O Restriction defaults not being properly set for POV ... | Closed | |
3.70 RC7 |
Task Description
I/O Restriction defaults are not being properly set on a fresh install of POVWIN.
See this thread for more information.
|
|
168 | Texture/Material/Finish | Definite Bug | 3.70 beta 38 | Very Low | Medium | noise_generator default broken | Closed | |
3.70 beta 40 |
Task Description
[Original Title: “texture_map interpolation does not work correctly for some patterns”]
The below test scene should yield identical textures T_STRAND1 and T_STRAND2 but this is not the case. Reported and verified in
http://news.povray.org/povray.general/thread/%3C4cbd804b%241%40news.povray.org%3E/
The problem seems to affect bozo, bumps, dents, granite, spotted, and maybe wrinkles. The problem was reported earlier in
http://news.povray.org/povray.beta-test/thread/%3C48112367%241%40news.povray.org%3E
with a comment that 3.6 gives the expected results
#declare C_STRAND = color rgb 1;
#declare C_CLEAR = color rgb 0;
#declare T_STRAND = texture
{
pigment {color C_STRAND}
}
#declare T_CLEAR = texture
{
pigment {color C_CLEAR}
}
#declare T_STRANDS1 = texture
{
pigment
{
granite scale 2 color_map
{
[0.0 color C_STRAND]
[0.5 color C_CLEAR]
[1.0 color C_CLEAR]
}
}
}
#declare T_STRANDS2 = texture
{
granite scale 2 texture_map
{
[0.0 T_STRAND]
[0.5 T_CLEAR]
[1.0 T_CLEAR]
}
}
plane
{
z, 10
texture {T_STRANDS1}
//texture {T_STRANDS2}
}
|
|
167 | Other | Definite Bug | 3.70 beta 38 | Very Low | Medium | Core dump when rendering to huge dimensions | Closed | |
|
Task Description
From post in povray.general (circa 29 september 2010: “Maximum Resolution of Renders?”)
The ultimate goal would be a 41000×41000 image. However each time I have attempted to render that Pov-Ray has crashed on me. Even when using a single, simple test object (a plain white sphere that should use a single pixel). So I think this is running into a program limitation at present.
It won’t be for the faint hearted: a 30500 x 30500 does still produces the bug, but you’d better have 24 GB of true ram to test it. (it’s a render of a few “real” minutes if you do not swap, for any very quick scene (a 305 x 305 in 0.117s moved to 220s for 30500×30500 on my system when corrected))
With core-dumped enable, the issue is pointed in the creator of PixelContainer. The problem is due to the resize() parameter: despite the parameter being a size_t (8 bytes long on 64bits), the computation ( h * w * 5 ) use unsigned int for h & w (and signed int for 5).
As a consequence, the value of resize is computed as a signed int... havoc might happen when the signed bit (#31) is propagated to the #63 to #32 of size_t... vector does not enjoy a negative value for resize (and destroy itself: no iterator on coming soon call! hence the crash when the values in the vector are to be initialised)
30500²: (in hex)
1 15 3C 71 50 floats
4 54 F1 C5 40 bytes
Basic solution: promote the 5 to an unsigned long, forcing the computation to happen on unsigned long, avoiding promotion of silly sign-bit, and keeping the resize’s value as a good number.
aka: resize( w * h * 5) becomes resize ( w * h * 5ul )
This solution has been tested and seems fine (it’s just that in base/image/image.cpp, there is a lot of resize()!). For all resize(), the “ul” must be added. (and that means also that resize( w * h ) must be rewritten as ( w * h * 1ul ). )
|
|
163 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 38 | Very Low | Medium | no pigment warning | Closed | |
Future release |
Task Description
no warning is issued when an object/primitive has no pigment type given
|
|
161 | Image format | Definite Bug | 3.70 beta 38 | Very Low | Medium | error when writing jpg format (linux build) | Closed | |
3.70 release |
Task Description
There is a confirmed bug when writing jpg file format with the current linux build (beta39). when specifying +fj output format the following error occurs:
JPEG parameter struct mismatch: library thinks size is 372, caller expects 376 JPEG parameter struct mismatch: library thinks size is 372, caller expects 376 Render failed
this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32 bit version) as openSuSe 11.2 64-bit reports no problem
there has been a proposed fix to ~smp/source/base/image/jpeg.cpp that appears to work, however it requires some additional work to make it a platform (linux) and compiler (gcc) specific fix.
|
|
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.
|
|
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
|
|
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).
|
|
98 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Medium | Refactor Windows UI code for Unicode support | Tracked on GitHub | |
Future release |
Task Description
Windows UI code should be refactored to use _TCHAR throughout instead of char, as well as the corresponding string function macros, to head for Unicode support.
|
|
93 | Photons | Definite Bug | 3.70 beta 36 | Very Low | Medium | Photons are unnaturally amplified by pass_through objec ... | Closed | |
3.70 release |
Task Description
The following scene shows how photons are “boosted” by pass_through objects; removing one of the boxes will reduce the effect; the effect can be seen with 3.6 as well as current betas:
global_settings {
max_trace_level 10 // makes a difference!
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,500,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>
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
cylinder {
<-1.2,0.01,0.8>, <-1.2,2.5,0.8>, 1
material { M_Glass }
photons { // photon block for an object
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_Glass }
photons { pass_through }
}
box {
<2.9,0,-2.3>, <3.1,4,-0.3>
material { M_Glass }
photons { pass_through }
}
|
|
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”.
|
|
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.
|
|
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.
|
|
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
|
|
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.
|
|
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).
|
|
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.
|
|
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
|
|
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.
|
|
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>
}
}
|
|
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.
|
|
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)
|
|
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.
|
|
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}}
}
|