|
207 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Attempted to redefine float identifier as function ide ... | Closed | |
Future release |
Task Description
#macro A()
#local f = function { x }
#end
#local f = 1;
A()
This gives:
File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
function identifier.
The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.
For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:
#include "transforms.inc"
#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );
The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:
// Do NOT allow to redefine functions! [trf]
// #declare foo = function(x) { x }
// #declare foo = function(x) { foo(x) } // Error!
// Reason: Code like this would be unreadable but possible. Is it
// a recursive function or not? - It is not recursive because the
// foo in the second line refers to the first function, which is
// not logical. Further, recursion is not supported in POV-Ray 3.5
// anyway. However, allowing such code now would cause problems
// implementing recursive functions after POV-Ray 3.5!
In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.
|
|
214 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | Failed to parse command-line option in Debian | Closed | |
3.70 RC4 |
Task Description
I tried to use 3.7 RC3. This was my first time with 3.7.
I got source, configured and compiled it and installed into Debian with checkinstall. And then I tried to use it. First run was with -benchmark (it took about 9 minutes, ok). Then I tried very simple scene:
rekcahx@oah:~/pov$ povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Failed to parse command-line option
I tried to debug with strace:
rekcahx@oah:~/pov$ strace -o debug.strace povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (g++ 4.6.1 @ x86_64-unknown-linux-gnu) This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Primary POV-Ray 3.7 Architects/Developers: (Alphabetically)
Chris Cason Thorsten Froehlich Christoph Lipka
With Assistance From: (Alphabetically)
Nicolas Calimet James Holsenback Christoph Hormann Nathan Kopp
Juha Nieminen
Past Contributors: (Alphabetically)
Steve Anger Eric Barish Dieter Bayer David K. Buck
Nicolas Calimet Chris Cason Aaron A. Collins Chris Dailey
Steve Demlow Andreas Dilger Alexander Enzmann Dan Farmer
Thorsten Froehlich Mark Gordon James Holsenback Christoph Hormann
Mike Hough Chris Huff Kari Kivisalo Nathan Kopp
Lutz Kretzschmar Christoph Lipka Jochen Lippert Pascal Massimino
Jim McElhiney Douglas Muir Juha Nieminen Ron Parker
Bill Pulver Eduard Schwan Wlodzimierz Skiba Robert Skinner
Yvo Smellenbergh Zsolt Szalavari Scott Taylor Massimo Valentini
Timothy Wegner Drew Wells Chris Young
Other contributors are listed in the documentation.
Support libraries used by POV-Ray:
ZLib 1.2.3.4, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.44, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 62, Copyright 1998 Thomas G. Lane
LibTIFF 3.9.5, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.46, http://www.boost.org/
OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.
Parser Options
Input file: aa.pov
Remove bounds........On
Split unions.........Off
Library paths:
/usr/share/povray
/usr/share/povray/ini
/usr/share/povray/include
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....320 by 240 (rows 1 to 240, columns 1 to 320).
Output file..........aa.png, 24 bpp PNG
Dithering............Off
Graphic display......Off
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
[Parsing...]
Parse Warning: This scene did not contain a #version directive. Please be aware that as of POV-Ray 3.7, unless already specified via an INI option, a #version is expected as the first declaration in a scene file. POV-Ray may apply settings to some features that are intended to maintain compatibility with pre-3.7 scenes. You are strongly encouraged to add a #version statement to the scene to make your intent clear. Future versions of POV-Ray may make the presence of a #version statement mandatory.
Parser Statistics
Finite Objects: 1 Infinite Objects: 0 Light Sources: 1 Total: 2
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
—————————————————————————- Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........Off
[Rendering...]
Rendered 76800 of 76800 pixels (100%)
Render Statistics Image Resolution 320 x 240
Pixels: 76800 Samples: 0 Smpls/Pxl: 0.00 Rays: 76800 Saved: 0 Max Level: 1/5
Ray→Shape Intersection Tests Succeeded Percentage
Box 78226 1426 1.82
Shadow Ray Tests: 1426 Succeeded: 0
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 0 seconds (0.016 seconds)
using 4 thread(s) with 0.036 CPU-seconds total
POV-Ray finished
—
Every now and then all other command line options than –version, -version, -V, –help, -help -h, -?, –benchmark and –benchmark without leading strace in command line produces “Faild to parse command-line option” error.
My system: ebian GNU/Linux unstable (sid), quadcore AMD Phenom 2.6 GHz, 8GB ram. Povray: rekcahx@oah:~/pov$ povray –version povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. POV-Ray 3.7.0.RC3
This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 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.6.1
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
223 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Artifacts in thin torus | Closed | |
|
Task Description
Thin tori exhibit artifacts in 3.7.0 RC3 when the camera is placed inside the torus close to its “center plane”, as can be demonstrated with the following scene:
camera {
location <0.0, 0.0, -0.5>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
angle 1
}
light_source { <-30, 30, -30> color rgb 1 }
torus {
1, 0.001
texture { pigment { color red 1 } }
}
|
|
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
|
|
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
|
|
184 | Radiosity | Definite Bug | 3.70 RC1 | Very Low | Low | Too many pretrace steps when pretrace_start < pretrace_ ... | Closed | |
3.70 RC2 |
Task Description
If pretrace_start is set below pretrace_end, POV-Ray will run a high number of pretrace steps (without changing pretrace resolution).
|
|
186 | Geometric Primitives | Definite Bug | 3.70 RC1 | Very Low | Low | numeric precision problem with polygon start/end points | Closed | |
3.70 RC2 |
Task Description
polygon objects comprised of multiple “sub-polygons” don’t work properly if start/end points of sub-polygons do not exactly match, as can be demonstrated by the following code:
#default { texture { pigment { rgb 1 } finish { ambient 1.0} } }
camera {
orthographic
up 3.5*y
right 3.5*x*image_width/image_height
location <0,0,-4>
look_at <0,0,0>
}
polygon { 8,
// outer triangle
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.70 * < cos(360 *pi/180),sin(360 *pi/180),0>
// inner triangle
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.35 * < cos(360 *pi/180),sin(360 *pi/180),0>
}
Note that the end points /should/ be identical. There are however some minor rounding differences, which mess up polygon computations. Compare with the following code, which leads to the desired results:
polygon { 8,
// outer triangle
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
// inner triangle
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
}
Code inspection shows that the polygon insideness testing code tests for precise equality of the points, whereas the general policy of POV-Ray is to accept slight rounding differences.
|
|
188 | Texture/Material/Finish | Definite Bug | 3.70 RC1 | Low | High | no_reflection broken | Closed | |
3.70 RC2 |
Task Description
I rendered attached .pov file with both 3.62 and 3.7RC1, and got different output between them. In 3.7RC1, it looks like no_reflection option of the black sphere doesn’t work.
|
|
190 | Photons | Feature Request | 3.70 RC1 | Very Low | Low | photon message reporting | Closed | |
|
Task Description
couple of observations:
if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)
when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.
|
|
191 | Texture/Material/Finish | Definite Bug | 3.70 RC1 | Very Low | Low | Using interpolated image_maps in functions results in p ... | Closed | |
3.70 RC4 |
Task Description
Using interpolated image_maps in functions results in pixel-sized dot-artifacts when using the functions back into pigments.
This problem doesn’t shows using the same code on POV-Ray 3.6.
I qualified it as “low severity” because is not going to happen to most users: it will show only when using some advances techniques, for example when you want to decompose an image_map into the RGB components, perform operations, and mixing them back with an averaged pigment (example attached).
|
|
189 | Parser/SDL | Possible Bug | 3.70 RC1 | Very Low | Low | segmentation fault | Closed | |
|
Task Description
I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.
FYI: I did a build off the depot last evening.(21:13)
|
|
185 | Other | Definite Bug | 3.70 beta 41 | Very Low | Very Low | wrong message about image resolution | Closed | |
3.70 RC2 |
Task Description
‘povray -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays
Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)
instead of
Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)
or
Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10)
|
|
187 | Frontend | Feature Request | 3.70 beta 41 | Very Low | Low | POV-Ray 3.70 ignores SIGTSTP signal, noisy on SIGWINCH ... | Closed | |
3.70 RC2 |
Task Description
When POV-Ray 3.70 is run on a terminal, on an unix shell, and the user hits ctrl-Z to suspend (stop) POV-Ray, rather than stopping as expected, POV-Ray just reports that it did receive the signal, as if to laugh at the user “I’m not obeying your puny stop attempts”. It
The default action (as happens if the SIGTSTP signal is not trapped) would be much better, and is usually safe also in multithread programs. It takes actual effort to _ignore_ the TSTP signal (namely, to trap that signal), so the current behavior is definitely a dysfeature, probably an oversight by whoever programmed the signal handler.
Also, when the terminal window is resized, POV-Ray needlessly reports that it received a signal number so-and-so (the number of SIGWINCH), adding irrelevant noise to its terminal output. Both signals (SIGTSTP and SIGWINCH) should simply be excluded from the signal trapping mask. I guess there are also other signals that are needlessly captured. It would be better to capture only those signals that an action is needed for.
|
|
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.
|
|
183 | Texture/Material/Finish | Possible Bug | 3.70 beta 40 | Very Low | Low | cutaway_textures broken with child unions | Tracked on GitHub | |
Future release |
Task Description
When using cutaway_textures in a CSG object that has union children, results are not as expected; instead, surfaces in the union children that have no explicit texture will be rendered with the default texture instead. This is not the case for e.g. difference children.
Example:
#default { texture { pigment { rgb 1 } } }
camera {
right x*image_width/image_height
location <0,1.5,-4>
look_at <0,1,0>
}
light_source { <500,500,-500> color rgb 1 }
#declare U = union {
sphere { <0,-0.1,-1>, 0.3 }
sphere { <0, 0.1,-1>, 0.3 pigment { color red 1 } }
}
intersection {
sphere { <0,0,0>, 1 pigment { color green 1 } }
object { U }
cutaway_textures
rotate y*90
}
When declaring U as an intersection instead, the results are as expected, with the surface of the first sphere in U being rendered with the texture defined in the outer intersection.
|
|
179 | Runtime error | Definite Bug | 3.70 beta 40 | Very Low | High | unix version segfaults when $HOME not set | Closed | |
3.70 beta 41 |
Task Description
unixoptions.cpp has a getenv(”HOME”) that does an assignment without checking to see if getenv returns NULL.
This causes an immediate and unceremonious segfault in those situations where $HOME is not set such as in the case where povray is launched by a daemon.
Best solution might be to set the home to /tmp and print a warning message about $HOME not being set.
|
|
182 | Texture/Material/Finish | Definite Bug | 3.70 beta 40 | Low | High | multi-textured blobs in intersections / differences bro ... | Closed | |
3.70 beta 41 |
Task Description
Multi-textured blobs are broken with 3.7 beta 40 when used inside an intersection, as can be demonstrated by the following scene:
#default { texture { pigment { rgb 1 } } }
camera {
right x*image_width/image_height
location <0,1.5,-4>
look_at <0,1,0>
}
light_source { <500,500,-500> color rgb 1 }
difference { blob {
threshold 0.6
sphere { < 0.75, 0, 0>, 1, 1 texture { pigment { color red 1 } } }
sphere { <-0.375, 0.65, 0>, 1, 1 texture { pigment { color green 1 } } }
sphere { <-0.375, -0.65, 0>, 1, 1 }
} }
With POV-Ray 3.7.0 beta 40, the entire blob is rendered with the default texture.
The same problem can be seen with “difference” or “merge” instead of “intersection”.
Omitting the CSG “envelope”, using “union”, or assigning the blob to a variable first and then using it inside an intersection, will yield the expected result.
POV-Ray 3.62 renders all variants as expected.
According to initial analysis, the problem appears to be caused by the dual use of the “MULTITEXTURE_FLAG”, which is used in CSG to indicate use of the “cutaway_textures” feature, and in blobs to indicate per-element texturing. (The same flag is also used in meshes to indicate per-face or per-vertex texturing, so similar problems are to expected there.)
My proposal is to use an entirely separate flag for the “cutaway_textures” feature (the blob and mesh can safely continue to share the MULTITEXTURE_FLAG).
|
|
180 | Runtime error | Definite Bug | 3.70 beta 40 | Very Low | High | lseek64(fileno(fd), ...) is not the same as fseek64(fd, ... | Closed | |
3.70 RC1 |
Task Description
FileBackedPixelContainer uses a FILE* to manage the backing store and under Linux/Unix defines fseek64 to be a kind of incantation of lseek64.
Since fseek64 and fseek64 have return values that are logical opposites this causes an exception to be thrown.
Moreover since the buffer size on a FILE is quite a bit smaller than a line of pixels (in terms of bytes), mostly what’s being done in this function is a lot of sloshing of bytes that don’t do much... which is to say that the intended caching mechanism is getting a very low hit rate now that povray is working in 32×32 pixel per-thread chunks.
The cache miss problem and the volume of bytes read/written grows exponentially as the size of the image grows.
Attached is a replacement function that seems to be working well and should produce a performance increase even under Windows. I originally went with simply fixing the fseek/lseek problem but saw a 10% decrease in render time on 2048×1024-sized images when I made the cache target smaller.
|
|
172 | Image format | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Re-implement progressive image output | Tracked on GitHub | |
Future release |
Task Description
With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.
|
|
177 | Light source | Feature Request | 3.70 beta 39 | Very Low | Low | Add support for conserve_energy to shadow computations | Tracked on GitHub | |
|
Task Description
The following scene gives a comparison of current conserve_energy handling in standard shadow computations vs. photons.
Note how the rather highly reflective slabs fail to cast shadows, except where the photons target sphere enforces computation of shadow brightness to be done by the photons algorithm.
For more realistic shadowing without the need to enable photons, I suggest do add proper conserve_energy handling to the shadow computation code (which shouldn’t be too much effort).
global_settings {
max_trace_level 10
photons { spacing 0.003 media 10 }
}
camera {
right x*image_width/image_height
location <-2,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb 0.7 } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0
specular 0.2 // just to give a hint where the sphere is
}
}
interior { ior 1.0 }
}
#declare M_PseudoGlass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.5
specular 0.6
roughness 0.005
reflection { 0.3, 1.0 fresnel on }
conserve_energy
}
}
interior { ior 1.5 }
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
// behind target object
box {
<-0.2,0,-2.3>, <0.0,4,0.3>
material { M_PseudoGlass }
rotate z*1 // just to better see the reflection of the horizon
}
// before target object
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_PseudoGlass }
photons { pass_through }
rotate z*1 // just to better see the reflection of the horizon
}
|
|
178 | Texture/Material/Finish | Feature Request | 3.70 beta 39 | Very Low | Low | Modify metallic reflection code to better work with con... | Tracked on GitHub | |
|
Task Description
The combination of metallic reflection with conserve_energy causes the reflection to lose colour, as demonstrated by the following scene:
global_settings {
max_trace_level 10
}
camera {
right x*image_width/image_height
location <-2,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
}
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 0.7 } }
}
#declare M=
material {
texture {
pigment {rgbt <1.0,0.7,0.2,0.99>}
finish {
ambient 0.0
diffuse 0.5
specular 0.6
roughness 0.005
reflection { 0.8, 1.0 metallic }
conserve_energy
}
}
interior { ior 1.5 }
}
box {
<-0.2,0,-2.3>, <0.0,4,0.3>
material { M }
rotate z*5
rotate x*2
}
|
|
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.
|
|
170 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Reduce memory footprint of output image buffer | Closed | |
3.70 release |
Task Description
Currently, output image is buffered using POV-Ray’s RGBFT color model and floating point values, leading to a memory consumption of 20 bit per pixel. This is an unproportionally large memory footprint, given that the only further processing performed on the buffered data is conversion of the data to the desired output file format, which will typically use only 3 bytes per pixel (at most 12 bit per pixel).
The situation can be improved by choosing the output image buffer container based on the desired output file format and parameters. To this end, the following code changes should be made:
Bundle image file format handler code into classes (typically one per file format)
Include a method to determine the best data container type for the image buffer
Instantiate the desired image file format handler object prior to rendering, querying the handler object for an image buffer
In addition to picking a suitable image data container from the already existing palette, careful design might also allow to use custom containers to directly pass the data to a library (in case the library provides its own buffering anyway), or write it directly to the output file (e.g. when writing image data to stdout). To make this compatible with multithreaded rendering, the following changes would have to be made:
Add code to detect when a row of SMP blocks has been finished, and call a certain method on the image handler object
Design the custom containers in such a way that they can buffer any number of unfinished SMP block rows as needed
|
|
173 | Other | Feature Request | 3.70 beta 39 | Very Low | Low | Prevent POV-Ray for Windows from stealing focus | Closed | |
|
Task Description
In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.
I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.
|
|
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/
|
|
115 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | More cutaway_textures | Tracked on GitHub | |
Future release |
Task Description
Think this is still a problem. See the attached scene file. Find the WindowFrameSegment declaration for more info. The scene as-is shows the problem (SOME portions of the difference inherit the color of the room) the window opening is scaled larger to show that they AREN’T touching. The problem goes away when (in WindowFrameSegment) the 1st occurrence of the applied texture is commented out and the 2nd occurrence is uncommented, and cutaway_textures is commented out.
|
|
118 | Light source | Feature Request | 3.70 beta 37a | Very Low | Low | More efficient handling of fading lights | Tracked on GitHub | |
3.71 release |
Task Description
Currently, fading light sources are used for lighting and shadow calculations even when so far away as to no longer have any effect on the outcome. The proposed solution is to add a new keyword fade_cutoff_distance which tells povray to ignore the light source when alluminating a point at larger distance.
A sample implementation is provided in the attached files. These changes are still based on beta 34 as sources for the current beta are not yet available, and starting to merge changes to beta 35 only at this time didn’t seem worth the effort. Also, please disregard, changes in the CVS header comments (I also use CVS locally for managing source files).
Further considerations regarding this feature:
- For special effects this feature can also be used if the light source does not actually use fading. On the other hand, cutting the light at some distances can be considered an extreme form of fading which may justify the keyword name anyhow.
- Depending on how FS#46 is implemented, the test for cutoff may then be needed at another location as well.
- The default value currently is 0 (or *no* cutoff distance). For #version 3.7 of higher, the default could be chosen automatically based on the light source intensity and adc_bailout, although it may then need to be overriden by the user for extreme pigments.
|
|
127 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Expandable arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, arrays are of a fixed size. You can’t add or remove items to/from an array. I think it would like arrays to be expandable with no fixed and pre-determined size.
|
|
129 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | Hash arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
|
|
131 | Other | Feature Request | 3.70 beta 37a | Very Low | Low | Ability to change the order of editor tabs by dragging ... | Tracked on GitHub | |
Future release |
Task Description
See Notepad++ or EditPad Lite for examples.
It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.
|
|
133 | Geometric Primitives | Feature Request | 3.70 beta 37a | Defer | Very Low | Subdivision support | Tracked on GitHub | |
Future release |
Task Description
Someone built a version of Povray with internal support for automatic subdivision of meshes. See:
http://www.cise.ufl.edu/~xwu/Pov-Sub/
Would like to see this feature added natively to Povray.
|
|
138 | User interface | Feature Request | 3.70 beta 37a | Very Low | Low | "Rename" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great if there were a “Rename” option in the editor File menu to rename the current file name. Otherwise, you have to close the file, rename it in file manager, then open the file again, thus loosing the current tab position and undo history for the file.
|
|
140 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Reload" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.
|
|
142 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | camera_view pigment from MegaPOV | Tracked on GitHub | |
Future release |
Task Description
I probably don’t have to explain why the camera_view pigment in MegaPOV was important, but I will list some reasons anyway:
1) post-processing could be performed in-scene 2) new types of focal blur effects could be created 3) feedback fractals were possible
I’m sure there are many others, as this is one of those features that has undetermined potential!
|
|
145 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Stack trace report on error | Tracked on GitHub | |
|
Task Description
In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.
Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.
Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.
Not sure how much of this is achievable in Povray.
|
|
151 | Runtime error | Possible Bug | 3.70 beta 37a | Very Low | Low | No way to cancel save while parsing, never ending error... | Tracked on GitHub | |
|
Task Description
On Windows, when I try and save a file while it is being parsed prior to rendering, I get an error, “Failed to save file: The operation completed successfully”, with a single OK button to click. Despite the weird wording, I’m OK with that.
However after clicking OK I get the error, “Failed to save file ‘...’“, with three buttons: Cancel, Try Again, Continue. Not sure what “Continue” means in this context, given that the possibilities would seem to be covered by the other two buttons. Whatever.
Also, sometimes I get a message with only a single “Retry” button. Not sure what the exact message was.
Anyway, the real problem is that, regardless of which button I press, the program continues to spawning the same error message endlessly. Luckily there is a delay between them, but still it would be nice to have at least one of the three buttons *stop* POV-Ray from asking me again.
Also, once the program finishes parsing the file and it becomes possible once again to save the file, it does nothing. I.e. it doesn’t save the file. So what’s the point of the message and all the options? Why not just say, “Unable to save the file, file is parsing” and be done with it?
I think I recall the same behavior in 3.6.2, so it’s nothing new that’s been introduced.
|
|
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?
|
|
110 | Sample scenes | Definite Bug | 3.70 beta 37a | Very Low | Low | Sample Lathe Scenes no Longer work in 3.7 | Closed | |
3.70 beta 38 |
Task Description
The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.
<3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
Although it works in version 3.6, only in 3.7 does a render time error ocurr.
Scene source should be adjusted to the following
<3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
|
|
111 | Parser/SDL | Definite Bug | 3.70 beta 37a | Very Low | Low | Remove_Bounds=off / -UR does not work properly | Closed | |
3.70 beta 38 |
Task Description
Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.
|
|
112 | Image format | Definite Bug | 3.70 beta 37a | Very Low | Low | OpenEXR alpha is only written when it shouldn't be | Closed | |
3.70 beta 38 |
Task Description
OpenEXR output currently writes an alpha channel when Output_Alpha=off (-UA), and does not write an alpha channel when Output_Alpha=on (+UA), i.e. doing it just the wrong way round.
|
|
113 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Low | High | Multi-layered reflections broken | Closed | |
3.70 beta 38 |
Task Description
Reflections in multi-layered textures are broken in 3.7 betas, as can be demonstrated with the following scene showing two reflective hemispheres on a checkered plane:
camera {
location <1.0, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
default {
finish { diffuse 0 ambient 0 specular 0 }
}
// ----------------------------------------
plane { // checkered floor
y, -1
texture
{
pigment { checker color rgb 1 color blue 1 }
finish{ diffuse 0.8 ambient 0.1 }
}
}
// left hemisphere
intersection {
sphere { 0, 1 }
plane { x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 } }
}
}
// right hemisphere
intersection {
sphere { 0, 1 }
plane { -x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 1.0 } }
}
}
Note that the reflection parameters of the left, multi-layered hemisphere sum up to 1.0, i.e. the same value as used in the single layer in the right hemisphere.
The first attached file (test_3.6.2.png), rendered with POV-Ray 3.6.2, shows the expected output: Both hemispheres appear to have the same reflectivity.
The second attached file (test_3.7.0.beta37a.png), rendered with POV-Ray 3.7.0.beta.37a, shows a much brighter left (multi-layered) sphere.
As it turns out, in order to get the expected result with POV-Ray 3.7.0.beta.37a, the reflectivity of each layer must be divided by 3, 2 and 1, respectively (which obviously does not sum up to 1.0):
...
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 / 3 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 / 2 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 / 1 } }
}
...
|
|
114 | Preview | Definite Bug | 3.70 beta 37a | Very Low | Low | Mosaic Preview not displaying properly | Closed | |
|
Task Description
Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.
I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.
|
|
116 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Very Low | Low | assertion fails when using "filter all" with small-pale ... | Closed | |
3.70 beta 38 |
Task Description
When using “filter all VALUE” with an image_map using a 4-bit (16-color) paletted bmp image, debug builds of POV-Ray fail with an assertion.
According to code analysis, other paletted image formats with <256 palette entries are also likely to be affected; similar assertion fails can be expected when using the “filter INDEX, VALUE” feature on such files with an index exceeding the palette size. “transmit” shows the same flaws.
|
|
122 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #ELSEIF statement | Closed | |
3.70 beta 38 |
Task Description
Request an #ELSEIF statement in POV SDL.
|
|
137 | Include files | Feature Request | 3.70 beta 37a | Very Low | Low | atand function | Closed | |
3.70 beta 38 |
Task Description
There already exist atan, atan2 and atan2d functions, why not atand?
|