|
334 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | HLS colors | Tracked on GitHub | |
|
Task Description
It would be nice to be able to specify colors in HLS as well as RGB.
Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.
|
|
335 | Parser/SDL | Possible Bug | 3.70 release | Very Low | Low | macro works in variable but not in array | Tracked on GitHub | |
|
Task Description
This doesn’t work:
#declare pavement_object = array[2] {
object {trash_can_macro() scale 3/4 translate -x * 1/2},
object {potted_plant_macro(_CT_rand2) scale 3/4 scale 3/2 translate -x * 1/2}
}
This does work:
#declare trash_can_object = object {trash_can_macro()}; #declare potted_plant_object = object {potted_plant_macro(_CT_rand2)}; #declare pavement_object = array[2] {
object {trash_can_object scale 3/4 translate -x * 1/2},
object {potted_plant_object scale 3/4 scale 3/2 translate -x * 1/2}
}
Logically, I cannot see a reason for this to be so.
|
|
26 | Geometric Primitives | Definite Bug | 3.61 | Very Low | Low | Artifacts rendering a cloth which has two-side textures | Tracked on GitHub | |
Future release |
Task Description
Dear PovRay maintainers and developers, congratulations for your great RayTracer!
We think that we have found a bug while we were rendering a piece of cloth.
In this piece of cloth were defined two textures, one for one side and one for the another side:
texture { mesh_tex0_0 }
interior_texture { mesh_tex0_1 }
these definitions in their original context.
We have found some artifacts in the final rendering, in concrete near some wrinkles, please, look at the attached file “render_artifacts.tga”, I have painted a big green arrow near the artifacts, maybe you’ll need to do a zoom to see them more accurately.
They are as though the texture of the other side was painted in the incorrect side.
Fortunately, we have a patch to fix this bug (thanks to Denis Steinemann, he made the implementation for PovRay 3.5, so I have adapted these changes to release 3.6.1)
Although we have found this bug in the Windows and Linux 3.6.1 releases, the patch was generated in Linux (using the source code release of “povray-3.6.1”).
To apply this patch, inside the parent folder of the directory “povray-3.6.1” execute:
patch -p0 < other_side_artifacts.patch
And the “povray-3.6.1” will be patched and you will get a console output like this:
patching file povray-3.6.1/source/lighting.cpp
patching file povray-3.6.1/source/mesh.cpp
patching file povray-3.6.1/source/render.cpp
We don’t know if this “hack” is enough smart to apply in the next release, but we think that it fixes the bug (the artifacts dissapear).
Best regards and thank you very much for your great RayTracer!
|
|
298 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Low | the warning for isosurface does not appears as often as ... | Closed | |
|
Task Description
From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)
William F Pokorny anonymous@anonymous.org wrote: > It seems to be the case the gradient warnings are only generated if the > isosurface is naked. If it is wrapped in an object as was the case with > my thread safety example, we get no warnings.
Confirmed. If only I still had the concentration required to investigate computer code.
#version 3.7;
#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end
global_settings
{ assumed_gamma 1
radiosity {} //force isosurface calculations from all directions
}
light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }
camera
{ location <0.0000, 1.0000, -5.6713>
look_at <-0.7969, 1.2000, -0.0598>
angle 10.7447
}
#include "functions.inc"
#if (Naked)
isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
#else
#declare Test = isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
object { Test }
#end
On the command line, try:
declare=MG=1 declare=Naked=1
and
declare=MG=1 declare=Naked=0
To lose the warning, I had to declare the isosurface. Just wrapping the naked isosurface in an object{} generated a warning.
Further analysis
isCopy seems to be intended to avoid displaying the same warning over and over for the same isosurface (as duplicated isosurface indeed are not copied but reference the same sub-structure).
#declare Ob = isosurface{...}; that’s not a copy object {Ob ... } that’s a copy
Previously (3.6.1) the warning was displayed at the destruction of the isosurface (when the sub-structure was actually referenced by no one else)
if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))
In 3.7, isCopy was introduced with change 4707, 16th February 2009, along with the change introducing means for objects to submit message on shutdown. It was reported in windows source with change 4714, 21th February 2009.
If the symptom “isosurface embbeded in object (CSG) does not show the warning” is correct, it might be a “feature/bug”. The parser copied the isosurface object and deleted the original before the render started. When the render ends, it find only copies and because the refcnt is not used anymore (for that purpose), it miss the last remaining true data to display.
Instead of isCopy, what about adding in mginfo a boolean “printed_warning” (actual name should be more appropriate), set to false on creation, and turn to true on the first call (instead of last for 3.6.1) of the warning displaying function (test for false, set to true if false) ? (and dropping isCopy in the process)
For instance, i’m afraid the following sequence would fails with current code:
#declare Foo = isosurface{ ... }; #declare Bar = object { Foo ... }; #undef Foo;
(or any pop of #local context, such as building the isosurface via macro or loop, or replacing the value of a previous #declare/#local )
|
|
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.
|
|
259 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | Stack Overflow with the write-directive with missing cl ... | Closed | |
|
Task Description
As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.
With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.
I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.
Best regards, Michael
|
|
331 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Medium | Intersection causes quadric to disappear | Closed | |
|
Task Description
The following paraboloid renders correctly:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
}
However, when I extend the clipping cylinder downward:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
}
the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray 3.6.1, it renders as expected.
POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered) POV-Ray 3.7.1-alpha.8150025.unofficial openSUSE 13.2 GNU/Linux
This scene file illustrates the problem:
// +w480 +h240
#version 3.6; //[sic]
global_settings { assumed_gamma 1 }
camera
{ location <0, 1, -7.5958>
look_at <0, 1, 0>
right 2 * x
up y
angle 43.1038
}
#default { finish { diffuse 0.6 ambient rgb 0.15618 } }
light_source
{ <-4.3125, 9.6250, -7.4695>,
rgb 6856.3
fade_power 2 fade_distance 0.10417
spotlight point_at <0, 1, 0> radius 45 falloff 90
}
box
{ -<9, 11, 9>, <9, 11, 9>
pigment { rgb 1 }
}
plane
{ y, 0
pigment { checker rgb 0.05 rgb 1 }
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
pigment { green 0.5 }
translate <-1.25, 1, 0>
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
pigment { green 0.5 }
translate <1.25, 1, 0>
}
On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.
|
|
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
|
|
249 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | UTF-8 files with BOM not accepted | Closed | |
3.70 RC7 |
Task Description
POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.
According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.
|
|
266 | Frontend | Definite Bug | 3.70 RC6 | Very Low | Low | command line options in ini files don't accept quoted s ... | Closed | |
3.70 RC7 |
Task Description
Quoted strings as parameters to command-line options work on the command line but not in INI files; e.g.:
+i"test.pov"
Root cause has already been identified (actually the problem was found during code inspection) and a fix is under way.
|
|
238 | Parser/SDL | Possible Bug | 3.70 RC4 | Very Low | High | Error during #read causes file to be kept open | Closed | |
3.70 RC7 |
Task Description
Consider the following script:
#fopen F "foo.txt" read
#read (F, Foo)
#debug concat ("'", Foo, "'\n")
#fclose F
Now assume that foo.txt erroneously contains unquoted text (which will result in a parse error):
Blah
When the error is reported, POV-Ray for Windows will helpfully open foo.txt, but any attempt to save a corrected version of foo.txt will fail until you exit the POV-Ray GUI, presumably because foo.txt is not properly closed by the parser.
|
|
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!)
|
|
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 }
///
|
|
234 | Frontend | Definite Bug | 3.70 RC3 | Very Low | Low | The +GD flag does not work | Closed | |
3.70 RC7 |
Task Description
The +GD flag gives me an “Invalid parameter” error, whether on the command line or in a .ini file.
Debug_File= still works.
I reported this in povray.beta-test, but did not receive a response.
The problem occurs in both Windows 7 and in Linux.
|
|
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.
|
|
150 | Frontend | Compatibility Issue | 3.70 beta 37a | Very Low | Low | Windows file association problems (Win7 only??) | Closed | |
|
Task Description
Windows allows you to associate programs with file extensions using the “Open with” file manager right-click menu extension.
I’m running Windows 7 64bit, and installed the 64 bit versions of 3.6.2 and the beta appropriately.
A couple of problems that I haven’t tested very thoroughly:
1. If you have both POV 3.6.2 and the beta installed at the same time, you can no longer using this dialog change the association to the beta once it has been created for 3.6.2. There’s no error or anything; it just opens the file inside 3.6.2 instead. Maybe because both versions appear as “POV-Ray for Windows” to this dialog? Would adding the version number to the name fix things? Anything I can do on my end of things to resolve this?
2. In POV-Ray 3.6.2, I can use this dialog to open *.inc, *.txt and other files in POV-Ray, but only if POV-Ray isn’t already running. If POV-Ray is already running I get an “Only /EDIT and /RENDER may be passed to previous instance” error. Files with the *.pov extension open properly regardless, without any error. I am unable to test this in the beta at the moment due to the first problem unfortunately. Could someone please test this with the beta and confirm whether the behavior also exists?
3. With the POV-Ray 3.7 beta, entering the following command in the command prompt results in the same error:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
If I change it to the following it works however:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" /EDIT "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
Is this error/behavior really necessary? Would it be OK to instead change the behavior when the /EDIT flag is omitted in the command-line such that the file is opened in the editor by default, without throwing an error?
|
|
43 | Editor | Definite Bug | All | Very Low | Low | Commas in path name | Closed | |
3.70 RC7 |
Task Description
In POV-ray 3.7 beta 33 under Windows XP, the editor’s MRU list incorrectly handles files that have a comma in the pathname. Only the part of the name before the comma appears on the MRU list, but the rest of the name is left off. Consequently, the file cannot be reopened via the MRU list. The file is also not reopened on launch if pov was closed with the file open. This also occurs in 3.6.1, I haven’t tried it under 3.6.2 yet.
Interestingly enough, a quick peek in the registry shows that both 3.6 and 3.7 are saving the entire path name correctly under HKEY_CURRENT_USER\Software\POV-Ray\v3.6\POV-Edit\Recent (or \v3.7\POV-Edit\Recent).
This seems to be limited strictly to the editor’s MRU list. The file can still be opened normally using the open dialog box. Calling POV-ray from the command line and using a file or path name with commas in it works correctly. Included files with commas in the path work correctly, and the Tools→Edit last rendered file/View last rendered file work correctly also.
To duplicate, save a file with a comma in the pathname (either in the directory name or the filename itself). Close the file, then attempt to reopen it using the MRU list in the file menu.
|
|
274 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | Low | light source fading doesn't work properly with area_ill ... | Closed | |
3.70 release |
Task Description
When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:
#version 3.7;
global_settings {
assumed_gamma 1.0
mm_per_unit 10
subsurface { samples 200,20 }
}
camera {
right x*image_width/image_height
angle 30
location <0,1.5,-4>
look_at <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>]
}
}
}
plane {
y, 0
texture {
pigment {
checker
color rgb <1.0, 0.8, 0.6>
color rgb <1.0, 0.0, 0.0>
scale 0.5
}
}
}
light_source {
<50,50,50>
color rgb 30
area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
area_illumination on
fade_distance 10
fade_power 2
}
cylinder {
<0,0,0>, <0,0.2,0> 1
texture {
pigment { color rgb 1 }
finish {
ambient 0
diffuse 0.7
specular albedo 0.3
reflection { 0.3 fresnel }
conserve_energy
subsurface { translucency 0.1 }
}
}
interior { ior 1.5 }
}
sphere {
<0,0.4,0>, 0.2
texture {
pigment { color rgb <1,0.6,0.0> }
finish {
ambient 0
diffuse 0.0
specular albedo 0.8 metallic
reflection { 1.0 metallic }
conserve_energy
}
}
}
|
|
294 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | High | Thread safety issue in functions using splines. 3.7.0.R ... | Closed | |
3.70 release |
Task Description
Thread safety issue in functions using splines. 3.7.0.RC7.
First vetting in p.bugreports where several users were able to reproduce the fail on the following systems:
1) Ubuntu 12.1 i7 920 using 3.7.0.RC7 2) Ubuntu 12.04, AMD 2431 CPU, Linux 3.2.0-45 kernel using 3.7.0.RC7 (g++ 4.6 @x86_64-unknown-linux-gnu) 3) POV-Ray 3.7.0.RC7 (icpc 13.1.0 @x86_64-unknown-linux-gnu)
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
uname -or
2.6.32-279.14.1.el6.x86_64 GNU/Linux
lsb_release -irc
Distributor ID: CentOS
Release: 6.3
Codename: Final
4) Confirmed with openSUSE 12.2. 5) Just to add to the system list: with Windows and a core i7 one yields the same result. 6) “Le_Forgeron” ran under Intel Inspector (XE 2013) and provided this feedback :
...
that might be less than 60 seconds, but with Intel Inspector (XE 2013),
it becomes 42:50 (just 14 data races, oh well, that's just so friendly).
ID Type Sources Modules State
P1 Data race isosurf.cpp; mutex.hpp povray New
P2 Data race mutex.hpp; povms.cpp povray New
P3 Data race povray.cpp povray New
P4 Data race povray.cpp povray New
P5 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P6 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P7 Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
P8 Data race recursive_mutex.hpp; scene.cpp; task.cpp; taskqueue.cpp;
view.cpp povray New
P9 Data race condition_variable.hpp; vfe.cpp; vfesession.cpp povray New
P10 Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
povray New
P11 Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
povray New
P12 Data race unixconsole.cpp; vfesession.cpp; vfesession.h povray New
P13 Data race unixconsole.cpp; vfesession.cpp povray New
P14 Data race [Unknown]; unixconsole.cpp; vfesession.cpp
libboost_thread.so.1.49.0; povray New
Numbers 2, 3, 4, 8, 9, 10, 11, 12, 13 & 14 are related to the handling
of session (and occur once or twice only, excepted #8, four times).
Number 1 is about isosurface (adjusting gradient at isosurf.cpp:1099 vs
1098 (testing its value), and copying the isosurface) (IMHO, rendering
threads updating the object... not the best move without some
atomic/protection (and not sure a DBL is/can be atomic)) (occurs 2505
times).
Number 5, 6 and 7 are about splines
* sp->Cache_Type & Cache_Point, splines.cpp :803 vs :814/815 (2024 times)
* sp->Cache_Valid, :805 vs :813 vs :904 (1770 times)
* sp->Cache_Data, :807 vs :903 (5025 times)
Only my 0.02¢ (yes, very cheap), but it seems to confirm
For test code see attached files or SplineThreadSafety.pov attachment to p.bugreports and images were posted to p.b.images.
Issue shows up any time more than one thread is used. Use of AA tends to hide the problem so do not use it if using the output image for testing.
Thanks. Bill P.
|
|
304 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | #for-loop may fail to perform last iteration | Closed | |
3.70 release |
Task Description
Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:
#declare N = 2000000; #debug concat(”N = “,str(N, 0,50),”\n”) #debug concat(”N-5 = “,str(N-5,0,50),”\n\n”) #for (I, N-5, N, 1)
#debug concat("I = ",str(I,0,50),"\n")
#end
(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)
As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.
The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:
if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
((Step < 0) && (*CurrentPtr <= End - EPSILON)) )
which should instead be:
if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
((Step < 0) && (*CurrentPtr < End - EPSILON)) )
|
|
308 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Medium | Heightfield computation from color (not palette) red/gr ... | Closed | |
|
Task Description
Due to a recent thread in povray.general (7th September 2013), I dive into the code of height field creation.
There is 2 TODO in source/backend/support/imageutil.cpp, for image_height_at() (circa line 512)
The first one is about using the index of palette-image: As far as *257 would indeed perform a better job to cover the full range than *256, it would break backward compatibility with previous versions of povray (3.6 included) which only promoted the index as the Most significant byte, keeping the least one at 0.
But on the second one, the new formula is plain wrong: (r*255+g)*255 should be (r*256+g)*255. In previous versions, r*255 was the Most significant byte, and g*255 was the least one. Ergo, the value was r*255*256 + g*255, which can and should be only factored as (r*256+g)*255;
I know it is damn late in the release schedule, but can that be either be fixed before final official delivery or a memo added to the release note that it would be fixed later and backward-bug will not be maintained for that specific point (using rgb-8 or less bit per channel-image for height field)
(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit of 3.7 that would should that bug)
If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top. With 3.6, it matched exactly (hence the noise on the top pixels row) the view. With 3.7, it cannot reach the top and leave a white area (another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)
If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov
The white line at the bottom is expected, as the minimal value of the height field is “full green”
|
|
262 | Setup/Install | Definite Bug | 3.70 RC6 | Very Low | Low | sources are being compiled twice on Linux | Closed | |
3.70 release |
Task Description
When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe
-I../../vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp
This is especially annoying on platforms that are rather slow at compiling.
|
|
271 | Texture/Material/Finish | Definite Bug | 3.70 RC6 | Defer | Low | filter affects object's own brightness in an improper w ... | Closed | |
3.70 release |
Task Description
The following scene has four spheres with different pigment color & filter settings:
- Left: filter 1 - Right: filter 0
- Top: red 0.0 green 0.5 blue 1.0 - Bottom: red 0.00 green 0.05 blue 0.10 (10% of the above)
Background is set to black, so that we only see the diffuse component of the object’s effective color.
Theoretically, both left spheres should be invisible, as they are fully transmissive (with a filtering effect), but apparently with a high filter setting, reducing an object’s pigment color actually increases the object’s effective diffuse color.
//+w600 +h600
global_settings{ assumed_gamma 1.0 }
camera {
orthographic
location <0,0,-10>
right 4*x
up 4*y
look_at <0,0,0>
}
light_source{<10,10,-10> color rgb 1 parallel }
background { color rgb 0 }
default {
finish {
ambient 0
diffuse 1
specular 0
phong 0
reflection { 0.0 }
}
}
sphere { <-1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 1.0 } } }
sphere { < 1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 0.0 } } }
sphere { <-1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 1.0 } } }
sphere { < 1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 0.0 } } }
This bug has been around in 3.6 already.
|
|
315 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with quadrics | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with quadrics.
Left: a sphere primitive as reference Right: a sphere-shaped quadric primitive (sphere-shaped)
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the quadric’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = sphere { 0, 1 inverse }
#declare TopRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 }
#declare BottomRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-1,-1,-1>, <0,1,1> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
316 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with fractals | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with fractals.
Left: a sphere primitive as reference Right: a julia fractal
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the fractal’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = object { TopLeft inverse }
#declare TopRight = julia_fractal{ <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 20 scale 0.9 }
#declare BottomRight = object { TopRight inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-2,-2,-2>, <0,2,2> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
318 | Texture/Material/Finish | Definite Bug | 3.70 release | Very Low | Low | method 3 (default) scattering media is too bright & cau ... | Closed | |
3.71 release |
Task Description
The following scene demonstrates how media sampling method 3 gives inaccurate results with scattering media.
The scene shows four spheres with uniform media, using (left to right) sampling methods 1, 2 and 3 with default settings, and sampling method 3 with high minimum sample count, respectively.
Note how changing the sample count significantly affects the result, despite the media being uniform.
Code analysis shows that the root cause is an underestimation of the extinction effect on the light scattered by the media, corresponding in order of magnitude to half the distance between mandatory samples (as defined by minimum sample count).
The effect also leads to visible artifacts when nesting hollow objects inside the media, as can be demonstrated by un-commenting the four smaller spheres.
#version 3.7;
camera {
perspective angle 25
location <0.0 , 0.0 ,-20.0>
right x*image_width/image_height
look_at <0.0 , 0.0 , 0.0>
}
light_source {
<0,3000,-3000> color rgb 1
}
background { color rgb 0.5 }
plane {
<0,1,0>, -1
texture { pigment { checker color rgb<1,1,1>*1.2 color rgb<0.25,0.15,0.1>*0 } }
}
#declare T_Transparent = texture {
pigment { color rgbt <1,1,1,1> } finish { diffuse 1 }
}
sphere { <-3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 1
}
}
}
sphere { <-1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 2
}
}
}
sphere { <1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
}
}
}
sphere { <3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
samples 100
}
}
}
/*
sphere { <-3,0,0>,0.8 texture { T_Transparent } hollow }
sphere { <-1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 3,0,0>,0.8 texture { T_Transparent } hollow }
*/
|
|
336 | Parser/SDL | Definite Bug | 3.70 release | Very Low | Low | #fopen w/o OPEN_TYPE crash povray (segfault) | Closed | |
3.71 release |
Task Description
#fopen directive w/o OPEN_TYPE (yeah, I forgot it, some other languages have ‘read’ as default value)
expected behavior: Parse error msg “line XXX, OPEN_TYPE missing in #fopen directive”, then stop.
observed behavior: crash - Segfault err (core dump) in Parsing stage
minimal working example attached
|
|
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
|
|
258 | Editor | Definite Bug | 3.70 RC6 | Very Low | Low | backspace problem at start of line | Closed | |
3.70 RC7 |
Task Description
Using POV-Ray 3.7 RC6 64bit for Windows I have problems in the POV-Ray editor with ‘backspace’:
When using backspace at start of line it does not only kill the return/line feed, but also everything of the line what’s beneath the upper line.
Sample: (here ‘|’ is used for the current cursor position!)
//--------------------------------------
texture { pigment{ Red }
| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
hitting backspace results in:
//--------------------------------------
texture { pigment{ Red }| 0.5 scale 0.1 }
//--------------------------------------
and not as expected:
//--------------------------------------
texture { pigment{ Red }| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
With 3.6.2 and with RC3 (latest old beta I found on my computers) this was no problem!
I already reported this on 17-Sept-2012 at http://news.povray.org/povray.beta-test/thread/%3C5056f452%241%40news.povray.org%3E/
|
|
267 | Geometric Primitives | Definite Bug | 3.70 RC6 | Very Low | Medium | Bug in "sor" Primitive Leads to Random Black Artefacts ... | Closed | |
3.70 RC7 |
Task Description
Recently, I have been rendering an animation with POV-Ray 3.7 RC 6 using radiosity, photons and backside illumination. Many frames contained artefacts like in the attached image file. Trying to eliminate those artefacts I observed the following:
Rendering the same frame several times did not reproduce the artefacts or reproduced them differently. I.e., when I rendered a second (third, fourth, ...) time with +SF100 +EF100, the black space in the image was somewhere else or in some cases disappeared.
With radiosity turned off, no such artefacts have happened since, even in the scenes where they happened with radiosity turned on.
Turning off photons with radiosity still turned on did not remove the artefacts.
Rendering with one thread on one CPU core instead of two threads on two cores did not change anything except the rendering time.
Changing the radiosity settings I have not tried thoroughly, but at least raising or lowering count or error_bound does not seem to have any effect on this.
While POV-Ray was rendering, no other memory-intensive or CPU-intensive programs were running and POV-Ray itself did not report any error (just the usual warnings that some of the used features could change in future versions etc.). Render priotity was set to “high”.
|
|
244 | Texture/Material/Finish | Unimp. Feature/TODO | 3.70 RC5 | Very Low | High | Crand is disabled in 3.7 code | Closed | |
3.70 RC7 |
Task Description
Turns out the crand feature, which depends on a real random number generator (and hence has threading issues) was disabled early on during 3.7 development, and hasn’t been fixed yet. The code is commented out in line 2426/2427 of trace.cpp.
|
|
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.
|
|
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 ?
|
|
210 | Geometric Primitives | Definite Bug | 3.70 RC3 | Low | Medium | UV mapping broken for parametric | Closed | |
3.70 RC4 |
Task Description
UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.
In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.
camera {
location <0.0, 1.5, -3.0>
direction 1.5*z
right x*image_width/image_height
look_at 0
}
light_source { <-30, 30, -30> color rgb 1 }
#declare Param = parametric {
function { u*v*sin (15*v) },
function { v },
function { u*v*cos (15*v) }
0, 1
contained_by { box { -1,1 } }
accuracy 0.002
precompute 15 x,y,z
rotate 180*x
translate <0.3,0.5,0>
}
object {
Param
uv_mapping
texture {
pigment {
gradient x frequency 3
color_map {
[0 color red .5 ]
[1 color red 1 ]
}
}
}
}
object {
Param
uv_mapping
texture {
pigment {
gradient x frequency 7
color_map {
[0 color green .5 ]
[1 color green 1 ]
}
}
}
rotate y*180
}
POV-Ray 3.62 renders the scene properly.
As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.
|
|
213 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing check for ios failbit/badbit: endless loop whil ... | Closed | |
3.70 RC4 |
Task Description
Hello,
this bug report relates to this thread: http://news.povray.org/povray.beta-test/thread/%3Cweb.4e0064d9a3970d212b256d410%40news.povray.org%3E/
In /unix/unixoptions.cpp around line 817:
while ( !Stream.eof() )
{
// get and preprocess line
std::getline(Stream, line);
line = pre_process_conf_line(line);
++line_number;
// skip empty line
if(line.length() == 0)
continue;
[...]
}
`Stream.eof()` could never be true as well as `line.length()` always can be zero, leading to an endless loop. In my case, the problem occurred due to my ~/.povray/3.7/povray.conf being a directory instead of a file.
To fix the problem, one has to consolidate this loop by not only checking for eofbit, but also for failbit and badbit of `Stream`. The getline() method on a directory does not set the eofbit, but it sets fail and bad (test: http://codepad.org/RiZGo3ia). According to http://www.cplusplus.com/reference/iostream/ios/operatornot/ fail and bad can be checked for by `!Stream`. A simple `if (!Stream) break;` within the loop fixes the problem (patch file attached).
Are there more missing checks on iostreams like this in the code? :) They should definitely be fixed.
Furthermore, one could think about using the boost filesystem library to be able to distinguish files and directories to provide good error messages.
Hope that helps,
Jan-Philip Gehrcke
|
|
215 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Double Error Reporting | Closed | |
3.70 RC4 |
Task Description
Certain types of errors are being reported twice. For example:
Parse Error: Expected ‘numeric expression’, } found instead Parse Error: Expected ‘object’, undeclared identifier ‘foo’
The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.
During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>
Verified on linux and windows platforms.
|
|
216 | Sample scenes | Definite Bug | 3.70 RC3 | Very Low | Low | raddem.ini is not parsable by 3.7RC3 | Closed | |
3.70 RC4 |
Task Description
in the sample scenes, animations/raddem/raddem.ini is not parsable by current versions of povray. (3.7RC3 and upto #5476)
Radiosity= is a gone away option.(from a bit of time in the 3.7 branch)
|
|
221 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Undefined looks_like object causes hard crash | Closed | |
3.70 RC4 |
Task Description
The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:
light_source {
<0, 0, 0>
color rgb 0.5*<1,0.905882,0.211765>
fade_distance 500
fade_power 1.6
looks_like {_3024_dot_dat texture {
pigment { rgbf <1,0.905882,0.211765,0.90> }
finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
reflection 0.9
refraction 1 ior 1.25
}
}
} }
|
|
225 | Light source | Definite Bug | 3.70 RC3 | Very Low | Low | translating a light source fails to translate looks_lik ... | Closed | |
3.70 RC4 |
Task Description
The following scene reders differently with POV-Ray 3.7.0.RC3 than with POV-Ray 3.6.2:
camera
{
right x*image_width/image_height
location <0, 0, -5>
look_at <0, 0, 0>
}
light_source
{
<0,0,0>
color rgb 1
looks_like
{
box {
<-1,-1,-0.1>, <1,1,0.1>
pigment { wood }
finish { ambient 5.0 diffuse 0 specular 0 phong 0 reflection 0 }
scale 0.5
}
}
translate <1,0,0>
}
plane
{
<0, 1, 0>, -1
texture
{
pigment { color rgb <0.5, 0.5, 0.55> }
finish { specular 1.0 }
}
}
See attachments for the output. As can be seen, POV-Ray 3.7 does translate the shape of the looks_like object along with the light source, but fails to translate the textures.
|
|
235 | Platform-specific | Definite Bug | 3.70 RC3 | Very Low | High | Segmentation fault with animation of large image | Closed | |
|
Task Description
Hopefully platform specific, other ports are welcome to check their scaling code.
Reported originally in p.beta-test (28 january 2012) by Cousin Ricky (email dropped)
Symptom: crash on start of second frame rendering Environment: Unix, with display of rendered picture, rendered picture does not fit at 1:1 on the display
Demo (adjust the H/W to your setting to get them larger, both or any of them):
global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }
povray +H2000 +W2000 +KI0 +KF1 +KFI0 +KFF10 code.pov
|
|
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.
|