|
260 | Configure/Build | Compatibility Issue | 3.70 RC6 | Very Low | Low | Patch to let POV-Ray builds with boost >=1.50 | Closed | |
|
Task Description
Originally resolved in https://bugs.gentoo.org/show_bug.cgi?id=425450. Attached is a patch with Gentoo-specific code removed.
There are two parts in this issue:
The newer boost library requires downstream users to explicitly link to the boost system library (-lboost_system).
The newer boost library replaced TIME_UTC with TIME_UTC_, because glibc added TIME_UTC.
|
|
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.
|
|
204 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Low | -V is not Verbose=off on Unix | Closed | |
3.70 RC4 |
Task Description
In vfe/unix/unixoptions.cpp, -V is defined as a synonym for --version, overriding its general meaning of Verbose=off.
|
|
224 | Editor | Compatibility Issue | 3.70 RC3 | Very Low | Low | Keyword Completion does not work for several names | Closed | |
3.70 release |
Task Description
Keyword Completion does not work for several names. I miss it for animation related names like frame_number or final_frame.
Typing “fram{TAB}” just inserts a TAB character after “fram” instead of completing it to frame_number.
Independently of that bug, typing {TAB} repeatedly does not cycle through possible names: “fr{TAB}” gives “frequency” and “fresnel” and that’s all.
In version 3.6 it worked well.
My system is Windows 7 64bit and PovRay is 3.7.0.RC3.msvc9.win64
|
|
109 | Other | Compatibility Issue | 3.70 beta 37a | Defer | Very Low | Debug_File No Longer Appends Frame by Frame Debug Data | Closed | |
Future release |
Task Description
The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a. In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.
In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.
This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.
Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.
Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.
|
|
120 | Documentation | Compatibility Issue | 3.70 beta 37a | Very Low | Very Low | More library paths, wildcards | Closed | |
3.70 release |
Task Description
20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.
|
|
141 | Documentation | Compatibility Issue | 3.70 beta 37a | Very Low | Low | Document changed behavior processing INI files | Closed | |
3.70 release |
Task Description
The documentation assumes that INI files (as well as the command line!) are parsed and processed instantly. This no longer holds true for POV-Ray 3.7, where parsing INI files (and the command line) and processing it are separate operations that occur at different times. As such, one consequence is that INI file options only take effect after reading the whole INI file, and possibly later.
As such, documentation statements such as <http://www.povray.org/documentation/view/3.6.1/222/> “Note: that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read will not be affected.”
Are no longer correct. It needs to be explained that options only take effect after the INI file has been read. An error in the INi file causes other options _not_ to take effect because reading of the INi file is aborted prematurely.
|
|
150 | Frontend | Compatibility Issue | 3.70 beta 37a | Very Low | Low | Windows file association problems (Win7 only??) | Closed | |
|
Task Description
Windows allows you to associate programs with file extensions using the “Open with” file manager right-click menu extension.
I’m running Windows 7 64bit, and installed the 64 bit versions of 3.6.2 and the beta appropriately.
A couple of problems that I haven’t tested very thoroughly:
1. If you have both POV 3.6.2 and the beta installed at the same time, you can no longer using this dialog change the association to the beta once it has been created for 3.6.2. There’s no error or anything; it just opens the file inside 3.6.2 instead. Maybe because both versions appear as “POV-Ray for Windows” to this dialog? Would adding the version number to the name fix things? Anything I can do on my end of things to resolve this?
2. In POV-Ray 3.6.2, I can use this dialog to open *.inc, *.txt and other files in POV-Ray, but only if POV-Ray isn’t already running. If POV-Ray is already running I get an “Only /EDIT and /RENDER may be passed to previous instance” error. Files with the *.pov extension open properly regardless, without any error. I am unable to test this in the beta at the moment due to the first problem unfortunately. Could someone please test this with the beta and confirm whether the behavior also exists?
3. With the POV-Ray 3.7 beta, entering the following command in the command prompt results in the same error:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
If I change it to the following it works however:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" /EDIT "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
Is this error/behavior really necessary? Would it be OK to instead change the behavior when the /EDIT flag is omitted in the command-line such that the file is opened in the editor by default, without throwing an error?
|
|
69 | Other | Compatibility Issue | Not applicable | Very Low | Low | #version fails to raise error | Closed | |
|
Task Description
Scenes starting with the incorrect syntax
version 3.7;
do not raise an error, instead they render a black screen with an empty scene warning. #version should fail with an error when the # is missing.
|
|
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.
|
|
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.
|
|
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.
|
|
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)
|
|
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.
|
|
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).
|
|
220 | Other | Compatibility Issue | 3.6 | Very Low | High | Error number -43 | Closed | |
|
Task Description
REcently I installed POV-Ray tracing software in my mac OS X version 10.6.8. When I run the software its displaying a fatal error occured and the error number is -43. I’m new to POV-Ray...pls help me guys...
|
|
274 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | Low | light source fading doesn't work properly with area_ill ... | Closed | |
3.70 release |
Task Description
When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:
#version 3.7;
global_settings {
assumed_gamma 1.0
mm_per_unit 10
subsurface { samples 200,20 }
}
camera {
right x*image_width/image_height
angle 30
location <0,1.5,-4>
look_at <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>]
}
}
}
plane {
y, 0
texture {
pigment {
checker
color rgb <1.0, 0.8, 0.6>
color rgb <1.0, 0.0, 0.0>
scale 0.5
}
}
}
light_source {
<50,50,50>
color rgb 30
area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
area_illumination on
fade_distance 10
fade_power 2
}
cylinder {
<0,0,0>, <0,0.2,0> 1
texture {
pigment { color rgb 1 }
finish {
ambient 0
diffuse 0.7
specular albedo 0.3
reflection { 0.3 fresnel }
conserve_energy
subsurface { translucency 0.1 }
}
}
interior { ior 1.5 }
}
sphere {
<0,0.4,0>, 0.2
texture {
pigment { color rgb <1,0.6,0.0> }
finish {
ambient 0
diffuse 0.0
specular albedo 0.8 metallic
reflection { 1.0 metallic }
conserve_energy
}
}
}
|
|
275 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | circular area lights exhibit anisotropy | Tracked on GitHub | |
Future release |
Task Description
circular area lights exhibit some anisotropy, being brighter along the diagonals than on average, as can be demonstrated with the following scene:
//+w800 +h800
#version 3.7;
global_settings{assumed_gamma 1}
plane{-z,-10 pigment{rgb 1} finish{ambient 0 brilliance 0}}
disc{0,z,10000,0.5}
camera{orthographic location z look_at 10*z up y*12 right x*12}
light_source{-10*z rgb 10 area_light 10*x 10*y 257 257 adaptive 4 circular}
|
|
283 | Other | Definite Bug | 3.70 RC7 | Very Low | High | Transparent or semi-transparent background color comes ... | Closed | |
|
Task Description
When using the ‘background’ directive with a transparent color, for example:
background { color rgbt <0, 0, 0, 1> }
the final image is still opaque (both the one displayed in the render window and the PNG actually saved to disk).
Expected behaviour is for it to be transparent.
|
|
284 | Documentation | Definite Bug | 3.70 RC7 | Very Low | Low | Add to documentation of "background" command a referenc ... | Closed | |
|
Task Description
Currently neither of these pages:
http://www.povray.org/documentation/view/3.7.0/253/
http://www.povray.org/documentation/view/3.7.0/90/
mention that the background can be transparent. Any normal user will try to give “background { ... }” a transparent color, see that it doesn’t work, and assume that POV-ray can’t do it.
The pages should mention the +UA command-line option, which enables the transparency.
|
|
287 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | area_illumination shadow calculation | Tracked on GitHub | |
Future release |
Task Description
not sure if this is something needing further work or an intended effect.
Shadows from and area light with area_illumination on seem to follow the same shadow calculation as a standard area light by giving more weight to lights near the center of the array. I would assume the shadows would be calculated similarly to individual lights in the same pattern as the array by evenly distributing the amount of shadow equally for each light. But this is not what I see.
The code sample below when rendered with scene 1 will show shadows grouped near the center from the area light with area_illumination. If scene 1 is commented out and scene 2 is uncommented then rendered, you will see evenly distributed shadows from individual lights. Area lighting with area_illumination I would assume should give a result identical to scene 2. If scene 1 is rendered with area_illumination off, the shadow calculation is exactly the same as with area_illumination on.
example images rendered on win32 XP
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb .7 } }
torus { 1.5,.1 rotate 90*x translate 4*z pigment { rgb .2 } }
plane { -z,-7 pigment { rgb .7 } }
/*
// scene 1
light_source{
y
1
area_light 3*x, z, 7, 1
area_illumination on
}
union {
sphere { 0,.05 }
sphere { .5*x,.05 }
sphere { x,.05 }
sphere { 1.5*x,.05 }
sphere { -.5*x,.05 }
sphere { -x,.05 }
sphere { -1.5*x,.05 }
translate y
hollow pigment { rgbt 1 } interior { media { emission 10 } }
}
// end scene 1
*/
// scene 2
#declare Light = light_source {
0
1/7
looks_like { sphere { 0,.05 hollow pigment { rgbt 1 } interior { media { emission 10 } } } }
}
union {
object { Light }
object { Light translate .5*x }
object { Light translate x }
object { Light translate 1.5*x }
object { Light translate -.5*x }
object { Light translate -x }
object { Light translate -1.5*x }
translate y
}
// end scene 2
|
|
294 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | High | Thread safety issue in functions using splines. 3.7.0.R ... | Closed | |
3.70 release |
Task Description
Thread safety issue in functions using splines. 3.7.0.RC7.
First vetting in p.bugreports where several users were able to reproduce the fail on the following systems:
1) Ubuntu 12.1 i7 920 using 3.7.0.RC7 2) Ubuntu 12.04, AMD 2431 CPU, Linux 3.2.0-45 kernel using 3.7.0.RC7 (g++ 4.6 @x86_64-unknown-linux-gnu) 3) POV-Ray 3.7.0.RC7 (icpc 13.1.0 @x86_64-unknown-linux-gnu)
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
uname -or
2.6.32-279.14.1.el6.x86_64 GNU/Linux
lsb_release -irc
Distributor ID: CentOS
Release: 6.3
Codename: Final
4) Confirmed with openSUSE 12.2. 5) Just to add to the system list: with Windows and a core i7 one yields the same result. 6) “Le_Forgeron” ran under Intel Inspector (XE 2013) and provided this feedback :
...
that might be less than 60 seconds, but with Intel Inspector (XE 2013),
it becomes 42:50 (just 14 data races, oh well, that's just so friendly).
ID Type Sources Modules State
P1 Data race isosurf.cpp; mutex.hpp povray New
P2 Data race mutex.hpp; povms.cpp povray New
P3 Data race povray.cpp povray New
P4 Data race povray.cpp povray New
P5 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P6 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P7 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P8 Data race recursive_mutex.hpp; scene.cpp; task.cpp; taskqueue.cpp;
view.cpp povray New
P9 Data race condition_variable.hpp; vfe.cpp; vfesession.cpp povray New
P10 Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
povray New
P11 Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
povray New
P12 Data race unixconsole.cpp; vfesession.cpp; vfesession.h povray New
P13 Data race unixconsole.cpp; vfesession.cpp povray New
P14 Data race [Unknown]; unixconsole.cpp; vfesession.cpp
libboost_thread.so.1.49.0; povray New
Numbers 2, 3, 4, 8, 9, 10, 11, 12, 13 & 14 are related to the handling
of session (and occur once or twice only, excepted #8, four times).
Number 1 is about isosurface (adjusting gradient at isosurf.cpp:1099 vs
1098 (testing its value), and copying the isosurface) (IMHO, rendering
threads updating the object... not the best move without some
atomic/protection (and not sure a DBL is/can be atomic)) (occurs 2505
times).
Number 5, 6 and 7 are about splines
* sp->Cache_Type & Cache_Point, splines.cpp :803 vs :814/815 (2024 times)
* sp->Cache_Valid, :805 vs :813 vs :904 (1770 times)
* sp->Cache_Data, :807 vs :903 (5025 times)
Only my 0.02¢ (yes, very cheap), but it seems to confirm
For test code see attached files or SplineThreadSafety.pov attachment to p.bugreports and images were posted to p.b.images.
Issue shows up any time more than one thread is used. Use of AA tends to hide the problem so do not use it if using the output image for testing.
Thanks. Bill P.
|
|
295 | User interface | Definite Bug | 3.70 RC7 | Very Low | Low | Minor GUI Bugs | Tracked on GitHub | |
|
Task Description
Here are two low-priority bugs in POV-Ray’s GUI, observed by me under Windows XP, which should be easy to fix I think:
In the “Insert” menu, there are sub-menus (e.g. “Radiosity and Photons”) in which there are menu seperators at the end of the popped-up menu bar.
The progress bar in the top-right corner of the editor window seems to be too large for the window (203px) and therefore clipped. As a result, progress seems to be 100% when it is not yet, e.g. at 90% progress. (Have not measured exactly.)
Both bugs are not severe at all, but it would be nice if they could be fixed. By the way, a second progress bar could be added to visualize the number of frames already rendered in an animation.
|
|
296 | Geometric Primitives | Definite Bug | 3.70 RC7 | Defer | Medium | max gradient computation is not thread safe (isosurface... | Tracked on GitHub | |
3.71 release |
Task Description
It appears as a side effect of investigation of #294: the code in isosurf.cpp, inside bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)
if(gradient < temp)
gradient = temp;
is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)
It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)
|
|
298 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Low | the warning for isosurface does not appears as often as ... | Closed | |
|
Task Description
From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)
William F Pokorny anonymous@anonymous.org wrote: > It seems to be the case the gradient warnings are only generated if the > isosurface is naked. If it is wrapped in an object as was the case with > my thread safety example, we get no warnings.
Confirmed. If only I still had the concentration required to investigate computer code.
#version 3.7;
#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end
global_settings
{ assumed_gamma 1
radiosity {} //force isosurface calculations from all directions
}
light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }
camera
{ location <0.0000, 1.0000, -5.6713>
look_at <-0.7969, 1.2000, -0.0598>
angle 10.7447
}
#include "functions.inc"
#if (Naked)
isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
#else
#declare Test = isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
object { Test }
#end
On the command line, try:
declare=MG=1 declare=Naked=1
and
declare=MG=1 declare=Naked=0
To lose the warning, I had to declare the isosurface. Just wrapping the naked isosurface in an object{} generated a warning.
Further analysis
isCopy seems to be intended to avoid displaying the same warning over and over for the same isosurface (as duplicated isosurface indeed are not copied but reference the same sub-structure).
#declare Ob = isosurface{...}; that’s not a copy object {Ob ... } that’s a copy
Previously (3.6.1) the warning was displayed at the destruction of the isosurface (when the sub-structure was actually referenced by no one else)
if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))
In 3.7, isCopy was introduced with change 4707, 16th February 2009, along with the change introducing means for objects to submit message on shutdown. It was reported in windows source with change 4714, 21th February 2009.
If the symptom “isosurface embbeded in object (CSG) does not show the warning” is correct, it might be a “feature/bug”. The parser copied the isosurface object and deleted the original before the render started. When the render ends, it find only copies and because the refcnt is not used anymore (for that purpose), it miss the last remaining true data to display.
Instead of isCopy, what about adding in mginfo a boolean “printed_warning” (actual name should be more appropriate), set to false on creation, and turn to true on the first call (instead of last for 3.6.1) of the warning displaying function (test for false, set to true if false) ? (and dropping isCopy in the process)
For instance, i’m afraid the following sequence would fails with current code:
#declare Foo = isosurface{ ... }; #declare Bar = object { Foo ... }; #undef Foo;
(or any pop of #local context, such as building the isosurface via macro or loop, or replacing the value of a previous #declare/#local )
|
|
301 | Other | Definite Bug | 3.70 RC7 | Very Low | Low | Fallback to default image size causes wrong values to b... | Tracked on GitHub | |
|
Task Description
When resolution is not specified (neither via POVRAY.INI nor via QUICKRES.INI nor via command line or custom .ini file), random values are displayed for image resolution in the Image Output Options message output. (The actual render will be performed at the default size of 160×120 pixels though.)
|
|
303 | Other | Definite Bug | 3.70 RC7 | Defer | Very Low | wrong bit depth reported for OpenEXR file format | Tracked on GitHub | |
|
Task Description
When using OpenEXR output file format, POV-Ray erroneously reports it as “24 bpp EXR” in the message output, while in fact it generates a 3×16 = 48 bpp file.
|
|
304 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | #for-loop may fail to perform last iteration | Closed | |
3.70 release |
Task Description
Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:
#declare N = 2000000; #debug concat(”N = “,str(N, 0,50),”\n”) #debug concat(”N-5 = “,str(N-5,0,50),”\n\n”) #for (I, N-5, N, 1)
#debug concat("I = ",str(I,0,50),"\n")
#end
(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)
As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.
The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:
if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
((Step < 0) && (*CurrentPtr <= End - EPSILON)) )
which should instead be:
if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
((Step < 0) && (*CurrentPtr < End - EPSILON)) )
|
|
306 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | High | finish subsurface block before global_settings subsurfa... | Tracked on GitHub | |
3.71 release |
Task Description
The following scene causes a crash:
sphere {
<0,0,0>, 1
finish { subsurface { translucency 1.0 } }
}
global_settings {
subsurface { }
}
|
|
307 | Image format | Definite Bug | 3.70 RC7 | Very Low | Low | netpbm, ppm, read bug where first data byte CR char | Closed | |
|
Task Description
I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.
Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.
The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.
The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.
I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.
The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.
Thanks for your time. Bill P.
|
|
308 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Medium | Heightfield computation from color (not palette) red/gr ... | Closed | |
|
Task Description
Due to a recent thread in povray.general (7th September 2013), I dive into the code of height field creation.
There is 2 TODO in source/backend/support/imageutil.cpp, for image_height_at() (circa line 512)
The first one is about using the index of palette-image: As far as *257 would indeed perform a better job to cover the full range than *256, it would break backward compatibility with previous versions of povray (3.6 included) which only promoted the index as the Most significant byte, keeping the least one at 0.
But on the second one, the new formula is plain wrong: (r*255+g)*255 should be (r*256+g)*255. In previous versions, r*255 was the Most significant byte, and g*255 was the least one. Ergo, the value was r*255*256 + g*255, which can and should be only factored as (r*256+g)*255;
I know it is damn late in the release schedule, but can that be either be fixed before final official delivery or a memo added to the release note that it would be fixed later and backward-bug will not be maintained for that specific point (using rgb-8 or less bit per channel-image for height field)
(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit of 3.7 that would should that bug)
If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top. With 3.6, it matched exactly (hence the noise on the top pixels row) the view. With 3.7, it cannot reach the top and leave a white area (another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)
If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov
The white line at the bottom is expected, as the minimal value of the height field is “full green”
|
|
309 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | Warning Message Missing | Tracked on GitHub | |
3.71 release |
Task Description
Draw_Vistas, Light_Buffer, and Vista_Buffer (plus associated switches) do not issue warning when used, even tho code has been disabled.
|
|
249 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | UTF-8 files with BOM not accepted | Closed | |
3.70 RC7 |
Task Description
POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.
According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.
|
|
252 | Photons | Definite Bug | 3.70 RC6 | Very Low | Low | photons and light_group is broken | Tracked on GitHub | |
|
Task Description
photons are not working when used with a light_group. verified in NG posting in p.general a simple scene file is attached.
|
|
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.
|
|
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.
|
|
257 | Other | Definite Bug | 3.70 RC6 | Very Low | Low | POV-Ray cannot find input file when resuming to render ... | Closed | |
3.70 RC7 |
Task Description
How to reproduce:
# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png
What happens:
==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed
OS: Gentoo AMD64 unstable POV-Ray version: 3.7.0 rc5
|
|
258 | Editor | Definite Bug | 3.70 RC6 | Very Low | Low | backspace problem at start of line | Closed | |
3.70 RC7 |
Task Description
Using POV-Ray 3.7 RC6 64bit for Windows I have problems in the POV-Ray editor with ‘backspace’:
When using backspace at start of line it does not only kill the return/line feed, but also everything of the line what’s beneath the upper line.
Sample: (here ‘|’ is used for the current cursor position!)
//--------------------------------------
texture { pigment{ Red }
| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
hitting backspace results in:
//--------------------------------------
texture { pigment{ Red }| 0.5 scale 0.1 }
//--------------------------------------
and not as expected:
//--------------------------------------
texture { pigment{ Red }| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
With 3.6.2 and with RC3 (latest old beta I found on my computers) this was no problem!
I already reported this on 17-Sept-2012 at http://news.povray.org/povray.beta-test/thread/%3C5056f452%241%40news.povray.org%3E/
|
|
259 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | Stack Overflow with the write-directive with missing cl ... | Closed | |
|
Task Description
As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.
With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.
I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.
Best regards, Michael
|
|
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.
|
|
262 | Setup/Install | Definite Bug | 3.70 RC6 | Very Low | Low | sources are being compiled twice on Linux | Closed | |
3.70 release |
Task Description
When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe
-I../../vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp
This is especially annoying on platforms that are rather slow at compiling.
|
|
266 | Frontend | Definite Bug | 3.70 RC6 | Very Low | Low | command line options in ini files don't accept quoted s ... | Closed | |
3.70 RC7 |
Task Description
Quoted strings as parameters to command-line options work on the command line but not in INI files; e.g.:
+i"test.pov"
Root cause has already been identified (actually the problem was found during code inspection) and a fix is under way.
|
|
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”.
|
|
268 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | "naked" pigment statement does not properly override pr ... | Closed | |
|
Task Description
A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
pigment { checker color red 1 color blue 1 scale 1.0 }
}
the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
texture {
pigment { checker color red 1 color blue 1 scale 1.0 }
} }
which behaves as expected.
The issue has been around at least since POV-Ray 3.6.2.
|
|
271 | Texture/Material/Finish | Definite Bug | 3.70 RC6 | Defer | Low | filter affects object's own brightness in an improper w ... | Closed | |
3.70 release |
Task Description
The following scene has four spheres with different pigment color & filter settings:
- Left: filter 1 - Right: filter 0
- Top: red 0.0 green 0.5 blue 1.0 - Bottom: red 0.00 green 0.05 blue 0.10 (10% of the above)
Background is set to black, so that we only see the diffuse component of the object’s effective color.
Theoretically, both left spheres should be invisible, as they are fully transmissive (with a filtering effect), but apparently with a high filter setting, reducing an object’s pigment color actually increases the object’s effective diffuse color.
//+w600 +h600
global_settings{ assumed_gamma 1.0 }
camera {
orthographic
location <0,0,-10>
right 4*x
up 4*y
look_at <0,0,0>
}
light_source{<10,10,-10> color rgb 1 parallel }
background { color rgb 0 }
default {
finish {
ambient 0
diffuse 1
specular 0
phong 0
reflection { 0.0 }
}
}
sphere { <-1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 1.0 } } }
sphere { < 1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 0.0 } } }
sphere { <-1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 1.0 } } }
sphere { < 1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 0.0 } } }
This bug has been around in 3.6 already.
|
|
273 | Other | Definite Bug | 3.70 RC6 | Very Low | Medium | No automatic backup files from inc files | Tracked on GitHub | |
|
Task Description
If enabled, POVray always created backups of pov and inc files once per session. Now using 3.7 RC6 only pov file backups are created but not from inc files.
|
|
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!)
|
|
241 | Photons | Definite Bug | 3.70 RC4 | Very Low | Low | Photons not working correctly | Closed | |
3.70 RC6 |
Task Description
~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.
|
|
194 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | command line parse error | Closed | |
3.70 RC4 |
Task Description
povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.
|
|
196 | Subsurface Scattering | Definite Bug | 3.70 RC3 | Very Low | Low | More SSLT Caveats | Tracked on GitHub | |
Future release |
Task Description
when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.
|