|
154 | Setup/Install | Possible Bug | 3.70 beta 37a | Very Low | Low | Installation on linux (unix ?) in $HOME/.povray/3.7 set ... | Closed | |
|
Task Description
Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.
Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.
Please fix ?
|
|
160 | Other | Feature Request | All | Very Low | Very Low | Parallel GPU processing support | Closed | |
|
Task Description
...for instance nVidia’s CUDA architecture, discussed here and other places.
General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.
|
|
164 | Other | Feature Request | 3.70 beta 38 | Very Low | Low | Date/time stamp on rendered images | Closed | |
|
Task Description
I’d like to request the ability to create a date/time stamp on output images so that new renders don’t always overwrite old ones. Thanks.
|
|
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 ). )
|
|
175 | Radiosity | Feature Request | 3.70 beta 39 | Very Low | Low | Radiosity. Emissive and scattering media don't illumina ... | Closed | |
|
Task Description
Tested with beta 40. Also affect version 3.6.1 as reported in the discution group.
When using radiosity and emissive media. Any object, or part of, that is inside the media container is not affected by the illumination comming from the media.
When using scattering media, the light scattered by the media also don’t affect objects that are inside it’s container.
http://news.povray.org/povray.newusers/thread/%3C4cf8fe22%241%40news.povray.org%3E/
|
|
176 | Other | Feature Request | Not applicable | Very Low | Low | Raise maxpower of the Poly Oject to 16. | Closed | |
|
Task Description
At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.
|
|
192 | Image format | Definite Bug | 3.6 | Very Low | High | png-1.5 breaks povray 3.6 | Closed | |
|
Task Description
Trying to build povray-3.6 against png-1.5 fails spectacularly.
.../include/png.h:666: error: forward declaration of ‘struct png_info_def’ png_pov.cpp:1405: error: invalid use of undefined type ‘struct png_info_def’
appears a lot in the output.
The problem is that png-1.5 hides structure members from public view.
Note, this is not the same problem as FS#144 .
|
|
211 | Image format | Feature Request | 3.70 RC3 | Very Low | Low | Fill blank space with pixels on quit rendering | Closed | |
|
Task Description
It would be nice when quitting a render if the remaining space were filled with empty pixels. That way the partial render will still be viewable in all image apps.
|
|
212 | User interface | Feature Request | 3.70 RC3 | Very Low | Low | Next beta: new desktop icon | Closed | |
|
Task Description
For the next beta version, could you please create a new desktop icon? I keep clicking on the wrong version.
|
|
217 | Other | Possible Bug | 3.70 RC3 | Very Low | High | raddem.ini with +C and some frames already done: failur ... | Closed | |
|
Task Description
How to do it: (with raddem.ini & raddem.pov from distributed scenes, copied in local directory)
1. run “povray raddem.ini” until frame 6 or more (irrelevant, at least frame 1 & 2 are needed), interrupt the render. 2. restart “povray raddem.ini +C”
It fails at frame 2 with Possible Parse Error: Cannot find file ‘raddem.pov’, even after trying to append file type extension. Parse Error: Cannot open input file. Fatal error in parser: Cannot parse input. Render failed
The detection of frame 1 is fine.
|
|
218 | Sample scenes | Definite Bug | 3.70 RC3 | Very Low | Critical | Benchmark must be updated to not reference a #local arr ... | Closed | |
|
Task Description
Lines 1217, 1241 and 1242 of benchmark.cpp must be change to use #declare instead of local for A and its elements. (because A is returned by the macro)
"#macro L_GetVN(ResSpl)\n"
" #local I = 0;\n"
" #declare A = array[ResSpl+1][2]\n" // <============== this is line 1217
" #while (I<=ResSpl)\n"
" #local P0 = 0+<FnA(I/ResSpl), I/ResSpl, 0>;\n"
" #if (P0.x=0 & P0.z=0)\n"
" #local P0 = <1e-25,P0.y,1e-25>;\n"
" #end\n"
" #if (I=0)\n"
" #local P1 = 0+<FnA(((I-0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #else\n"
" #local P1 = P2;\n"
" #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #end\n"
" #local P3 = vrotate(P0,<0,1,0>);\n"
" #local P4 = vrotate(P0,<0,-1,0>);\n"
" #local B1 = P4-P0;\n"
" #local B2 = P2-P0;\n"
" #local B3 = P3-P0;\n"
" #local B4 = P1-P0;\n"
" #local N1 = vcross(B1,B2);\n"
" #local N2 = vcross(B2,B3);\n"
" #local N3 = vcross(B3,B4);\n"
" #local N4 = vcross(B4,B1);\n"
" #local N = vnormalize((N1+N2+N3+N4)*-1);\n"
" #declare A[I][0] = P0;\n" // <============== this is line 1241
" #declare A[I][1] = N;\n"
" #local I = I+1;\n"
" #end\n"
" A\n"
"#end\n"
Same update should also be reported into the distributed scene benchmark.pov
|
|
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...
|
|
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.
|
|
231 | Image format | Feature Request | 3.70 RC3 | Very Low | Low | Number of digits in file name at an animation | Closed | |
|
Task Description
There is a long animation to render.
computer 1 should render 0..799 computer 2 should render 800..1599
And after this, You have a bad surprise with the filenames.
animation799.png animation0800.png
There should be a seting how many digits a file name in an animation should have.
This avoids, that there are series of pictures with 3 and other with 4 digit filenames.
BTW: All the experiences for this feature requests had been made during producing http://roland.pege.org/2011-gusi-peace-prize/calculation-error.htm
|
|
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
|
|
250 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | ini shell-outs always fail | Closed | |
|
Task Description
I’ve got an ini file that looks like this:
Post_Frame_Return=U Post_Frame_Command=notepad.exe
And when I render a scene using that ini file, it renders correctly but then gives me this error:
Render halted because the post-frame shell-out (’notepad.exe’) requested POV-Ray to generate a user abort. Render failed
.....and it doesn’t open notepad.
I’ve unchecked the “Disable Starting Other Programs” and I’ve tried various variations on what exe to run and whether to do it Pre/Post Frame/Scene, and nothing has worked.
|
|
253 | Backend | Possible Bug | 3.70 RC6 | Very Low | Low | Segmentation fault | Closed | |
|
Task Description
I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.
I’ve been dismissing them up until now wanted to speak up because I finally got this crash:
29623 Segmentation fault
Here’s some observed behaviors:
In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.
I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?
No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.
Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.
Any comments ... ideas ... suggestions?
|
|
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.
|
|
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.
|
|
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.
|
|
276 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Medium | SDL Access to Spline Derivatives | Closed | |
|
Task Description
I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.
In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.
I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)
Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).
|
|
277 | Other | Possible Bug | 3.70 RC7 | Very Low | Medium | Max Image Buffer Memory Does not Seem to Work | Closed | |
|
Task Description
In POV-Ray’s documentation it says:
3.2.2.2 Max Image Buffer Memory
This INI parameter sets the number of megabytes of RAM to allow for output image caching. If the output image happens to use more than this, a file backed temporary image is used instead.
I used this INI file option because the default value (128 megabytes) seemed insufficient. pov-state backend files were always created and they were remarkably larger than the resulting image (bmp) files. Consequently, I set
Max_Image_Buffer_Memory = 3096
in the INI file so that POV-Ray should, according to the documentation, now be able to use 3 gigabytes of RAM so no backend temporary file would be needed at all (this large they were never).
However, while POV-Ray was rendering I still discovered a pov-state file and it still had a similar size.
Now I am confused: did the INI option not work or have I misunderstood the documentation? If the former is the case, that would be a bug, wouldn’t it?
I tested both under Windows XP and Debian 6.0.5.
|
|
279 | Light source | Possible Bug | 3.70 RC7 | Very Low | Low | area_illumination causes artifacts when used with radio ... | Closed | |
|
Task Description
see my post titled: “area light and radiosity problem?” in povray.binary.images [Edit - copied that post’s text here - clipka]
wondering about what’s going on here with this series of images. the radiosity and area light settings are unchanged from image to image, and all I did was radiosity on/off and area_light on/off (btw: using rad_def “Normal” settings)
the 1st image is radiosity only, the 2nd is area light only, and the 3rd combines them:
what’s up with blotches? change #5819/5820 (octree) or maybe something still with area lights?
|
|
280 | Editor | Possible Bug | 3.70 RC7 | Very Low | Medium | editor issue | Closed | |
|
Task Description
The following editor issue experienced in 3.7 RC 6 under Win7/64::
Place the curser at the middle of a row. Press enter. Now the line has been split and the cursor is at the beginning of the new line, followed by the rest of the original line Press backspace. Instead of restoring the original line, the second part of the line disappears.
RC 3 under Vista/32 (and earlier versions) behave normally.
|
|
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.
|
|
285 | Documentation | Definite Bug | Not applicable | Very Low | High | wiki.povray.org is not editable | Closed | |
|
Task Description
I cannot edit any pages on wiki.povray.org, even after confirming my e-mail address.
This means that I cannot add any documentation, help improve the documentation, fix errors or help in any other way.
If you want contributions to the documentation, you should let users edit pages.
|
|
290 | Documentation | Possible Bug | 3.70 RC7 | Very Low | Medium | Windows. Editor context menu opens folder instead of ad ... | Closed | |
|
Task Description
This is an annoying little bug in the Windows GUI:
Installed 3.7 RC07 on Windows 8. No previous povray installation on this machine.
How to reproduce error :
- Open a file in the editor.
- Right click on the files tab. This opens a popup menu showing “Open containing folder/Copy file to clipboard/....”.
-Now each selection in this menu does open the containing Folder. I cannot close or run any of the other actions in this menu.
|
|
291 | Include files | Possible Bug | 3.70 RC7 | Very Low | Low | Math.inc: error in VDist function | Closed | |
|
Task Description
Included math.inc into scene and recieved this fatal error from povray:
File '/usr/local/share/povray-3.7/include/math.inc' line 248: Parse Error: Expected 'string expression', float function 'vlength' found instead
Appropriate place in math.inc:
245 > #end
246 >
247 > // Distance between V1 and V2
248 > #macro VDist(V1, V2) vlength(V1 - V2) #end
249 >
250 > // Returns a vector perpendicular to V
Running newly-downloaded/newly-compiled POV-Ray 3.7.0, on Linux x86_64 system
|
|
297 | Other | Feature Request | 3.70 RC7 | Very Low | Low | Have a user-definable epsilon | Closed | |
|
Task Description
There are times when scaling an entire scene up or down is difficult or just not feasible.
One suggestion is a global_settings option.
Also, I’ve noticed that in some situations, such as interactions between certain transparent objects, the epsilon seems to kick in quite early. Perhaps there could be situational or contextual epsilons, such as the “tolerance” of sphere_sweep or the “accuracy” of isosurface.
|
|
312 | Other | Possible Bug | 3.70 release | Very Low | Low | Rendering stuck at 99% | Closed | |
|
Task Description
After a long parse period and a relatively quick rendering, POVray gets stuck at 99% when rendering the attached file.
Rendered at 6144x3072px with antialiasing set to 0.3.
Can anyone confirm?
|
|
322 | Configure/Build | Definite Bug | 3.70 release | Very Low | Medium | ubuntu 14.04, boost 1.54, can not configure | Closed | |
|
Task Description
can not run POV-Ray on ubuntu 14.04, boost 1.54,
./configure COMPILED_BY=”Dmitry <my>”
...
Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for boostlib >= 1.37... yes
checking whether the Boost::Thread library is available... yes
checking whether the boost thread library is usable... no
configure: error: in `/home/di/workspace2/povray-3.7-stable':
configure: error: cannot link with the boost thread library
log in attach file
|
|
325 | Subsurface Scattering | Possible Bug | 3.70 release | Very Low | Medium | SSLT Glow issue with radiosity | Closed | |
|
Task Description
Hi,
I think I may have found a bug in the subsurface/radiosity features of Povray 3.7 attached image showing the issue and sample files required to reproduce. The original files (on povray forum images thread) had different radiosity settings but these ones show the problem and only take a few seconds to render the image without AA so probably better for bug fixing/testing etc.
Thanks
Sean
|
|
329 | Documentation | Possible Bug | 3.70 release | Very Low | Low | Mesh_camera type 0 output seems | 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.
|
|
332 | User interface | Feature Request | 3.70 release | Very Low | Low | Progress animation in taskbar tabs | Closed | |
|
Task Description
On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.
Here is an example of Chrome downloading something and showing the progress in the taskbar:
http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg
Here is an example with Paint.NET instead:
http://www.getpaint.net/images/pdn351_superbarProgress.png
I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.
|