|
78 | Photons | Possible Bug | 3.70 beta 35a | Very Low | High | Wrong rendering of BeamTest-Scene in 3.7.beta.35a | Closed | |
3.70 beta 37 |
Task Description
Hi,
following scene will not be rendered correctly in 3.7.beta.35a:
http://lib.povray.org/collection/beamtest/cousin%20ricky%201.1/beamtest.html
maybe it is a configuration problem or it is a real bug.
|
|
83 | Source code | Possible Bug | 3.70 beta 36 | Very Low | Very Low | redundant code in pvengine.cpp | Closed | |
3.70 beta 37 |
Task Description
In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:
3997 case KEYWORD_LOOKUP_MESSAGE :
3998 hh_aklink.pszKeywords = (LPCSTR) lParam ;
3999 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000 hh_aklink.pszKeywords = "" ;
4001 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002 hh_aklink.pszKeywords = "" ;
4003 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004 hh_aklink.pszKeywords = "" ;
4005 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006 hh_aklink.pszKeywords = "" ;
4007 HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008 return (true) ;
This duplication appears pretty much useless to me - or am I missing something?
|
|
84 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | A for-loop construct | Closed | |
3.70 beta 37 |
Task Description
Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.
The only remaining question would be the syntax.
IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:
#for(<identifier name>, <initial value>, <final value> [, <step>])
<loop body>
#end
Example:
#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
#debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
#debug concat(str(Counter, 0, 0), "\n")
#end
I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).
Of course this raises a couple of questions:
1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:
2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:
// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
#debug concat(str(Counter, 0, 0), "\n")
#if(Counter = 3) #local Counter = 8; #end
#end
Alternatively the counter variable could be read-only.
Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).
|
|
88 | Image format | Definite Bug | 3.70 beta 36 | Very Low | Low | File output code does not properly handle negative colo ... | Closed | |
3.70 beta 37 |
Task Description
File output code for virtually all file formats performs gamma correction on unclipped color values, which leads to issues when color values happen to be negative for some reason and gamma does not happen to be an integer value such as 1.0 or 2.0. As a consequence, subsequent steps (clipping and converting to integer) apparently produce compiler-dependent results. Compiled with Microsift or Intel compilers, POV-Ray seems to write zero brightness in such cases, while compiled with g++ 4.4 (and possibly other compilers) it seems to write full brightness instead.
(See thread news://news.povray.org:119/4ba819f6@news.povray.org for examples.)
The proper solution should be to apply gamma correction after clipping.
|
|
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)
|
|
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.
|
|
92 | Geometric Primitives | Definite Bug | 3.70 beta 36 | Low | High | Sphere_Sweep Bug | Closed | |
3.70 beta 37 |
Task Description
This item may need to be merged with item FS#81. This is another sphere sweep bug, though they are of different spline types.
The code is
#include "colors.inc"
camera {
location <0, 0.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
#declare i_start = 0;
#declare i_stop = 3;
#declare i_step = 0.05;
#declare i_inc = i_start;
sphere_sweep {
linear_spline // linear curve
(i_stop - i_start)/i_step + 1, // number of specified sphere positions
#while(i_inc<=i_stop)
#declare y_coor = 0.23*sin(7.1*i_inc);
<i_inc, y_coor, 0>, 0.05
#declare i_inc = i_inc + i_step;
#end
pigment{color Orange}
}
|
|
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 }
}
|
|
94 | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | High | Unexpected refraction angle in interfaces with changing ... | Closed | |
3.70 beta 37 |
Task Description
I’ve tried to model this setup: http://kschwebke.webng.com/povray/ior-interfaces/drawing.png with the following SDL: http://kschwebke.webng.com/povray/ior-interfaces/rs2.pov.txt
A small overlap between the two transparent solids is needed, because a gap would lead to total reflection. The camera in the test scene looks in the direction of the ray in the setup drawing. The setup is surrounded with angular markers, so one can easily read the final resulting looking angle.
POV-Ray 3.6.1 renders the expected result (~53° in the center of the screen): http://kschwebke.webng.com/povray/ior-interfaces/rs2-35.jpeg
POV-Ray 3.7.0b35a (compiled Unix source) renders a different (and in my opinion wrong) angle (~67°), however – for the very same scene file: http://kschwebke.webng.com/povray/ior-interfaces/rs2-37b35a.jpeg
I’ve started a discussion about this issue in povray.beta-test: http://news.povray.org/povray.beta-test/thread/%3Cweb.4bba4677730ab9f3e8c084b40%40news.povray.org%3E/
All linked documents are also attached.
|
|
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 }
}
|
|
97 | Other | Possible Bug | 3.70 beta 36 | Very Low | Low | Forward-slash pathnames not fully supported in Windows ... | Closed | |
3.70 beta 38 |
Task Description
The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.
|
|
100 | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | Low | cutaway_textures | Closed | |
3.70 beta 37 |
Task Description
When using cutaway_textures the differenced part traces black. Simple scene file attached.
|
|
101 | Include files | Feature Request | 3.70 beta 36 | Very Low | Low | woodmaps.inc dependency | Closed | |
3.70 beta 38 |
Task Description
woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1
|
|
103 | Image format | Definite Bug | 3.70 beta 37 | Very Low | Low | JPEG output does not conform to baseline JFIF standard | Closed | |
3.70 beta 38 |
Task Description
POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.
As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.
|
|
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).
|
|
107 | Parser/SDL | Definite Bug | 3.70 beta 37 | Very Low | Low | Failed to parse INI file, over network | Closed | |
3.70 beta 38 |
Task Description
I can no longer run a Myfile.ini over a network, on a different computer.
Possiblely related to:
http://bugs.povray.org/task/97 FS#97 (Forward-slash pathnames not fully supported in Windows version)
- Cannot open INI file ‘\\STEPHEN-POVRAY\Bishop3d\Objects\Industrial_enclosure\Telco_enclosure_extra.ini’. Failed to start render: Failed to parse INI file
|
|
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?
|
|
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).
|
|
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
|
|
156 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Crash when reading from DF3 file with no data, using in ... | Closed | |
3.70 RC4 |
Task Description
A df3 file is written, with header 00 00 00 00 00 00 and no data (hypothetically valid df3 file). This file is used as density file for media, using interpolation. This causes a crash once Pov-Ray starts rendering the pixels that contain media. All pixels rendered before that render fine. Using no interpolation does not cause a crash.
Sample Scene: #fopen out “random.df3” write #write (out, uint16be <0,0,0>) #fclose out
box{0,1 pigment{rgbt 1} hollow interior{media{ density{density_file df3 “random.df3” interpolate 1}}}} // interpolate 2 also crashes, interpolate 0 does not.
System: Win7 x64, 3.7 Beta 38
|
|
157 | Include files | Definite Bug | 3.70 beta 37a | Very Low | Medium | Warnings when parsing include file provided by distribu ... | Closed | |
3.70 beta 39 |
Task Description
Include file golds.inc still provides warnings when parsed, a shame for a standard include file. (colors.inc is ok, I did not test the other includes)
File '/usr/local/share/povray-3.7/include/golds.inc' line 118: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 119: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 129: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 130: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 140: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 141: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 151: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 152: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 162: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 163: Parse Warning:
Expected pure RGB color expression, unexpected filter and transmit components
will have no effect.
|
|
158 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Antialias Gamma reporting error | Closed | |
3.70 beta 39 |
Task Description
value is erroneously clipped to the range 0..1 before being displayed
|
|
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
|
|
166 | Texture/Material/Finish | Definite Bug | 3.70 beta 38 | Very Low | Low | quick_color does not work | Closed | |
|
Task Description
the quick_color feature doesn’t work when +qN or Quality=N is set to 5 or below
|
|
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}
}
|
|
169 | Parser/SDL | Possible Bug | 3.6 | Very Low | Low | Error in Linux version using #while loop and SweepSplin ... | Closed | |
3.70 RC4 |
Task Description
I used POV-Ray to make an animation of my Morgan driving around a slalom course. (If you are curious, you can see the output on youtube under my user name, nojonushi.) To make the long swooping fenders I used Mike William’s SweepSpline macro.
The code rendered the 1189 frames in one go with no problems. But the wheels in that animation do not rotate, so I then added code to rotate the wheels. In the calculations I added I used a #while loop to step through the spline containing the route coordinates and total up the distance traveled. Running POV-Ray on this file produced a random number of images and then issued an error, e.g.
0:00:00 Processing Frame 456 of 1189
0:00:00 Parsing
File: mogslalom.pov Line: 1918 Parse Warning: Patch objects not allowed in intersection. File: mogslalom.pov Line: 2988 File Context (5 lines):
object {
SweepSpline(TFSpline,
Parse Error: Identifier expected, incomplete function call or spline call found instead.
Most of the parameters for the macro are missing. But this is after successfully generating, in this case, 455 images.
I have attached a text file with set-up and sample code that has given the error on two different machines.
|
|
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).
|
|
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).
|
|
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)
|
|
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.
|
|
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.
|
|
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).
|
|
197 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | -J by itself does nothing | Closed | |
3.70 RC4 |
Task Description
The documentation says:
“-J Sets aa-jitter off”
However, it seems to have no effect. -J0 will turn off jittering.
|
|
198 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing closing brace in function definition causes mem ... | Closed | |
3.70 RC4 |
Task Description
Given the following two statements, a missing closing brace in the function declaration fn should throw a parse exception; instead it causes a memory access violation when trying to use fn in the second delcaration:
#local fn = function {
pigment { image_map { png "MultiPassBlobs3.png" gamma 1 map_type 0 once }}
#local clr = fn(0,0,0);
|
|
200 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Calibri TrueType font garbled | Closed | |
3.70 RC4 |
Task Description
original post on povray.beta-test:
POV-Ray 3.7.0.RC3 on Slackware 13.0 x86_64.
I pointed povray to use the calibri.ttf font over on my Windows 7 partition.
The result is garbled - strange letters with accents appear instead of the
expected text. (KDE's kfontview opens calibri.ttf OK, with nothing strange).
Pointing povray to use other fonts of Win7, e.g. comic.ttf and arial.ttf, was
OK.
I solved the problem by pushing calibri.ttf through fontforge and resaving it
as mycalibri.ttf.
Cheers,
Peter
Confirmed with development version on Windows XP x64.
Possibly a similar problem as FS#162 .
|
|
201 | Parser/SDL | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Low | repeated re-declaring of functions causes runaway memor ... | Closed | |
3.70 RC4 |
Task Description
original posting from povray.beta-test:
I get this error message:
"Parse Error: bad allocation Render failed"
- after the code below has been running for about 3 seconds.
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
#version 3.7;
#while (true)
#local Fn = function { transform { translate <0, 0, 0> } }
#undef Fn
#end // while
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
I'm using POV-Ray for Windows - Version 3.7.0.RC3.msvc9-sse2.win32
The operating system is Windows XP.
With the code above, the error messages has so far appeared every time
right after 3318K tokens have been parsed. But with other versions of
my code, the error message does not always show up. (Sometimes the
render finishes and sometimes the parsing stops at different "times".)
[...]
Other users report no error message, but memory consumption rising to about 1.2 GB.
|
|
203 | Radiosity | Definite Bug | 3.70 RC3 | Very Low | Low | Radiosity artifacts at low error_bound | Closed | |
3.70 RC4 |
Task Description
A scene of a hollow sphere viewed from the inside:
difference {
sphere { 0, 100 }
sphere { 0, 99 }
pigment { rgb 1 }
finish { ambient .4 }
}
global_settings {
radiosity {
error_bound .1
}
}
Rendering produces dark splotches at the centers of the pretrace blocks, as shown in the attached image. Blocks rendered earlier have darker splotches. They also differ in shape between renders even with +HR (but not with +WT1).
Turning “always_sample” on, changing “pretrace_end” to 0.01, or increasing “count” past 1000 makes them imperceptibly faint (they can still be seen by increasing image contrast).
This is possibly a bug, as 3.6 doesn’t produce these artifacts regardless of additional settings.
povray.beta-test thread
|
|
204 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Low | -V is not Verbose=off on Unix | Closed | |
3.70 RC4 |
Task Description
In vfe/unix/unixoptions.cpp, -V is defined as a synonym for --version, overriding its general meaning of Verbose=off.
|
|
208 | Parser/SDL | Definite Bug | 3.70 RC3 | Low | High | Use-after-free when returning local function or spline ... | Closed | |
3.70 RC4 |
Task Description
#macro A()
#local foo = function { x }
foo
#end
#local bar = A();
This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.
After some debugging I think this is what happens.
In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.
So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:
Temp_Data = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);
if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.
A similar problem occurs when foo is a spline.
A tentative patch for the function case is attached.
|
|
209 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Medium | Weighted texture of CSG | Closed | |
3.70 RC4 |
Task Description
in change #3319, csg got a new computation for its weighted textures.
But I’m confused by the computation of the weight: (circa end of csg.cpp file)
COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);
I would have used a max() rather than a min().
It is transparent when there is only one texture, but:
should there be no texture (an error...): it would be a division by 0
should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n
Or did I get a confusion about min() ?
min(0,1) == 0 min(4,1) == 1
Using max would protect against the division by 0 and the right value when multiple textures are used.
Any thought ?
|