|
206 | Other | Possible Bug | 3.70 RC3 | Very Low | Low | "Cannot open file" error when text output files specifi... | Tracked on GitHub | |
3.71 release |
Task Description
I created an INI file which specifies the Input_File_Name, Output_File_Name, and also the Render_File and the remaining four text outputs as double-quoted absolute paths on my disk. When I run the render, I get the following output:
Preset INI file is ‘C:\USERS\TPREAL\DOCUMENTS\POV-RAY\V3.7\INI\QUICKRES.INI’, section is ‘[512×384, No AA]’. Preset source file is ‘D:\Ruby\POV-Rb\ini\20110521_004037_Noix.ini’. Rendering with 2 threads. - Cannot open file. Render failed - CPU time used: kernel 0.06 seconds, user 0.02 seconds, total 0.08 seconds. Elapsed time 0.52 seconds.
And the render does not start. The five text output files are not even created, and where the output image should be, there is a file with extension pov-state. The render works as it should only when I remove all five lines defining the five text output files. The paths I specify for the files are correct (paths exist and files do not, no white-spaces or anything), read/write restrictions are disabled in POV-Ray. This used to work in 3.6 and does not work now in 3.7 RC3. The error happens no matter if I run the render using GUI or command line.
(Also please note that the error message is really not useful here, it does not say which file it failed to open, and not even if it was an attempt to open for read or for write.)
I’d be really glad if you could correct this as it’s a critical functionality for me. I’m generating the POV-Ray code automatically and I need to parse the text output automatically to return the status to the generator.
|
|
202 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Numerical oddities in Julia_Fractal | Tracked on GitHub | |
|
Task Description
I understand that some things have changed in the way certain computations in POV-Ray decide when something is “good enough” and I think this is biting me in Julia_Fractal (where, of course, the highest-resolution computations are needed).
The bug has been posted here:
http://news.povray.org/povray.bugreports/thread/%3Cweb.4dbf2e26b56a53c15b4449250%40news.povray.org%3E/
Including a short .pov file and instructions that reproduce it.
(It pops up in other configurations and view angles as well, but this one captures in in a way that makes it clear it’s a bug: the distance of the camera from the origin appears to change the shape of the rendered object).
This appeared first on a Windows Server 2003 machine, it is apparently confirmable on at least one other system as per that thread.
|
|
205 | Documentation | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Low | Syntax documentation uses inconsistent notation | Tracked on GitHub | |
|
Task Description
The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.
|
|
222 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | incorrect render of CSG merge with radiosity | Tracked on GitHub | |
Future release |
Task Description
The problem arises when I am trying to trace a radiosity scene without conventional lighting that has a GSG merge object. There are a coincident surfaces, but these surfaces are first merged, then the texture applied. The texture is a simple solig color non-transfluent pigment, default normal, default finish etc..
Problem consists when adding antialiasing, changing resolution, changing camera view-point etc.; when I replace merge with union, the problem disappeared.
The scene was checked on two different machines with different versions of POV-Ray:
Gentoo Linux, kernel 2.6.39-r3, i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel, 2G RAM (this is Dell PowerEdge 2650 server with 2 dual-core Intel Xeon MP processors); Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (i686-pc-linux-gnu-g++ 4.5.3 @ i686-pc-linux-gnu)
Gentoo Linux, kernel 2.6.37-r4, x86_64 AMD Athlon™ X2 Dual Core Processor BE-2350, 2G RAM (non-branded machine); Persistence of Vision™ Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++ 4.4.4 @ x86_64-pc-linux-gnu)
(scene has been adapted slightly to be rendered with 3.6, the adaptation was to change “emission” with “ambient” and replace gamma “srgb” with “2.2”)
Both machines generate similar images.
The attachment is an archive containing sources of minimal scenes with these problems, and sample pictures I generated from them on my machines.
|
|
226 | Geometric Primitives | Possible Bug | 3.70 RC3 | Very Low | Low | Near-coincident surface accuracy | Tracked on GitHub | |
|
Task Description
This is a transparent box very close to a plane.
box {
-1, 1
pigment { rgbf <0, 0, 1, 1> }
}
plane {
#if (version < 3.7)
y, -1.0000007
#else
y, -1.00007
#end
pigment { rgb 1 }
finish { ambient 1 }
}
camera {
location <1, 2, 3>
look_at 0
}
The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).
So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)
|
|
227 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 RC3 | Very Low | High | Fixed Vector Limitations | Tracked on GitHub | |
|
Task Description
See this documentation entry for more details.
|
|
229 | Image format | Feature Request | 3.70 RC3 | Very Low | Low | Clock value into EXIF data for PNG | Tracked on GitHub | |
|
Task Description
The best time for a picture....
I set the day time and so the position of the sun by “clock=”
Normal I document my source very good, but this time, I forgot the clock seting for the picture of my book cover.
So I would find it very practicall to put the clock value and other setings for rendering into EXIF data of the picture.
|
|
230 | User interface | Feature Request | 3.70 RC3 | Very Low | Low | Improved handling of animations | Tracked on GitHub | |
|
Task Description
October to middle November, I prodduced a 5 minutes video mainly py POVRAY.
Here a part of the video.ini file
#
# szenes based on games.pov #
#game-pat #Initial_Frame=450 - time scale 1000 - 30 seconds #Final_Frame=899 #Initial_Clock=-12500 #Final_Clock=17500
#game-lost - time scale 1000 - 22 seconds #Initial_Frame=0 #Final_Frame=659 #Initial_Clock=2000 #Final_Clock=24000
#game-lost - time scale 3000 - 12 seconds - fast through the night #Initial_Frame=0 #Final_Frame=359 #Initial_Clock=24000 #Final_Clock=60000
#book-cover #clock=64000
#game-sunrise - time scale 1000 - 35 seconds #Initial_Frame=0 #Final_Frame=1049 #Initial_Clock=60000 #Final_Clock=95000
Now imagine all the problems:
One computer crashes often because of thermal problems. Last picture rendere 487.
Now calculate the setings, that this computer continues the task at 487
Or 2 computers should render a scene.
Sounds very easy. Something like computer 1 makes 0..499 computer 2 makes 500..999.
But the computers are different in speed and the pictures are very different in computation time.
So it would be best
computer 1: 0 to 999 computer 2: 999 to 0
They would meet in the middle, where ever this middle is.
So it would be much easier with
#game-sunrise - time scale 1000 - 35 seconds Initial_Frame=0 Final_Frame=1049 Initial_Clock=60000 Final_Clock=95000 Initial_Task=487 Final_Task=1049
So I have not to calculate the exact clock seting, when a computer sould continue a task after crashing at picture 487
#game-sunrise - time scale 1000 - 35 seconds Initial_Frame=0 Final_Frame=1049 Initial_Clock=60000 Final_Clock=95000 Initial_Task=1049 Final_Task=0
This would be the reverse calcualtion order. Starting with picture 1049 and going down 1048..1047
|
|
237 | User interface | Definite Bug | 3.70 RC3 | Defer | Very Low | Glitch in displaying rendered pixels and percentage | Tracked on GitHub | |
|
Task Description
When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal are first displayed like this: Rendered 126202 of 360000 pixels (35%) Then on the second stage the output text becomes shorter and you see Rendered 25344 of 360000 pixels (7%)%) The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.
I’m running Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu) compiled for the Arch Linux package.
|
|
240 | Geometric Primitives | Feature Request | 3.70 RC3 | Very Low | Low | Object for efficient automatic periodic pavement | Tracked on GitHub | |
|
Task Description
Whenever some object is to be periodically repeated in some kind of grid, you can achieve this with macros, but it a) wastes a lot of resources
even if object references are implemented in the future, wrapper with its own transformation matrix still takes space and bookkeeping
b) is not infinite
annoying when making infinite planar tiling with arbitrary objects
like an approximate water surface or tiling with real bricks
or anything that needs to extend to horizon
c) is not optimized for periodicity
I think it can be very efficiently implemented as an object that takes a finite object argument (like CSG functions) and can be periodic in either 1D,2D or (possibly dangeorous?) 3D with specified period. In each dimension, the number of repetitions can be any integer or even infinity (or max_int). Something like periodicity <2,2,Infinity> 2 copies in 1 direction, 2 in the other, infinite in the third grid_separation <1,2,2> 1 unit size in first direction, 2 unit sizes in the other two
All the code needs to do is raytrace in the current unit cell and if the ray passes uninterrupted, pass it through the neighbouring unit cell (which means trace a translated ray through the same object). The object itself would just feel an additional clipping box, everything else would work seamlessly.
In case of infinite column of transparent object, max_trace stops the infinite loop anyway.
This is just a suggestion, I realize this is more of a long-term change but it is quite easy to implement and would simplify a large number of projects.
|
|
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.
|
|
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)
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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/
|
|
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
}
|
|
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.
|
|
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.
|
|
117 | Sample scenes | Unimp. Feature/TODO | 3.70 beta 37a | Very Low | Low | Update Benchmark.pov | Closed | |
|
Task Description
The included scenes\advanced\benchmark.pov (v1.02)is different then the winpov menu render\run benchmark (v2.01).
The winpov menu render\run benchmark is missing some objects, turned off in early betas?
|
|
119 | Documentation | Feature Request | 3.70 beta 37a | Very Low | Low | Table of Contents in each page of the docs | Closed | |
3.70 release |
Task Description
There should be a table of contents on each page of the documentation, or at least on the very long pages. Scrolling through the entire page to figure out what topics are covered sucks.
|
|
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.
|
|
121 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Option to render pixels randomly, or in Nth pixel | Closed | |
|
Task Description
Assuming there are no performance issues, it would be nice to tell Povray to select the pixels to render randomly, so that the image gets filled in gradually instead of from top to bottom and from left to right.
Also, maybe an option to tell it to render every Nth pixel.
|
|
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.
|
|
123 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #BREAK statement inside #WHILE and #FOR loops | Closed | |
|
Task Description
Request #BREAK statement inside #WHILE and #FOR loops.
|
|
124 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | variable number of parameters in macros | Closed | |
Future release |
Task Description
Many programming languages support an indeterminate number of parameters in functions/macros.
JavaScript for instance supports an “arguments” object.
Lua for instance supports the “args” object.
I would like to see that added to POV as well.
Here’s an JavaScript example:
function ArgTest(a, b){
var i, s = "The ArgTest function expected ";
var numargs = arguments.length; //Get number of arguments passed.
var expargs = ArgTest.length; //Get number of arguments expected.
if (expargs < 2)
s += expargs + " argument. ";
else
s += expargs + " arguments. ";
if (numargs < 2)
s += numargs + " was passed.";
else
s += numargs + " were passed.";
s += "\n\n"
for (i =0 ; i < numargs; i++){ //Get argument contents.
s += " Arg " + i + " = " + arguments[i] + "\n";
}
return(s); //Return list of arguments.
}
|
|
125 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Very Low | System variable to track whether a file has been includ ... | Closed | |
|
Task Description
Request a system variable to test whether a scene file has been included by another scene file.
For instance:
#if (is_included)
camera {...}
#end
|
|
126 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Explicit #RETURN statement inside macros | Closed | |
|
Task Description
In POV SDL it can sometimes be ambiguous what exactly a macro returns. An explicit #RETURNS statement would make this unambiguous.
|
|
128 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Mixed-type arrays | Closed | |
|
Task Description
Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.
|
|
130 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | High | Master scene unit system variable | Closed | |
|
Task Description
Currently, many POV scenes/include files behave differently depending on the basic units used within the scene. Scaling them differently can affect things like ior and media. A master system variable that users can set to configure the scene’s units would be beneficial for sharing and collaboration purposes, so that person A’s glass interior works correctly in person B’s wine glass scene. Just like the #version system variable, it should have a default value but should be possible to explicitly override.
|
|
132 | Geometric Primitives | Feature Request | 3.70 beta 37a | Very Low | Low | Native support for mesh-based surface approximations | Closed | |
|
Task Description
There are various scripts around the Net meant for approximating things like isosurfaces and parametric objects using meshes. It would probably run bit faster and be easier to use if this were supported natively within Povray. The feature would require an additional object parameter in order to toggle this behavior on/off.
|
|
134 | Image format | Feature Request | 3.70 beta 37a | Very Low | Low | INI option to overlay render information on output imag ... | Closed | |
|
Task Description
It would be nice to configure an INI option to add render information like render time, date, and input file to output images.
|