|
145 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Stack trace report on error | Tracked on GitHub | |
|
Task Description
In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.
Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.
Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.
Not sure how much of this is achievable in Povray.
|
|
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
|
|
325 | Subsurface Scattering | Possible Bug | 3.70 release | Very Low | Medium | SSLT Glow issue with radiosity | Closed | |
|
Task Description
Hi,
I think I may have found a bug in the subsurface/radiosity features of Povray 3.7 attached image showing the issue and sample files required to reproduce. The original files (on povray forum images thread) had different radiosity settings but these ones show the problem and only take a few seconds to render the image without AA so probably better for bug fixing/testing etc.
Thanks
Sean
|
|
17 | Texture/Material/Finish | Possible Bug | 3.70 beta 32 | Very Low | Low | square blotches in transparency | Closed | |
3.70 beta 33 |
Task Description
There can be square (32×32) blotches in partially transparent objects.
global_settings {
max_trace_level 10
}
camera {
location <-30,10,5>
look_at <0,0,0>
angle 25
}
light_source {
<-100,30,70>
rgb 1
}
difference { // make a dome
sphere { <0,0,0> 5 } // ball
sphere { <0,0,0> 4.9 } // hollow interior
box { <-6,-6,-6> <6,1,6> pigment { rgb <0,0,0> }} // chop off bottom half
pigment { rgbt <1,1,1,0.675> }
}
box {
<-6,-6,-6>, <6,0.99,6>
pigment { rgb <1,1,1> }
rotate <0,45,0>
} // sit it on a box
|
|
81 | Geometric Primitives | Definite Bug | 3.62 | Very Low | Medium | sphere_sweep generating artifacts | Tracked on GitHub | |
|
Task Description
I’m running POV-Ray for (64 bit) Windows v3.62 on (64 bit) Windows Vista
This pov file:
#include "colors.inc"
#include "metals.inc"
light_source { <6, 9, -21> color White }
camera { location <0, 0, -3> look_at <0, 0, 0> }
sphere_sweep {
cubic_spline
6
<-2.0, 0, 0> 0.05
<0.000,0,0> 0.2
<0.025,0,0> 0.2
<0.050,0,0> 0.2
<0.075,0,0> 0.2
<3.0,0,0> 0.2
pigment { color White }
}
Produces two strange artifacts: A disk at the center of the sweep, and a faint “halo” or veil which shows as 4 faint hyperbolas centered around the origin.
I have tried tweaking tolerance (for no other reason than I saw that someone else was tweaking it to solve a problem) but this does not seem to change things.
For a look at MY result when I run this, view this image:
Alain reports the same behavior in the latest version: “It’s still there with the latest version: 3.7 beta 35a.” This MAY move the status to “confirmed”, but I can’t do that
Someone else says that changing the scale (!) “solves” the problem by moving the disk and the halo offscreen, but that sounds like a bad idea to me.
-Jeff Evarts, first-time POVRay bug reporter
|
|
92 | Geometric Primitives | Definite Bug | 3.70 beta 36 | Low | High | Sphere_Sweep Bug | Closed | |
3.70 beta 37 |
Task Description
This item may need to be merged with item FS#81. This is another sphere sweep bug, though they are of different spline types.
The code is
#include "colors.inc"
camera {
location <0, 0.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
#declare i_start = 0;
#declare i_stop = 3;
#declare i_step = 0.05;
#declare i_inc = i_start;
sphere_sweep {
linear_spline // linear curve
(i_stop - i_start)/i_step + 1, // number of specified sphere positions
#while(i_inc<=i_stop)
#declare y_coor = 0.23*sin(7.1*i_inc);
<i_inc, y_coor, 0>, 0.05
#declare i_inc = i_inc + i_step;
#end
pigment{color Orange}
}
|
|
243 | Geometric Primitives | Unimp. Feature/TODO | All | Defer | Low | Sphere sweep behaves wrong when scaled | Tracked on GitHub | |
Future release |
Task Description
The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.
The effect is present for all three types of splines.
I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.
I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.
|
|
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.
|
|
91 | Texture/Material/Finish | Feature Request | 3.70 beta 36 | Defer | Low | Slope pattern applied to object is not transformed afte... | Tracked on GitHub | |
Future release |
Task Description
There is an big issue with the slope pattern: when the object it is applied to is instanced (again) with a transformation (in particular a rotation, as a translation would not impact.. but a shear might), the colours of the surfaces are changed.
object { p translate -5*x }
object { p rotate 220*y+20*x translate 3*x }
Nobody would expect the object to be different in appearance. If slope {} is replaced with wood, all is fine. (as for others textures, i guess)
IMHO, the slope vector need to be adjusted for the later transformation(s) (so as to compensate the issue of using the Perturbed Normal vector).
This should not impact the AOI/FACING (experimental) patterns, as AOI definition is pretty clear about duplicating & transform if you think about it a bit, as well as FACING: for these two, it is expected to either use the ray(current point of view) or a fixed 3D point as reference. At the limit, discussion about moving the 3D point of FACING might also be opened to interpretation.
AOI/FACING are in task #19
|
|
247 | Other | Feature Request | 3.70 RC6 | Very Low | Low | Set no_radiosity in Screen_Object() | Closed | |
Future release |
Task Description
Suggestion:
In file screen.inc, have macro Screen_Object() set no_radiosity on the object.
|
|
62 | Geometric Primitives | Feature Request | Not applicable | Very Low | Low | Set and get font metrics | Closed | |
|
Task Description
Add a way to get and set font metrics.
Attached an image that shows what I’m talking about.
Thanks!!
|
|
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
|
|
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
|
|
253 | Backend | Possible Bug | 3.70 RC6 | Very Low | Low | Segmentation fault | Closed | |
|
Task Description
I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.
I’ve been dismissing them up until now wanted to speak up because I finally got this crash:
29623 Segmentation fault
Here’s some observed behaviors:
In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.
I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?
No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.
Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.
Any comments ... ideas ... suggestions?
|
|
189 | Parser/SDL | Possible Bug | 3.70 RC1 | Very Low | Low | segmentation fault | Closed | |
|
Task Description
I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.
FYI: I did a build off the depot last evening.(21:13)
|
|
276 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Medium | SDL Access to Spline Derivatives | Closed | |
|
Task Description
I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.
In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.
I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)
Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).
|
|
251 | Parser/SDL | Possible Bug | 3.70 RC6 | Very Low | Medium | Scene / include files of >2GB size may cause problems | Tracked on GitHub | |
3.71 release |
Task Description
Code inspection shows that we’re still using fseek() and ftell() in various places (including text file input), which can’t handle file positions of 2GB and beyond (except on 64-bit linux machines); those calls need to be examined and (where appropriate) replaced with the fseek64() macro we’re already defining (but currently not using), and a to-be-defined ftell64() macro.
One potential (untested) error scenario would be a scene file calling a macro that is defined at the end of a > 2GB long include file.
|
|
110 | Sample scenes | Definite Bug | 3.70 beta 37a | Very Low | Low | Sample Lathe Scenes no Longer work in 3.7 | Closed | |
3.70 beta 38 |
Task Description
The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.
<3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
Although it works in version 3.6, only in 3.7 does a render time error ocurr.
Scene source should be adjusted to the following
<3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
|
|
135 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | Right-click menu when clicking on editor tab | Closed | |
3.70 beta 38 |
Task Description
When right-clicking on a tab in the editor window a list of options should appear, such as:
* Close * Close all but this * Save * Save as * Print
See Notepad++, EditPad Lite, and Firefox for examples.
|
|
326 | Other | Definite Bug | 3.70 release | Very Low | Low | restricted setting ignored in 3.7 | Tracked on GitHub | |
|
Task Description
Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.
Fixing this reveals some other issues:
%INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc , not /usr/local/etc
read+write paths are added to the read list only, so writing is impossible
See attached patch.
Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc .
Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.
|
|
75 | Geometric Primitives | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Medium | Replace POV_MALLOC with std::vector in shape code | Tracked on GitHub | |
Future release |
Task Description
In the files bezier.cpp, fpmetric.cpp, fractal.cpp, hfield.cpp, isosurf.cpp, lathe.cpp, poly.cpp, polygon.cpp, prism.cpp, sor.cpp, and sphsweep.cpp the use of POV_MALLOC can be replaced by std::vector quite easily because the containing class already is a C++ class. As this is a low hanging fruit for continued code cleanup, it should be done sooner rather than later.
|
|
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.
|
|
312 | Other | Possible Bug | 3.70 release | Very Low | Low | Rendering stuck at 99% | Closed | |
|
Task Description
After a long parse period and a relatively quick rendering, POVray gets stuck at 99% when rendering the attached file.
Rendered at 6144x3072px with antialiasing set to 0.3.
Can anyone confirm?
|
|
20 | User interface | Feature Request | 3.70 beta 32 | Very Low | Very Low | render window behavior | Tracked on GitHub | |
|
Task Description
When changing the behavior of the render window, “Keep above main”, requires restarting the POV editor to take effect. It would be nice either to get a warning to restart, or to get it to work without restarting.
|
|
47 | Preview | Possible Bug | 3.70 beta 32 | Very Low | Low | Render Preveiw window can become disabled | Tracked on GitHub | |
|
Task Description
If a render is continued with the +c option and the render had completed, the render preview window will disappear and the show/hide render window button will be grayed. Even after the scene is modified and the command line options have been changed, the show/hide button will still be grayed.
Opening or changing to another scene and rendering will not restore the button, nor will rendering with +d. However, if a trace is started using -d, halted, then continued using +d (or allowed to finish completely with -d and a new one is started using +d), then the preview window is restored.
This behavior is different from 3.6.1, which correctly always showed the preview window (since +d is default) unless -d was specified.
|
|
270 | Other | Definite Bug | 3.70 release | Medium | High | render abort-continue (+C) sometimes skips blocks | Closed | |
|
Task Description
When aborting a render when there are unfinished blocks among finished ones, under certain conditions some of those blocks are skipped when continuing the render later.
|
|
111 | Parser/SDL | Definite Bug | 3.70 beta 37a | Very Low | Low | Remove_Bounds=off / -UR does not work properly | Closed | |
3.70 beta 38 |
Task Description
Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.
|
|
305 | Geometric Primitives | Feature Request | 3.70 RC7 | Very Low | Low | remove maximum component limit for blobs | Closed | |
|
Task Description
Blobs are currently limited to 1,000,000 components (with each cylindrical component counting as three: one cylinder + two end hemispheres); this limit may have served a historic purpose, but is now entirely arbitrary: The remaining code is limited only by the available RAM and the numeric limits of the int data type. The arbitrary maximum components limit per blob should therefore be removed.
Aside from unnecessarily limiting the power of the blob component, another drawback of the current test is that it is only performed after parsing of all the blob’s components, potentially hours after the limit had actually been reached.
|
|
246 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | Regression on scale limit between 3.7 and previous rele... | Tracked on GitHub | |
|
Task Description
From Thomas de Groot
Using the following code for a (sky) sphere in a scene, with light source well outside the sphere; works correctly until the above scale value. Use a value of >=100*10e4 and the sphere becomes black.
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#declare T_sky =
texture {
pigment {
gradient y
pigment_map {
[0.0 srgb <1.0,0.7,0.6>*1 transmit 0.5]
[1.0 srgb <0.8,0.1,0.0>*1 transmit 0.5]
}
}
finish {
emission 0.9
diffuse 0.0
}
}
#declare T_cosmos =
texture {
pigment {
color rgbt <0,0,0,1>
}
finish {
ambient 0.0
diffuse 0.0
}
}
sphere {
<0,0,0>,1
texture {T_sky}
interior_texture {T_cosmos}
no_shadow
no_reflection
inverse
scale 99.9*10e4
}
Working with windows version of POV-Ray and Win7 x64
Is this normal for version 3.7 RC5? I seem to remember that with lower versions of POV-Ray on could go at least to 10e6. Especially with the Ringworld scenes back in 2010 the scales used where much larger without any black out.
I can indeed confirm that the Ringworld scene does not render correctly anymore, with identical black out.
|
|
16 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Medium | reflective texture map crash | Closed | |
3.70 beta 33 |
Task Description
Reflective texture maps can cause a stack overflow crash.
sphere{0,1
texture{
bozo
texture_map{
[0 pigment{rgb 0}]
[1 pigment{rgb 0} finish{reflection 1}]
}
}
}
|
|
286 | Texture/Material/Finish | Possible Bug | 3.70 RC7 | Very Low | Low | reflection exponent other than 1 causes black artifacts... | Tracked on GitHub | |
|
Task Description
[EDIT: Original title was “radiosity causing black patches when using emission less than 0”]
see attached image for reference.
mountain on left has emission set to -.13 and black patches show up, when emmission set to 0 or greater no patches
changing max_trace or any radiosity settings has no effect
setting no_radiosity on mountain fixed problem as a temp fix
code sample ...
#version 3.7;
#default { finish { ambient 0 } }
#declare rad_lvl = 4;
global_settings {
assumed_gamma 1
max_trace_level max(5,rad_lvl*3)
adc_bailout .007
ambient_light 0
radiosity {
pretrace_start 64/max(image_width,image_height)
#if(rad_lvl)
pretrace_end max(2,int(8/rad_lvl))/max(image_width,image_height)
#else
pretrace_end 32/max(image_width,image_height)
#end
count pow(rad_lvl+1,2)*10
nearest_count 1
#if(rad_lvl) error_bound 1/rad_lvl #end
low_error_factor max(.4,(8-rad_lvl)/10)
recursion_limit 1
gray_threshold .25
brightness 1
max_sample 1
normal on
media off
always_sample off
minimum_reuse min(.008,8/max(image_width,image_height))
maximum_reuse .1
adc_bailout .02
}
}
#declare sunC = rgb <1, 1, .9925>; // actual D65 standard illuminant
#declare SkyC = rgb <.3195, .5745, .8805>;
#macro GammaAdj(C,G) rgb <pow(C.red,G),pow(C.green,G),pow(C.blue,G)> #end
light_source {
50000*y
sunC*1.06
area_light <-300, 0, -300>, <300, 100, 300>, 3, 3
rotate <-28, 0, 14>
adaptive 0
circular
}
sphere { 0, 1
texture {
pigment{
gradient y
pigment_map{
[.07 GammaAdj(SkyC,.5)]
[.2 average pigment_map { [.5 GammaAdj(SkyC,.75)][1 wrinkles turbulence .65 octaves 5 lambda 3 omega .9 color_map { [.2 rgb 1][.5 SkyC] } scale <10, .1, 1>] }]
[.4 GammaAdj(SkyC,1.15)]
[.5 GammaAdj(SkyC,1.35)]
}
rotate -75*y scale <1, 1, 100>
}
finish { diffuse .72 }
}
scale 100000
inverse
}
#declare Cam_pos = Cam_pos + <0, 20, -40>;
#declare Cam_lkt = Cam_lkt + <0, 10, 50>;
camera {
location Cam_pos
direction <0,0,1>
right 1.33*x
up y
sky <0,1,0>
#if(Cam_agl) angle Cam_agl #end
look_at Cam_lkt
}
#macro sinai(HillQ)
#local F = function { pattern { granite poly_wave 4 turbulence .01 lambda 2.1 omega .9 scale 5 translate <.2, 0, 18.08> scale <2, 1, 3> } }
#local N = function { pigment { crackle ramp_wave turbulence .3 lambda 2.2 omega .76 color_map {[0 rgb 0][1 rgb 1] } scale .07 translate <-.15, -.12, .13> } }
height_field {
function HillQ, HillQ { F(x,y,z) + N(x,y,z).grey/47 }
water_level .05
clipped_by { box { <0, .05, .3>, <1, 1, 1> } }
translate <-.5, -.05, -.5>
rotate 20*y
texture {
pigment{ crackle color_map { [0 rgb <161, 107, 71>/255][.25 rgb <193, 132, 93>/255][.35 rgb <218, 163, 123>/255][.45 rgb <212, 153, 112>/255][.55 rgb <222, 166, 125>/255][.65 rgb <236, 178, 124>/255][.75 rgb <220, 154, 102>/255][.85 rgb <160, 121, 103>/255] } turbulence .75 lambda 3 omega .7 scale .1 }
finish{ diffuse albedo .56 emission -.13 specular .25 roughness .02 brilliance 1.5 metallic 1.3 }
normal { crackle poly_wave .7 turbulence .4 omega .8 scale <.007, .03, .007> }
}
rotate 12*y
scale <2400, 2000, 3000>*1.5
translate <1900, 0, 1900>
scale <-1,1,1>
no_radiosity
}
#end
sinai(1600)
plane { y,0 pigment { rgb <1, 1, 1> } }
//courtyard gating not included due to size of code and many external files needed. add anything around <0,0,0> to try to reproduce effect of error
|
|
300 | Other | Feature Request | 3.70 RC7 | Defer | Very Low | Reference Documentation Support | Tracked on GitHub | |
|
Task Description
As emerged as an idea during the discussion of FS#299, an SDL / POV-Ray editor feature would be useful that allows API documentation via formal comments, e.g. in include files:
/**
* Creates a car object.
* @param a
* description of param a
* ...
*/
#macro car(a,b,c)
...
#end
In addition to the ability of (auto-)generating a documentation file from such comments, an editor window feature would be convenient that allows popup display of a macro’s (object’s / parameter’s / ...) documentation section.
|
|
98 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Medium | Refactor Windows UI code for Unicode support | Tracked on GitHub | |
Future release |
Task Description
Windows UI code should be refactored to use _TCHAR throughout instead of char, as well as the corresponding string function macros, to head for Unicode support.
|
|
99 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Very Low | Refactor engine (front- & back-end) code for Unicode su... | Tracked on GitHub | |
Future release |
Task Description
Front- & Back-end code should be refactored for full Unicode support in scene files and strings.
|
|
83 | Source code | Possible Bug | 3.70 beta 36 | Very Low | Very Low | redundant code in pvengine.cpp | Closed | |
3.70 beta 37 |
Task Description
In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:
3997 case KEYWORD_LOOKUP_MESSAGE :
3998 hh_aklink.pszKeywords = (LPCSTR) lParam ;
3999 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000 hh_aklink.pszKeywords = "" ;
4001 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002 hh_aklink.pszKeywords = "" ;
4003 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004 hh_aklink.pszKeywords = "" ;
4005 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006 hh_aklink.pszKeywords = "" ;
4007 HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008 return (true) ;
This duplication appears pretty much useless to me - or am I missing something?
|
|
170 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Reduce memory footprint of output image buffer | Closed | |
3.70 release |
Task Description
Currently, output image is buffered using POV-Ray’s RGBFT color model and floating point values, leading to a memory consumption of 20 bit per pixel. This is an unproportionally large memory footprint, given that the only further processing performed on the buffered data is conversion of the data to the desired output file format, which will typically use only 3 bytes per pixel (at most 12 bit per pixel).
The situation can be improved by choosing the output image buffer container based on the desired output file format and parameters. To this end, the following code changes should be made:
Bundle image file format handler code into classes (typically one per file format)
Include a method to determine the best data container type for the image buffer
Instantiate the desired image file format handler object prior to rendering, querying the handler object for an image buffer
In addition to picking a suitable image data container from the already existing palette, careful design might also allow to use custom containers to directly pass the data to a library (in case the library provides its own buffering anyway), or write it directly to the output file (e.g. when writing image data to stdout). To make this compatible with multithreaded rendering, the following changes would have to be made:
Add code to detect when a row of SMP blocks has been finished, and call a certain method on the image handler object
Design the custom containers in such a way that they can buffer any number of unfinished SMP block rows as needed
|
|
314 | Comments/Typos | Definite Bug | 3.70 release | Very Low | High | reading Gif is bugged in 3.7 | Closed | |
|
Task Description
In gif.cpp (source/base/image), circa line 150:
case ',': /* Start of image object. Get description. */
for (int i = 0; i < 9; i++)
{
if ((data = file->Read_Byte()) == EOF)
throw POV_EXCEPTION(kFileDataErr, "Unexpected EOF reading GIF file");
buffer[i] = (unsigned char) data;
}
/* Check "interlaced" bit. */
if ((buffer[9] & 0x40) != 0)
throw POV_EXCEPTION(kFileDataErr, "Interlacing in GIF image unsupported");
The loop reads the 9 bytes of the Image Block, but is testing the tenth byte for interlacing.
Reference for image format: http://www.onicos.com/staff/iz/formats/gif.html#ib
When the gif is generated by Gimp, the Image block is preceded by the comment block which default to “Created with GIMP”... the comment is read in the buffer, and the “i” will be in buffer[9], any letter after @ will indeed block povray.
This bug was not present in 3.1g nor in 3.6.1 (due to different source to handle gif).
If not created by Gimp, or with shorter comment, the content of buffer[9] is more random, yet it might trigger the bug depending on the previous blocks and their handling.
|
|
18 | Distribution | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | read only files in distribution | Closed | |
3.70 beta 33 |
Task Description
Array.inc and subsurface.pov are in read only mode, they probably should have normal permissions.
|
|
7 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Re-implement Radiosity render abort/continue support | Tracked on GitHub | |
|
Task Description
For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.
To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.
|
|
172 | Image format | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Re-implement progressive image output | Tracked on GitHub | |
Future release |
Task Description
With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.
|
|
29 | Image format | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Medium | Re-implement image output to STDOUT | Closed | |
3.70 beta 39 |
Task Description
Versions of POV-Ray prior to 3.7 had the ability to write the image output as a stream to STDOUT. This was particularly useful in unix as it allowed POV-Ray output to be directly piped to other processes.
The introduction of SMP and the associated non-linear generation of pixels complicates stream output to the extent that it is not currently available in v3.7.
At a minimum 3.7 must at least be able to write the completed image to STDOUT after a render - this is not an optimal solution but is better than nothing. Ideally however once entire lines are complete (most likely this will occur in batches due to the block nature of the render subdivision) these lines will be written immediately to STDOUT (after possibly being processed through the appropriate image format routines).
NB currently the image format routines are not invoked until the entire render is completed, so to do this would be a significant modification. However if we limit real-time stream output to “simple” non-compressed formats (e.g. PPM), it would not be overly difficult, and from the point of view of Unix-like operating systems (where the piping feature is most useful), if the data is in PPM format it can easily be transformed into anything else.
|
|
71 | User interface | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Low | raise warning when command line option has no effect | Tracked on GitHub | |
|
Task Description
Warnings should be raised when a command line option has no effect, for example...
pvengine +am
is legal, but without the number after it, it has no effect.
pvengine +am7
should be an error, and also raises no warnings.
|
|
176 | Other | Feature Request | Not applicable | Very Low | Low | Raise maxpower of the Poly Oject to 16. | Closed | |
|
Task Description
At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.
|
|
313 | Radiosity | Definite Bug | 3.70 release | Low | High | radiosity.cpp pov::RadiosityFunction::BeforeTile assert... | Tracked on GitHub | |
|
Task Description
With 3.7.0 final, rendering attached files (for Computer Engineering college course), which renders without issues in povray 3.6.1, fails with following error:
...
==== [Rendering...] ========================================================
povray: backend/lighting/radiosity.cpp:324: virtual void pov::RadiosityFunction::BeforeTile(int, unsigned int): Assertion `(pts >= PRETRACE_FIRST) && (pts <= PRETRACE_MAX)' failed.
Command line:
povray +K0.6500 \
+FN +Q9 +MB1 \
+W600 +H400 \
+AM1 +A0.0 +R2 \
+D +SP32 +EP4 \
+L/usr/share/povray-3.7/include \
+Imain.pov \
+Omain-0.6500.png
Using Arch Linux testing current: Linux archmidi 3.12.0-1-ARCH #1 SMP PREEMPT Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux
Downstream bug report: https://bugs.archlinux.org/task/37689
|
|
175 | Radiosity | Feature Request | 3.70 beta 39 | Very Low | Low | Radiosity. Emissive and scattering media don't illumina ... | Closed | |
|
Task Description
Tested with beta 40. Also affect version 3.6.1 as reported in the discution group.
When using radiosity and emissive media. Any object, or part of, that is inside the media container is not affected by the illumination comming from the media.
When using scattering media, the light scattered by the media also don’t affect objects that are inside it’s container.
http://news.povray.org/povray.newusers/thread/%3C4cf8fe22%241%40news.povray.org%3E/
|
|
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
|
|
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.
|
|
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)
|
|
166 | Texture/Material/Finish | Definite Bug | 3.70 beta 38 | Very Low | Low | quick_color does not work | Closed | |
|
Task Description
the quick_color feature doesn’t work when +qN or Quality=N is set to 5 or below
|
|
332 | User interface | Feature Request | 3.70 release | Very Low | Low | Progress animation in taskbar tabs | Closed | |
|
Task Description
On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.
Here is an example of Chrome downloading something and showing the progress in the taskbar:
http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg
Here is an example with Paint.NET instead:
http://www.getpaint.net/images/pdn351_superbarProgress.png
I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.
|