|
317 | Preview | Definite Bug | 3.70 release | Very Low | High | problem with +D option at specific output file dimensio ... | Closed | |
|
Task Description
Reported in p.beta-test by James Dietrich (2013-12-12)
when the display window must be scaled (because one or both dimensions are larger than the actual screen), the ratio of scale might be too large in some occasion, performing a memory corruption in two places and usually crashing povray.
How to reproduce, with a 1920×1080 display (or 1920×1200):
povray +W2596 +H1003 +Ispiral.pov +Ospiral.png +D
|
|
35 | Documentation | Feature Request | All | Very Low | Low | problem parsing +i option in povray-3.7.0.beta.32 on li ... | Closed | |
|
Task Description
The commands:
povray +i /home/ronis/Nm=500/povray.00001.pov
or
povray +i/home/ronis/Nm=500/povray.00001.pov
fail with: povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and 1 hour(s) Failed to parse command-line option
Going to the directory and simply running: povray +i povray.00001.pov works.
I came across this by accident trying to get emac’s povray mode to work; apparently it passes the full path name to povray.
I don’t think there is a problem in 3.6.1
|
|
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.
|
|
89 | Image format | Definite Bug | 3.70 beta 36 | Very Low | Low | PPM output garbled for bit depths other than 8 bits | Closed | |
3.70 beta 37 |
Task Description
When choosing PPM output with a bit depth other than 8 bits per color channel (e.g. +FP16), POV-Ray messes up the colors (see thread news://news.povray.org:119/4babb48f$1@news.povray.org)
|
|
195 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Medium | povray-3.7.0rc3 incompatible with NetBSD | Closed | |
|
Task Description
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe) 2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable. 3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix). 4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3. 5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is #ifdef HAVE_SYS_WAIT_H # include <sys/wait.h> #endif but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html. Backtrace is Program terminated with signal 11, Segmentation fault. #0 0x00000000004ac479 in boost::gregorian::date::date () (gdb) bt #0 0x00000000004ac479 in boost::gregorian::date::date () #1 0x00000000004d29f7 in boost::gregorian::date::date () #2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= () #3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= () #4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= () #5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName () #6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName () #7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName () #8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= () #9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>) at /archive/cvs/src/lib/libpthread/pthread.c:473 #11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
|
|
76 | Other | Feature Request | 3.6 | Very Low | Medium | Povray returns incorrect exit code when aborting render | Closed | |
3.70 release |
Task Description
If you abort a render with ^C, Povray exits with a ‘success’ error code.
To test:
povray scene.ini
(^C to abort it)
echo $?
Right now 0 is returned (’success’). A non-zero value should be returned (’failure’).
This is particularly important for scripting, where command lines like:
povray scene.ini && halt
...can be used. I only want the halt to be executed if the scene renders successfully. If I change my mind and ^C it, I don’t want the machine to shut down!
|
|
144 | Image format | Compatibility Issue | 3.6 | Very Low | Medium | povray compatibility issue with png-1.4 | Closed | |
3.70 beta 39 |
Task Description
source/png_pov.cpp included in povray-3.6.1 contains calls to an internal function of libpng (png_write_finish_row) which was removed from the public interface quite a while ago, so linking fails.
Also, in the 1.4 releases of libpng, the info_struct “trans” member was renamed to trans_alpha. This causes a compilation error in the same file.
A suggestion for the solution: a) remove the png_write_finish_row prototype and function call b) add something like: #if PNG_LIBPNG_VER < 10400 #define trans_alpha trans #endif and change cmap[index].Transmit = 255 - r_info_ptr→trans[index]; to cmap[index].Transmit = 255 - r_info_ptr→trans_alpha[index]; (two occurrences).
|
|
245 | Other | Feature Request | All | Defer | Low | POVMS message queue can fill up with GB of data for ver... | Tracked on GitHub | |
Future release |
Task Description
With very fast renders and very large output files, the message queue can fill up because the producers are not limited by IO, while the consumer performance is limited by disk IO. Consequently, the message queue can fill up to exhaust all available memory. The solution is to build in some better control of pending output data in the message queue on the producer side. This will also pave the way for message communication over slow links (i.e. a network).
|
|
38 | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | POVDocGen extension | Closed | |
3.70 release |
Task Description
Develop MediWiki extension to extract documentation sets from the POV-Wiki.
|
|
293 | User interface | Possible Bug | 3.70 RC7 | Very Low | Low | POV-Ray Shown Twice in Windows Taskbar | Tracked on GitHub | |
|
Task Description
When rendering for some time, it occasionally happens that POV-Ray appears twice in the Windows taskbar. One button is the normal one, the other one does not open any window when clicked on and reads something like “99% complete” (see attached image), like the render window’s title, but obviously unrelated to it (probably the title the render window had shortly before?). After stopping the render, the odd taskbar button remains there until POV-Ray is closed.
Observed under Windows XP
POV-Ray 3.7.0.RC7.msvc10-sse2.win32
When applications are summarized into groups in the taskbar by Windows, the odd POV-Ray button is attached to the Windows Explorer group
Run with render priority set to “high”
Is this a Bug in Windows or in POV-Ray?
|
|
51 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Critical | POV-Ray crashes hard on missing parenthesis | Closed | |
3.70 beta 35 |
Task Description
The following (bogus) SDL code causes POV-Ray 3.7 beta to crash hard with an access violation:
#include "fubar.inc"
Bar(42)
#macro FooBar() #end
//fubar.inc
#macro Foo(Fnord) #end
#macro Bar(Ignord) Foo(23 #end
|
|
257 | Other | Definite Bug | 3.70 RC6 | Very Low | Low | POV-Ray cannot find input file when resuming to render ... | Closed | |
3.70 RC7 |
Task Description
How to reproduce:
# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png
What happens:
==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed
OS: Gentoo AMD64 unstable POV-Ray version: 3.7.0 rc5
|
|
90 | Parser/SDL | Definite Bug | 3.70 beta 36 | Very Low | Very Low | POV-Ray accepts additional patterns after "slope" | Closed | |
3.70 beta 37 |
Task Description
The following code is erroneously accepted by POV-Ray (tested with 3.7.0.beta.36):
pigment{
slope { x }
checker
}
The result is a checker pattern.
Apparently there is an EXIT statement missing in the slope-pattern parsing code in parstxtr.cpp.
|
|
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.
|
|
2 | Platform-specific | Compatibility Issue | 3.61c | Low | High | POV-Ray 3.6x does not work properly in Vista | Closed | |
3.62 |
Task Description
There are a number of problems with the Windows version of POV-Ray under Windows Vista. To resolve these, the setup program needs to be re-written and the location of internal files changed.
|
|
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 .
|
|
233 | Parser/SDL | Possible Bug | 3.70 RC3 | Very Low | Low | Picture index out of range. - Fatal error in renderer: ... | Closed | |
3.70 RC7 |
Task Description
As posted in povray.beta-test 2012-01-14 with the same subject.
OS Win7 32 bit
The following code fails with the following message: Picture index out of range. Picture index out of range. Fatal error in renderer: Uncategorized error. Render failed
The texture scale is relevant.
It does not fail in Pov 3.62 The image map can be downloaded from: http://www.mmedia.is/~bjj/data/s_rings/sat_ring_color.png
(Attached)
#version 3.7;
global_settings { adc_bailout 0.0039 ambient_light rgb <1.000,1.000,1.000> assumed_gamma 1.00 irid_wavelength rgb <0.250,0.180,0.140> max_trace_level 5 number_of_waves 10 noise_generator 3 charset ascii }
background { colour rgb <0.000,0.000,0.000> }
#declare Ring_Texture1 = texture { uv_mapping pigment {
image_map{
png "sat_ring_color.png"
interpolate 2
map_type 0
}
rotate <90.000,90.000,0.000>
}
finish {
ambient rgb <0.100,0.100,0.100>
brilliance 1.000
crand 0.000
diffuse 0.600
metallic 0.000
phong 0.000
phong_size 40.000
specular 0.000
roughness 0.050
}
}
#declare Camera0 = camera { perspective location <3843.816,38.892,-2660.667> up y right 1.333*x angle 33.000 sky ←0.004,1.000,0.002> look_at < 0.449, 18.943, 0.102 > } end Camera0
disc { Disc0 0,y,4.400000,2.500000 texture{ Ring_Texture1 }
scale <750.000000,750.000000,750.000000> // Fails 32 bit
scale <800.000000,800.000000,800.000000> Fails 64 bit scale <600.000000,600.000000,600.000000> does not fail rotate <0.000000,0.000000,-20.000000> translate ←3500.000000,900.000000,900.000000> } end Disc0
camera{ Camera0 }
///
|
|
241 | Photons | Definite Bug | 3.70 RC4 | Very Low | Low | Photons not working correctly | Closed | |
3.70 RC6 |
Task Description
~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.
|
|
93 | Photons | Definite Bug | 3.70 beta 36 | Very Low | Medium | Photons are unnaturally amplified by pass_through objec ... | Closed | |
3.70 release |
Task Description
The following scene shows how photons are “boosted” by pass_through objects; removing one of the boxes will reduce the effect; the effect can be seen with 3.6 as well as current betas:
global_settings {
max_trace_level 10 // makes a difference!
photons { spacing 0.02 }
}
camera {
right x*image_width/image_height
location <0,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,500,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.5
fade_power 1001
fade_distance 0.9
fade_color <0.5,0.8,0.6>
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
cylinder {
<-1.2,0.01,0.8>, <-1.2,2.5,0.8>, 1
material { M_Glass }
photons { // photon block for an object
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_Glass }
photons { pass_through }
}
box {
<2.9,0,-2.3>, <3.1,4,-0.3>
material { M_Glass }
photons { pass_through }
}
|
|
95 | Photons | Definite Bug | 3.70 beta 36 | Low | High | Photons are over-attenuated by semi-transparent surface ... | Closed | |
3.70 beta 37 |
Task Description
The code to attenuate transmitted photons according to surface texture was apparently duplicated during refactoring of the source code for version 3.7. Behavior has changed from 3.6 to 3.7 (beta.36) accordingly, as can be demonstrated with the following scene:
global_settings {
assumed_gamma 1.0
max_trace_level 10
photons { spacing 0.02 }
}
camera {
right x*image_width/image_height
location <0,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,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 <1.0, 0.8, 0.6> } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.5
fade_power 1001
fade_distance 0.9
fade_color <0.5,0.8,0.6>
}
}
#declare M_PseudoGlass2=
material {
texture {
pigment {rgbf <0.8,0.2,0.2,0.8>}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.0
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,0.3>
material { M_PseudoGlass2 }
photons { target 1.0 refraction on reflection on }
}
|
|
252 | Photons | Definite Bug | 3.70 RC6 | Very Low | Low | photons and light_group is broken | Tracked on GitHub | |
|
Task Description
photons are not working when used with a light_group. verified in NG posting in p.general a simple scene file is attached.
|
|
165 | Photons | Definite Bug | 3.6 | Very Low | Low | photon problem: image of projected image_map is clipped ... | Closed | |
3.70 RC4 |
Task Description
Hi,
I have a problem with photons. The following stripped down code simulates a slide projector:
#include "colors.inc"
global_settings {
#if (1) // switch photons on/off
photons { count 1000000 }
#end
}
camera { location <0, 0, 200> sky<0,1,0> look_at <0,200,-200> angle 90 }
// projection screen
plane { z, -200 texture { pigment { White } finish{ diffuse 1 ambient 0.1} } }
// slide
polygon {
5, <0,0,0>, <1,0,0>,<1,1,0>,<0,1,0>,<0,0,0>
pigment { image_map {jpeg "s7_0.9_320.jpg" interpolate 2 filter all 1.0 } }
translate <-0.5, 0.2, -0.3>
photons { target refraction on reflection off collect off }
}
// projector lamp
light_source { <0, 0, 0> color <1,1,1> }
——————————————-
A point light source projects through a image_map onto a screen.
Without photons the projected image is ok: http://img838.imageshack.us/i/test4woph.png/
With photons the left and right bottom corners of the image will be clipped: http://img101.imageshack.us/i/test4wph.png/
The size of clipped corners depends on the y-offset in the translate command.
The povray Version is: Persistence of Vision™ Ray Tracer Version 3.6.1 (Debian (x86_64-linux-gnu-g+ + 4.3.3 @ x86_64-pc-linux-gnu)) (the 3.7 beta has the same problem)
I posted this question in the general news group and got an answer by Christian Froeschlin, who could reproduce the problem and suggested as workaround to divide the slide into small stripes
http://news.povray.org/povray.general/thread/%3Cweb.4c972bdffcc128eac947b6de0%40news.povray.org%3E/
This works, but doesn’t explain the problem.
Does anyone have an idea, whats wrong?
Many thanks, Corvin
|
|
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.
|
|
25 | Animation | Definite Bug | 3.70 beta 32 | Defer | Low | Pause sometimes fails when rendering animation | Tracked on GitHub | |
|
Task Description
There is an issue where the pause button in POVWIN will sometimes not work during an animation (primarily where the frame rate is high), and furthermore, POVWIN can then get into a state where it’s not possible to use the pause until it is re-started.
Newsgroup report.
|
|
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.
|
|
33 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Low | parse accepting invalid vector float components | Closed | |
3.70 beta 33 |
Task Description
The parser is missing extra period characters when it parses a float as a vector component.
#local sample = <0.0.0.1,0,0>;
Doesn’t generate an error, but should.
|
|
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.
|
|
219 | Documentation | Possible Bug | 3.70 RC3 | Very Low | Low | Panoramic camera broken & obsolete | Closed | |
3.70 RC4 |
Task Description
According to the docs, the panoramic camera...
[...] uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle.
However, current implementation differs (and probably always has): The angle keyword has no effect, and the effective viewing angle is fixed to 180 degrees. Also note that this behaviour is identical to the spherical camera with angle 180,180, making the panoramic camera obsolete.
I propose to deprecate the “panoramic” keyword; should the keyword be encountered in a camera block, the code for the spherical camera should be used instead, except that the angle setting should be forced to 180,180; this should be accompanied by a parse warning.
|
|
239 | Setup/Install | Definite Bug | 3.70 RC4 | Very Low | Medium | Owner and group of user's local configurations on insta ... | Closed | |
Future release |
Task Description
I reinstall a system, (so ~/.povray was not existant), and then installed povray from sources, as a normal user (excepted the installation step):
$ ./configure ... $ make $ make check $ sudo make install
I find these steps pretty much standard.
The problem I’m noticing is that the $HOME/.povray hierarchy get owned by root (hey, it’s *MY* directory !). There is a chown in the Makefile for the target files (povray.ini & povray.conf), as well as subtree but:
* povowner & povgroup are hard coded to 0 (I would expect a copy of the owner & group of $HOME, wouldn’t I ?)
For getting povowner, I would suggest `stat -c “%u” $HOME` For povgroup, `stat -c “%g” $HOME`
Are they portable enough ? (I could ask on Monday a Solaris system, but I do not have bsd and the other flavours of unix)
(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)
Side note: This is fine to install for the local user, but new later users could benefit also from a ~/.povray/3.7/ subtree ; what about also filling the /etc/skel (when available) ? (and in /etc/skel, root owner is fine!)
|
|
55 | Image format | Definite Bug | 3.70 beta 32 | Very Low | Medium | Output_Alpha=on doesn't work as documented | Closed | |
|
Task Description
I have installed POV-Ray 3.7 beta 34 on Windows 7 The setting ‘Output_Alpha=on’ doesn’t work as documented. With this setting the Background appear black and the scene is transparent.
Check with this Code:
camera {
location <3, 3, -3>
direction <0, 0, 2.9>
look_at <0, 0, 0>
right 1.0*x
}
light_source { < 3, 3, -3> color red 1 green 1 blue 1 }
sphere
{
<0,0,0> 0.8
pigment {color rgb<1,1,0>}
finish
{
ambient 0.2
diffuse 0.8
}
}
and with this ini file:
Input_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.pov
Output_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.tga
Output_File_Type=t
Output_Alpha=on
Bits_Per_Color=24
+W121 +H121
+a0.3
+q11
+a
|
|
105 | User interface | Unimp. Feature/TODO | 3.70 beta 37 | Very Low | Low | output options not displayed | Closed | |
|
Task Description
POV-Ray 3.7 does not show output options, such as:
Output Options
Image resolution 640 by 480 (rows 1 to 480, columns 1 to 640).
Output file: D:\foo\test.png, 24 bpp PNG
Graphic display......On (gamma: 2.2)
Mosaic preview.......Off
CPU usage histogram..Off
Continued trace......Off
(the above is what 3.6 used to show)
|
|
104 | Image format | Definite Bug | 3.70 beta 37 | Medium | Critical | Output file gamma broken for File_Gamma=1.0 | Closed | |
3.70 beta 37a |
Task Description
Setting File_Gamma=1.0 produces unexpectedly bright output files for most output file formats, as if File_Gamma was set to 2.2 instead.
The underlying problem is a bug that, when File_Gamma is set to exactly 1.0, causes the encoding gamma function to be undefined, which was not meant to happen in current versions, and instead was reserved for future versions to signal that a file-format-specific default encoding gamma should be used. The image file output handlers already support this, most of them choosing the sRGB transfer function, giving roughly the same output as setting File_Gamma=2.2.
As a preliminary workaround, users may want to set File_Gamma=1.02 (any value smaller than 0.99 or greater than 1.01 should do).
|
|
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.
|
|
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.
|
|
299 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Low | Object Properties Feature | Tracked on GitHub | |
|
Task Description
Up to POV-Ray 3.7 RC7 it has not been possible so far to declare custom properties for POV-Ray’s objects, which would be especially useful for complex objects defined in include files.
Currently, if you want to have an object (e.g. a car) with certain variable parameters (e.g. colour, wheel rotation, ...) defined in an include file and the parameters set by a scene file which uses the include file, you have to choose one of the following approaches:
1. use a macro
#macro car(colour, wheelrot, ...)
...
#end
or, 2. check parameters declared before, e.g.
#declare car =
union {
#ifdef (colour)
#local colour_internal = colour;
#else
#local colour_internal = default_colour;
#end
}
The resulting object would be used in the following way:
#include "car.inc" // include file once
object {
car(rgb <1,0,0>, 0, ...) // macro approach
}
// other approach
#declare colour = rgb <1,0,0>;
#declare wheelrot = 0;
...
#include "car.inc" // include file every time you want to have a car object instance
object {
car
}
Needless to say, both approaches are not quite optimal.
The macro approach needs only one #include directive and name conflicts will (hopefully) not be a problem. However, one would have to look up the parameter order of the macro in the include file, in the worst case every time the macro is used.
The other approach needs as many #include directives as car objects shall be instantiated, there can arise name conflicts with other inculde files used in the scene, and a (potentially long) list of parameters has to be declared before each #include. On the other hand, with this approach for any value it is clear which information it gives, e.g. #declare colour = rgb <1,0,0> can easily be read as ‘set car colour to “red”‘.
My suggestion would be creating an SDL feature to
One step up could be to even declare object classes along with them.
This could look like this:
// include file code
class car { // alternatively (without classes) use #declare car = object { ...
property colour = rgb <1,0,0>; // with default colour
union {
...
}
}
// scene file code
car { // alternatively (without classes) use object { car ... }
colour rgb <0,0,1>
}
Note that this solution makes the declarations much more concise and easy-to-read. Especially in scenes with many includes and animation scenes where objects’ properties have to be manipulated according to sometimes complex functions, this would be very useful. Please also consider that such user-defined objects can have dozens of properties.
|
|
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.
|
|
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.
|
|
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.
|
|
49 | Texture/Material/Finish | Possible Bug | 3.70 beta 32 | Very Low | Low | number_of_waves default value not properly initialized | Closed | |
|
Task Description
When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.
For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:
scenes\textures\finishes\arches.pov
scenes\textures\normals\normavg.pov
scenes\textures\finishes\arches.pov (again!)
|
|
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
|
|
155 | Runtime error | Definite Bug | 3.70 beta 38 | Very Low | Medium | Not able to run --benchmark | Closed | |
3.70 beta 39 |
Task Description
Compiled on linux (revision #5066), ./configure COMPILED_BY=”###” –disable-io-restrictions
the command: povray –benchmark
is failing: Failed to parse INI file
povray –version
povray: this pre-release version of POV-Ray for Unix expires in 27 day(s) and 5 hour(s) POV-Ray 3.7.0.beta.38
This is a time-limited beta test version which expires 31 Dec 2010. General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2010 Persistence of Vision Raytracer Pty. Ltd.
Built-in features:
I/O restrictions: disabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.4.3
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
168 | Texture/Material/Finish | Definite Bug | 3.70 beta 38 | Very Low | Medium | noise_generator default broken | Closed | |
3.70 beta 40 |
Task Description
[Original Title: “texture_map interpolation does not work correctly for some patterns”]
The below test scene should yield identical textures T_STRAND1 and T_STRAND2 but this is not the case. Reported and verified in
http://news.povray.org/povray.general/thread/%3C4cbd804b%241%40news.povray.org%3E/
The problem seems to affect bozo, bumps, dents, granite, spotted, and maybe wrinkles. The problem was reported earlier in
http://news.povray.org/povray.beta-test/thread/%3C48112367%241%40news.povray.org%3E
with a comment that 3.6 gives the expected results
#declare C_STRAND = color rgb 1;
#declare C_CLEAR = color rgb 0;
#declare T_STRAND = texture
{
pigment {color C_STRAND}
}
#declare T_CLEAR = texture
{
pigment {color C_CLEAR}
}
#declare T_STRANDS1 = texture
{
pigment
{
granite scale 2 color_map
{
[0.0 color C_STRAND]
[0.5 color C_CLEAR]
[1.0 color C_CLEAR]
}
}
}
#declare T_STRANDS2 = texture
{
granite scale 2 texture_map
{
[0.0 T_STRAND]
[0.5 T_CLEAR]
[1.0 T_CLEAR]
}
}
plane
{
z, 10
texture {T_STRANDS1}
//texture {T_STRANDS2}
}
|
|
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.
|
|
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.
|
|
163 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 38 | Very Low | Medium | no pigment warning | Closed | |
Future release |
Task Description
no warning is issued when an object/primitive has no pigment type given
|
|
273 | Other | Definite Bug | 3.70 RC6 | Very Low | Medium | No automatic backup files from inc files | Tracked on GitHub | |
|
Task Description
If enabled, POVray always created backups of pov and inc files once per session. Now using 3.7 RC6 only pov file backups are created but not from inc files.
|
|
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.
|
|
307 | Image format | Definite Bug | 3.70 RC7 | Very Low | Low | netpbm, ppm, read bug where first data byte CR char | Closed | |
|
Task Description
I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.
Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.
The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.
The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.
I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.
The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.
Thanks for your time. Bill P.
|
|
11 | Configure/Build | Compatibility Issue | 3.70 beta 32 | Very Low | Low | Need to rename Rect to avoid clash with OSX | Closed | |
3.70 beta 33 |
Task Description
The Rect data type needs to be renamed to avoid a clash with a Mac OSX declaration. It was originally called Rectangle, but this clashed with a Windows declaration. Something more POV-specific should be used, e.g. PovRect.
|
|
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.)
|