|
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
|
|
260 | Configure/Build | Compatibility Issue | 3.70 RC6 | Very Low | Low | Patch to let POV-Ray builds with boost >=1.50 | Closed | |
|
Task Description
Originally resolved in https://bugs.gentoo.org/show_bug.cgi?id=425450. Attached is a patch with Gentoo-specific code removed.
There are two parts in this issue:
The newer boost library requires downstream users to explicitly link to the boost system library (-lboost_system).
The newer boost library replaced TIME_UTC with TIME_UTC_, because glibc added TIME_UTC.
|
|
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.
|
|
263 | Parser/SDL | Feature Request | 3.70 RC6 | Very Low | Low | Functions and patterns for finish variations | Tracked on GitHub | |
|
Task Description
the pigment {} and normals {} sections allow spatial variation of color, transparency and normal map. On the other hand, the specular parameter is a fixed scalar. This removes many possibilities. For instance, specularity could vary in space (speckles of oil or water on a surface, worn-out finish, having specularity reduce where the pigment transparency increases) and have color components. With current settings, the light’s color is simply multiplied by the scalar specified by “specular”, whereas multiplying each component with different color could create diverse effects (the “metallic” keyword already acts similar to duplicating the specular color from the pigment). The syntax could be exactly the same as for the pigment (all the patterns, color maps, image maps and functions would apply, allowing reuse of most of the code).
The effect can now be partially faked by having patterned textures, but it requires a very complex code and the lack of layering of patterned textures makes it difficult to vary the specularity and pigment separately.
In a similar way, roughness and brilliance could also vary in space.
Doing the same for varying reflectivity would be more difficult, as it has angular dependence and possibilty of Fresnel calculation, but it could at least be a full color instead of a simple scalar multiplier. For instance, having a blue surface that reflects only red component of the light should not be impossible.
I think at least part of this functionality actually makes the scene description language more uniform and self-consistent.
|
|
264 | Photons | Unimp. Feature/TODO | 3.70 RC6 | Defer | Low | Improve precision of photon direction information | Tracked on GitHub | |
|
Task Description
In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:
latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)
For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using
LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;
dirCode = LatBase[latCode] + lngCode;
For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.
|
|
265 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | Warnings from clang that might need consideration | Closed | |
|
Task Description
Compiling the sources with clang instead of g++ (on ubuntu 12.10 with boost 1.50)
./configure COMPILED_BY=”your name here <also@email>” LIBS=-lboost_system –disable-io-restrictions CC=clang CXX=clang
there is a few warnings that catch the eyes (and other as well that I dismiss so far, such as cases not covered in switch and empty body in if, or extraneous parentheses in tests):
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
support/randomsequences.cpp:974:40: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<int>::PrecomputedNumberGenerator' requested here
SeedableIntGeneratorPtr generator(new PrecomputedIntGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:984:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<double>::PrecomputedNumberGenerator' requested here
SeedableDoubleGeneratorPtr generator(new PrecomputedDoubleGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:1011:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector3d>::PrecomputedNumberGenerator' requested here
return SequentialVectorGeneratorPtr(new PrecomputedVectorGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:1056:45: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector2d>::PrecomputedNumberGenerator' requested here
return SequentialVector2dGeneratorPtr(new PrecomputedVector2dGenerator(factory, count));
Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).
povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete nodeptr->handleroo;
^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete nodeptr->handler;
^
Maybe just a missing keyword (virtual) in the header file ? Or is it harder ?
shelloutprocessing.cpp:260:28: warning: expression result unused [-Wunused-value]
for (s = str.c_str(); *s; *s++)
^~~~
Why “*s++” ? why not just “s++” ?
renderfrontend.cpp:1165:57: warning: trigraph ignored [-Wtrigraphs]
default: t = "(???)"; break;
I guess it’s not an intended trigraph. Might nevertheless perturb some compiler/result.
|
|
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.
|
|
268 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | "naked" pigment statement does not properly override pr ... | Closed | |
|
Task Description
A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
pigment { checker color red 1 color blue 1 scale 1.0 }
}
the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
texture {
pigment { checker color red 1 color blue 1 scale 1.0 }
} }
which behaves as expected.
The issue has been around at least since POV-Ray 3.6.2.
|
|
269 | Texture/Material/Finish | Possible Bug | 3.70 RC6 | Very Low | Low | Transparent Objects inside Media Cause Artefacts | Tracked on GitHub | |
|
Task Description
When placing a transparent object inside another object which contains media, artefacts may occur (see attached file). They look similar to specular highlights or are just strange white spots in the image.
I discovered artefacts of that kind first in the image of which MediaArtefactDetail.png is a cropped part. The code I managed to reproduce such artefacts with contained a “starfield” sphere
sphere {
<0,0,0>, 1
pigment { rgbt 1 }
interior {
media {
emission rgb 1/10
density {
crackle form <1,0,0>
density_map {
[0.0 rgb 1]
[0.05 rgb 0]
}
scale 0.002
}
}
}
scale 1000
hollow on
}
and a transparent sphere
sphere {
<0,0,0>, 1
pigment { rgbt 1 }
scale 2
hollow on
}
which is, obviously, completely inside the other sphere. So is the camera.
Since the sphere has a pigment { rgbt 1 }, it should be completely invisible, which is correctly rendered as long as the scaling factor is 1 and hollow off (MediaArtefact1.png). Changing hollow to on does not yet produce the artefact, but the right half of the output image seems to be shifted by one pixel (MediaArtefact2.png). Changing the scaling factor to 2 (as it is in the above code) produces the artefact (MediaArtefact3.png). Changing the camera location (MediaArtefact4.png) does not change anything, the artefact just “moves with the sphere”. Changing the sphere size again, however, seems to stir up the “stars” in the “starfield” sphere while not removing the artefacts (MediaArtefact5.png). Changing hollow to off again does neither (MediaArtefact6.png).
The artefacts are definitely no specular highlights. There is not even a light source in the scene that could produce any. I used POV-Ray 3.7 RC6 to render the images, but the artefact shown in MediaArtefactDetail.png already occured in POV-Ray 3.6 which I used to render that image.
|
|
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.
|
|
272 | Other | Feature Request | 3.70 RC6 | Defer | Very Low | Minor change, significant speedup in cubic polynomial s... | Tracked on GitHub | |
3.71 release |
Task Description
While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.
In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).
solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.
I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).
These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].
This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.
The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).
|
|
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.
|
|
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!)
|
|
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.
|
|
218 | Sample scenes | Definite Bug | 3.70 RC3 | Very Low | Critical | Benchmark must be updated to not reference a #local arr ... | Closed | |
|
Task Description
Lines 1217, 1241 and 1242 of benchmark.cpp must be change to use #declare instead of local for A and its elements. (because A is returned by the macro)
"#macro L_GetVN(ResSpl)\n"
" #local I = 0;\n"
" #declare A = array[ResSpl+1][2]\n" // <============== this is line 1217
" #while (I<=ResSpl)\n"
" #local P0 = 0+<FnA(I/ResSpl), I/ResSpl, 0>;\n"
" #if (P0.x=0 & P0.z=0)\n"
" #local P0 = <1e-25,P0.y,1e-25>;\n"
" #end\n"
" #if (I=0)\n"
" #local P1 = 0+<FnA(((I-0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #else\n"
" #local P1 = P2;\n"
" #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
" #end\n"
" #local P3 = vrotate(P0,<0,1,0>);\n"
" #local P4 = vrotate(P0,<0,-1,0>);\n"
" #local B1 = P4-P0;\n"
" #local B2 = P2-P0;\n"
" #local B3 = P3-P0;\n"
" #local B4 = P1-P0;\n"
" #local N1 = vcross(B1,B2);\n"
" #local N2 = vcross(B2,B3);\n"
" #local N3 = vcross(B3,B4);\n"
" #local N4 = vcross(B4,B1);\n"
" #local N = vnormalize((N1+N2+N3+N4)*-1);\n"
" #declare A[I][0] = P0;\n" // <============== this is line 1241
" #declare A[I][1] = N;\n"
" #local I = I+1;\n"
" #end\n"
" A\n"
"#end\n"
Same update should also be reported into the distributed scene benchmark.pov
|
|
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.
|
|
217 | Other | Possible Bug | 3.70 RC3 | Very Low | High | raddem.ini with +C and some frames already done: failur ... | Closed | |
|
Task Description
How to do it: (with raddem.ini & raddem.pov from distributed scenes, copied in local directory)
1. run “povray raddem.ini” until frame 6 or more (irrelevant, at least frame 1 & 2 are needed), interrupt the render. 2. restart “povray raddem.ini +C”
It fails at frame 2 with Possible Parse Error: Cannot find file ‘raddem.pov’, even after trying to append file type extension. Parse Error: Cannot open input file. Fatal error in parser: Cannot parse input. Render failed
The detection of frame 1 is fine.
|
|
227 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 RC3 | Very Low | High | Fixed Vector Limitations | Tracked on GitHub | |
|
Task Description
See this documentation entry for more details.
|
|
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
|
|
195 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Medium | povray-3.7.0rc3 incompatible with NetBSD | Closed | |
|
Task Description
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe) 2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable. 3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix). 4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3. 5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is #ifdef HAVE_SYS_WAIT_H # include <sys/wait.h> #endif but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html. Backtrace is Program terminated with signal 11, Segmentation fault. #0 0x00000000004ac479 in boost::gregorian::date::date () (gdb) bt #0 0x00000000004ac479 in boost::gregorian::date::date () #1 0x00000000004d29f7 in boost::gregorian::date::date () #2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= () #3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= () #4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= () #5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName () #6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName () #7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName () #8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= () #9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>) at /archive/cvs/src/lib/libpthread/pthread.c:473 #11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
|
|
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);
|
|
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
|
|
228 | Texture/Material/Finish | Possible Bug | 3.70 RC3 | Very Low | Medium | Emission Media does not show on Alpha background | Closed | |
|
Task Description
I tried to render a candle’s flame (an object with interior made of emission media) against an Alpha background. In 3.6, the “flame” appears as a bright object against the alpha background; but in 3.7, the flame disappears against the alpha (as the attached scene will make clear, the “flame” is still visible against opaque background objects). I used the settings “Output_Alpha=true Output_File_Type=N”.
If there is another (better?) way to achieve a similar effect, I am open to using a work-around.
|
|
236 | Animation | Possible Bug | 3.70 RC3 | Very Low | Medium | Segmentation fault with animation of large image | Closed | |
|
Task Description
If the image is more than 1270 pixels wide or more than 720 pixels high, animation fails with a segmentation fault during the second rendered frame. This happens after parsing is complete and the .pov-state file is created. The last message line is the “[Rendering...]” line. (There is also a separate, but possibly related, issue that the output display does not work for these renders.)
On one occasion, POV-Ray hung, and I had to ctrl-Z kill -9 out of it.
On another occasion, instead of the segmentation fault, I got the message:
povray: xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed.
Aborted
There is no crash when -D is used.
I have not run an animation this large in Windows, so I don’t know if it’s a problem there.
Neither problem occurs in POV-Ray 3.6.1.
I used the following source code:
global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }
Operating system: openSUSE Linux 12.1 Hardware: HP Pavilion dv5030us Notebook PC (32 bits) RAM: 1GB Displays: 1280×800 built-in panel; 1680×1050 HP w2007 external monitor
Libraries
Boost 1.48.0 (Note: bzip2 and python dependent modules did not compile, and MPI support does not work.) Zlib 1.2.5 (LibXML 2.7.8) LibPNG 1.5.7 LibJPEG IJG 8d LibTIFF 3.8.2 OpenEXR 1.6.1 (IlmBase 1.0.1) SDL unknown
|
|
194 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | command line parse error | Closed | |
3.70 RC4 |
Task Description
povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.
|
|
196 | Subsurface Scattering | Definite Bug | 3.70 RC3 | Very Low | Low | More SSLT Caveats | Tracked on GitHub | |
Future release |
Task Description
when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.
|
|
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.
|
|
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.
|
|
202 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Numerical oddities in Julia_Fractal | Tracked on GitHub | |
|
Task Description
I understand that some things have changed in the way certain computations in POV-Ray decide when something is “good enough” and I think this is biting me in Julia_Fractal (where, of course, the highest-resolution computations are needed).
The bug has been posted here:
http://news.povray.org/povray.bugreports/thread/%3Cweb.4dbf2e26b56a53c15b4449250%40news.povray.org%3E/
Including a short .pov file and instructions that reproduce it.
(It pops up in other configurations and view angles as well, but this one captures in in a way that makes it clear it’s a bug: the distance of the camera from the origin appears to change the shape of the rendered object).
This appeared first on a Windows Server 2003 machine, it is apparently confirmable on at least one other system as per that thread.
|
|
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.
|
|
205 | Documentation | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Low | Syntax documentation uses inconsistent notation | Tracked on GitHub | |
|
Task Description
The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.
|
|
206 | Other | Possible Bug | 3.70 RC3 | Very Low | Low | "Cannot open file" error when text output files specifi... | Tracked on GitHub | |
3.71 release |
Task Description
I created an INI file which specifies the Input_File_Name, Output_File_Name, and also the Render_File and the remaining four text outputs as double-quoted absolute paths on my disk. When I run the render, I get the following output:
Preset INI file is ‘C:\USERS\TPREAL\DOCUMENTS\POV-RAY\V3.7\INI\QUICKRES.INI’, section is ‘[512×384, No AA]’. Preset source file is ‘D:\Ruby\POV-Rb\ini\20110521_004037_Noix.ini’. Rendering with 2 threads. - Cannot open file. Render failed - CPU time used: kernel 0.06 seconds, user 0.02 seconds, total 0.08 seconds. Elapsed time 0.52 seconds.
And the render does not start. The five text output files are not even created, and where the output image should be, there is a file with extension pov-state. The render works as it should only when I remove all five lines defining the five text output files. The paths I specify for the files are correct (paths exist and files do not, no white-spaces or anything), read/write restrictions are disabled in POV-Ray. This used to work in 3.6 and does not work now in 3.7 RC3. The error happens no matter if I run the render using GUI or command line.
(Also please note that the error message is really not useful here, it does not say which file it failed to open, and not even if it was an attempt to open for read or for write.)
I’d be really glad if you could correct this as it’s a critical functionality for me. I’m generating the POV-Ray code automatically and I need to parse the text output automatically to return the status to the generator.
|
|
207 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Attempted to redefine float identifier as function ide ... | Closed | |
Future release |
Task Description
#macro A()
#local f = function { x }
#end
#local f = 1;
A()
This gives:
File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
function identifier.
The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.
For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:
#include "transforms.inc"
#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );
The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:
// Do NOT allow to redefine functions! [trf]
// #declare foo = function(x) { x }
// #declare foo = function(x) { foo(x) } // Error!
// Reason: Code like this would be unreadable but possible. Is it
// a recursive function or not? - It is not recursive because the
// foo in the second line refers to the first function, which is
// not logical. Further, recursion is not supported in POV-Ray 3.5
// anyway. However, allowing such code now would cause problems
// implementing recursive functions after POV-Ray 3.5!
In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.
|
|
211 | Image format | Feature Request | 3.70 RC3 | Very Low | Low | Fill blank space with pixels on quit rendering | Closed | |
|
Task Description
It would be nice when quitting a render if the remaining space were filled with empty pixels. That way the partial render will still be viewable in all image apps.
|
|
212 | User interface | Feature Request | 3.70 RC3 | Very Low | Low | Next beta: new desktop icon | Closed | |
|
Task Description
For the next beta version, could you please create a new desktop icon? I keep clicking on the wrong version.
|
|
214 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | Failed to parse command-line option in Debian | Closed | |
3.70 RC4 |
Task Description
I tried to use 3.7 RC3. This was my first time with 3.7.
I got source, configured and compiled it and installed into Debian with checkinstall. And then I tried to use it. First run was with -benchmark (it took about 9 minutes, ok). Then I tried very simple scene:
rekcahx@oah:~/pov$ povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Failed to parse command-line option
I tried to debug with strace:
rekcahx@oah:~/pov$ strace -o debug.strace povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (g++ 4.6.1 @ x86_64-unknown-linux-gnu) This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Primary POV-Ray 3.7 Architects/Developers: (Alphabetically)
Chris Cason Thorsten Froehlich Christoph Lipka
With Assistance From: (Alphabetically)
Nicolas Calimet James Holsenback Christoph Hormann Nathan Kopp
Juha Nieminen
Past Contributors: (Alphabetically)
Steve Anger Eric Barish Dieter Bayer David K. Buck
Nicolas Calimet Chris Cason Aaron A. Collins Chris Dailey
Steve Demlow Andreas Dilger Alexander Enzmann Dan Farmer
Thorsten Froehlich Mark Gordon James Holsenback Christoph Hormann
Mike Hough Chris Huff Kari Kivisalo Nathan Kopp
Lutz Kretzschmar Christoph Lipka Jochen Lippert Pascal Massimino
Jim McElhiney Douglas Muir Juha Nieminen Ron Parker
Bill Pulver Eduard Schwan Wlodzimierz Skiba Robert Skinner
Yvo Smellenbergh Zsolt Szalavari Scott Taylor Massimo Valentini
Timothy Wegner Drew Wells Chris Young
Other contributors are listed in the documentation.
Support libraries used by POV-Ray:
ZLib 1.2.3.4, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.44, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 62, Copyright 1998 Thomas G. Lane
LibTIFF 3.9.5, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.46, http://www.boost.org/
OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.
Parser Options
Input file: aa.pov
Remove bounds........On
Split unions.........Off
Library paths:
/usr/share/povray
/usr/share/povray/ini
/usr/share/povray/include
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....320 by 240 (rows 1 to 240, columns 1 to 320).
Output file..........aa.png, 24 bpp PNG
Dithering............Off
Graphic display......Off
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
[Parsing...]
Parse Warning: This scene did not contain a #version directive. Please be aware that as of POV-Ray 3.7, unless already specified via an INI option, a #version is expected as the first declaration in a scene file. POV-Ray may apply settings to some features that are intended to maintain compatibility with pre-3.7 scenes. You are strongly encouraged to add a #version statement to the scene to make your intent clear. Future versions of POV-Ray may make the presence of a #version statement mandatory.
Parser Statistics
Finite Objects: 1 Infinite Objects: 0 Light Sources: 1 Total: 2
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
—————————————————————————- Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........Off
[Rendering...]
Rendered 76800 of 76800 pixels (100%)
Render Statistics Image Resolution 320 x 240
Pixels: 76800 Samples: 0 Smpls/Pxl: 0.00 Rays: 76800 Saved: 0 Max Level: 1/5
Ray→Shape Intersection Tests Succeeded Percentage
Box 78226 1426 1.82
Shadow Ray Tests: 1426 Succeeded: 0
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 0 seconds (0.016 seconds)
using 4 thread(s) with 0.036 CPU-seconds total
POV-Ray finished
—
Every now and then all other command line options than –version, -version, -V, –help, -help -h, -?, –benchmark and –benchmark without leading strace in command line produces “Faild to parse command-line option” error.
My system: ebian GNU/Linux unstable (sid), quadcore AMD Phenom 2.6 GHz, 8GB ram. Povray: rekcahx@oah:~/pov$ povray –version povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. POV-Ray 3.7.0.RC3
This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Built-in features:
I/O restrictions: disabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.6.1
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
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)
|
|
219 | Documentation | Possible Bug | 3.70 RC3 | Very Low | Low | Panoramic camera broken & obsolete | Closed | |
3.70 RC4 |
Task Description
According to the docs, the panoramic camera...
[...] uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle.
However, current implementation differs (and probably always has): The angle keyword has no effect, and the effective viewing angle is fixed to 180 degrees. Also note that this behaviour is identical to the spherical camera with angle 180,180, making the panoramic camera obsolete.
I propose to deprecate the “panoramic” keyword; should the keyword be encountered in a camera block, the code for the spherical camera should be used instead, except that the angle setting should be forced to 180,180; this should be accompanied by a parse warning.
|
|
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
}
}
} }
|
|
222 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | incorrect render of CSG merge with radiosity | Tracked on GitHub | |
Future release |
Task Description
The problem arises when I am trying to trace a radiosity scene without conventional lighting that has a GSG merge object. There are a coincident surfaces, but these surfaces are first merged, then the texture applied. The texture is a simple solig color non-transfluent pigment, default normal, default finish etc..
Problem consists when adding antialiasing, changing resolution, changing camera view-point etc.; when I replace merge with union, the problem disappeared.
The scene was checked on two different machines with different versions of POV-Ray:
Gentoo Linux, kernel 2.6.39-r3, i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel, 2G RAM (this is Dell PowerEdge 2650 server with 2 dual-core Intel Xeon MP processors); Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (i686-pc-linux-gnu-g++ 4.5.3 @ i686-pc-linux-gnu)
Gentoo Linux, kernel 2.6.37-r4, x86_64 AMD Athlon™ X2 Dual Core Processor BE-2350, 2G RAM (non-branded machine); Persistence of Vision™ Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++ 4.4.4 @ x86_64-pc-linux-gnu)
(scene has been adapted slightly to be rendered with 3.6, the adaptation was to change “emission” with “ambient” and replace gamma “srgb” with “2.2”)
Both machines generate similar images.
The attachment is an archive containing sources of minimal scenes with these problems, and sample pictures I generated from them on my machines.
|
|
223 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Artifacts in thin torus | Closed | |
|
Task Description
Thin tori exhibit artifacts in 3.7.0 RC3 when the camera is placed inside the torus close to its “center plane”, as can be demonstrated with the following scene:
camera {
location <0.0, 0.0, -0.5>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
angle 1
}
light_source { <-30, 30, -30> color rgb 1 }
torus {
1, 0.001
texture { pigment { color red 1 } }
}
|
|
224 | Editor | Compatibility Issue | 3.70 RC3 | Very Low | Low | Keyword Completion does not work for several names | Closed | |
3.70 release |
Task Description
Keyword Completion does not work for several names. I miss it for animation related names like frame_number or final_frame.
Typing “fram{TAB}” just inserts a TAB character after “fram” instead of completing it to frame_number.
Independently of that bug, typing {TAB} repeatedly does not cycle through possible names: “fr{TAB}” gives “frequency” and “fresnel” and that’s all.
In version 3.6 it worked well.
My system is Windows 7 64bit and PovRay is 3.7.0.RC3.msvc9.win64
|
|
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.
|
|
226 | Geometric Primitives | Possible Bug | 3.70 RC3 | Very Low | Low | Near-coincident surface accuracy | Tracked on GitHub | |
|
Task Description
This is a transparent box very close to a plane.
box {
-1, 1
pigment { rgbf <0, 0, 1, 1> }
}
plane {
#if (version < 3.7)
y, -1.0000007
#else
y, -1.00007
#end
pigment { rgb 1 }
finish { ambient 1 }
}
camera {
location <1, 2, 3>
look_at 0
}
The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).
So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)
|