|
132 | Geometric Primitives | Feature Request | 3.70 beta 37a | Very Low | Low | Native support for mesh-based surface approximations | Closed | |
|
Task Description
There are various scripts around the Net meant for approximating things like isosurfaces and parametric objects using meshes. It would probably run bit faster and be easier to use if this were supported natively within Povray. The feature would require an additional object parameter in order to toggle this behavior on/off.
|
|
182 | Texture/Material/Finish | Definite Bug | 3.70 beta 40 | Low | High | multi-textured blobs in intersections / differences bro ... | Closed | |
3.70 beta 41 |
Task Description
Multi-textured blobs are broken with 3.7 beta 40 when used inside an intersection, as can be demonstrated by the following scene:
#default { texture { pigment { rgb 1 } } }
camera {
right x*image_width/image_height
location <0,1.5,-4>
look_at <0,1,0>
}
light_source { <500,500,-500> color rgb 1 }
difference { blob {
threshold 0.6
sphere { < 0.75, 0, 0>, 1, 1 texture { pigment { color red 1 } } }
sphere { <-0.375, 0.65, 0>, 1, 1 texture { pigment { color green 1 } } }
sphere { <-0.375, -0.65, 0>, 1, 1 }
} }
With POV-Ray 3.7.0 beta 40, the entire blob is rendered with the default texture.
The same problem can be seen with “difference” or “merge” instead of “intersection”.
Omitting the CSG “envelope”, using “union”, or assigning the blob to a variable first and then using it inside an intersection, will yield the expected result.
POV-Ray 3.62 renders all variants as expected.
According to initial analysis, the problem appears to be caused by the dual use of the “MULTITEXTURE_FLAG”, which is used in CSG to indicate use of the “cutaway_textures” feature, and in blobs to indicate per-element texturing. (The same flag is also used in meshes to indicate per-face or per-vertex texturing, so similar problems are to expected there.)
My proposal is to use an entirely separate flag for the “cutaway_textures” feature (the blob and mesh can safely continue to share the MULTITEXTURE_FLAG).
|
|
54 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Low | Multi-textured blobs fail to increment trace level | Closed | |
|
Task Description
Trace level is not handled properly with blobs using per-component reflective or refractive textures, leading to lockups. Stepping through the code, it seems that POV-Ray fails to properly mark the blob object as increasing the trace level.
(Until this bug is fixed, the issue can be worked around in most cases by assigning a reflective texture to the blob as a whole.)
|
|
113 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Low | High | Multi-layered reflections broken | Closed | |
3.70 beta 38 |
Task Description
Reflections in multi-layered textures are broken in 3.7 betas, as can be demonstrated with the following scene showing two reflective hemispheres on a checkered plane:
camera {
location <1.0, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
default {
finish { diffuse 0 ambient 0 specular 0 }
}
// ----------------------------------------
plane { // checkered floor
y, -1
texture
{
pigment { checker color rgb 1 color blue 1 }
finish{ diffuse 0.8 ambient 0.1 }
}
}
// left hemisphere
intersection {
sphere { 0, 1 }
plane { x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 } }
}
}
// right hemisphere
intersection {
sphere { 0, 1 }
plane { -x, -0.002 }
texture {
pigment { color rgb 1 }
finish{ reflection { 1.0 } }
}
}
Note that the reflection parameters of the left, multi-layered hemisphere sum up to 1.0, i.e. the same value as used in the single layer in the right hemisphere.
The first attached file (test_3.6.2.png), rendered with POV-Ray 3.6.2, shows the expected output: Both hemispheres appear to have the same reflectivity.
The second attached file (test_3.7.0.beta37a.png), rendered with POV-Ray 3.7.0.beta.37a, shows a much brighter left (multi-layered) sphere.
As it turns out, in order to get the expected result with POV-Ray 3.7.0.beta.37a, the reflectivity of each layer must be divided by 3, 2 and 1, respectively (which obviously does not sum up to 1.0):
...
texture {
pigment { color rgb 1 }
finish{ reflection { 0.5 / 3 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.4 / 2 } }
}
texture {
pigment { color rgbt 1 }
finish{ reflection { 0.1 / 1 } }
}
...
|
|
108 | Parser/SDL | Feature Request | 3.70 beta 37 | Very Low | Low | motion_blur feature similar to Megapov version | Tracked on GitHub | |
Future release |
Task Description
motion_blur which is a simple and effective feature to use in Megapov to simulate motion blur of, e.g. bird wings, propellers or running animals, would be a neat addition to version 3.7 and later.
In Megapov, the feature requires a line of code in the global_settings{} e.g.: motion_blur 10, 2 and a declaration for the moving object. e.g.:
motion_blur {
type 0
object{MyObject material{MyMaterial rotate x*clock*2}}
rotate x*clock*10
}
type represents several types of pre-defined motions.
Thanks,
Thomas
|
|
114 | Preview | Definite Bug | 3.70 beta 37a | Very Low | Low | Mosaic Preview not displaying properly | Closed | |
|
Task Description
Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.
I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.
|
|
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.
|
|
120 | Documentation | Compatibility Issue | 3.70 beta 37a | Very Low | Very Low | More library paths, wildcards | Closed | |
3.70 release |
Task Description
20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.
|
|
118 | Light source | Feature Request | 3.70 beta 37a | Very Low | Low | More efficient handling of fading lights | Tracked on GitHub | |
3.71 release |
Task Description
Currently, fading light sources are used for lighting and shadow calculations even when so far away as to no longer have any effect on the outcome. The proposed solution is to add a new keyword fade_cutoff_distance which tells povray to ignore the light source when alluminating a point at larger distance.
A sample implementation is provided in the attached files. These changes are still based on beta 34 as sources for the current beta are not yet available, and starting to merge changes to beta 35 only at this time didn’t seem worth the effort. Also, please disregard, changes in the CVS header comments (I also use CVS locally for managing source files).
Further considerations regarding this feature:
- For special effects this feature can also be used if the light source does not actually use fading. On the other hand, cutting the light at some distances can be considered an extreme form of fading which may justify the keyword name anyhow.
- Depending on how FS#46 is implemented, the test for cutoff may then be needed at another location as well.
- The default value currently is 0 (or *no* cutoff distance). For #version 3.7 of higher, the default could be chosen automatically based on the light source intensity and adc_bailout, although it may then need to be overriden by the user for extreme pigments.
|
|
115 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | More cutaway_textures | Tracked on GitHub | |
Future release |
Task Description
Think this is still a problem. See the attached scene file. Find the WindowFrameSegment declaration for more info. The scene as-is shows the problem (SOME portions of the difference inherit the color of the room) the window opening is scaled larger to show that they AREN’T touching. The problem goes away when (in WindowFrameSegment) the 1st occurrence of the applied texture is commented out and the 2nd occurrence is uncommented, and cutaway_textures is commented out.
|
|
178 | Texture/Material/Finish | Feature Request | 3.70 beta 39 | Very Low | Low | Modify metallic reflection code to better work with con... | Tracked on GitHub | |
|
Task Description
The combination of metallic reflection with conserve_energy causes the reflection to lose colour, as demonstrated by the following scene:
global_settings {
max_trace_level 10
}
camera {
right x*image_width/image_height
location <-2,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb 0.7 } }
}
#declare M=
material {
texture {
pigment {rgbt <1.0,0.7,0.2,0.99>}
finish {
ambient 0.0
diffuse 0.5
specular 0.6
roughness 0.005
reflection { 0.8, 1.0 metallic }
conserve_energy
}
}
interior { ior 1.5 }
}
box {
<-0.2,0,-2.3>, <0.0,4,0.3>
material { M }
rotate z*5
rotate x*2
}
|
|
128 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Mixed-type arrays | Closed | |
|
Task Description
Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.
|
|
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);
|
|
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
|
|
295 | User interface | Definite Bug | 3.70 RC7 | Very Low | Low | Minor GUI Bugs | Tracked on GitHub | |
|
Task Description
Here are two low-priority bugs in POV-Ray’s GUI, observed by me under Windows XP, which should be easy to fix I think:
In the “Insert” menu, there are sub-menus (e.g. “Radiosity and Photons”) in which there are menu seperators at the end of the popped-up menu bar.
The progress bar in the top-right corner of the editor window seems to be too large for the window (203px) and therefore clipped. As a result, progress seems to be 100% when it is not yet, e.g. at 90% progress. (Have not measured exactly.)
Both bugs are not severe at all, but it would be nice if they could be fixed. By the way, a second progress bar could be added to visualize the number of frames already rendered in an animation.
|
|
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).
|
|
318 | Texture/Material/Finish | Definite Bug | 3.70 release | Very Low | Low | method 3 (default) scattering media is too bright & cau ... | Closed | |
3.71 release |
Task Description
The following scene demonstrates how media sampling method 3 gives inaccurate results with scattering media.
The scene shows four spheres with uniform media, using (left to right) sampling methods 1, 2 and 3 with default settings, and sampling method 3 with high minimum sample count, respectively.
Note how changing the sample count significantly affects the result, despite the media being uniform.
Code analysis shows that the root cause is an underestimation of the extinction effect on the light scattered by the media, corresponding in order of magnitude to half the distance between mandatory samples (as defined by minimum sample count).
The effect also leads to visible artifacts when nesting hollow objects inside the media, as can be demonstrated by un-commenting the four smaller spheres.
#version 3.7;
camera {
perspective angle 25
location <0.0 , 0.0 ,-20.0>
right x*image_width/image_height
look_at <0.0 , 0.0 , 0.0>
}
light_source {
<0,3000,-3000> color rgb 1
}
background { color rgb 0.5 }
plane {
<0,1,0>, -1
texture { pigment { checker color rgb<1,1,1>*1.2 color rgb<0.25,0.15,0.1>*0 } }
}
#declare T_Transparent = texture {
pigment { color rgbt <1,1,1,1> } finish { diffuse 1 }
}
sphere { <-3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 1
}
}
}
sphere { <-1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 2
}
}
}
sphere { <1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
}
}
}
sphere { <3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
samples 100
}
}
}
/*
sphere { <-3,0,0>,0.8 texture { T_Transparent } hollow }
sphere { <-1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 3,0,0>,0.8 texture { T_Transparent } hollow }
*/
|
|
255 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 should compute per vertex or per fac ... | Closed | |
|
Task Description
The documentation states mesh_camera 0 should produce 1 pixel per index but it currently seems to produce 1 lighting pixel per face.
This output seems fairly meaningless as using this data for vertex colours (presumably the intention for mesh_camera 0) would result in a flat shaded model.
Logically it would make more sense to output 1 pixel per vertex instead of 1 pixel per face. Another solution might 1 pixel per face index (as per documentation) although POV would need to record which indices had already been computed otherwise it could end up duplicating computation.
At the moment I’ve written a code workaround for my exporter which produces a special mesh but this is obviously a much more complex solution to a fairly simple problem.
|
|
254 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 output seems to be incorrect | Closed | |
|
Task Description
When using mesh_camera type ‘0’
The first line of the mesh output seems to be repeated resulting in incorrect light colour values.
If the first line of the texture is skipped then the values seem to be correct.
|
|
329 | Documentation | Possible Bug | 3.70 release | Very Low | Low | Mesh_camera type 0 output seems | Closed | |
|
Task Description
When using mesh_camera type ‘0’
The first line of the mesh output seems to be repeated resulting in incorrect light colour values.
If the first line of the texture is skipped then the values seem to be correct.
|
|
261 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | mesh_camera distribution type 3 output image is placed ... | Closed | |
|
Task Description
Output images are 0.5 pixels too right and 0.5 pixels too down (mesh_camera_bug.pov).
The error is cumulative when image files are used again as texture (run 10 times mesh_camera_bug_reuse.pov).
This can be compensated by adjusting UV maps (mesh_camera_fix.pov and mesh_camera_fix_reuse.pov).
Tested with and without anti-aliasing.
|
|
1 | Backend | Definite Bug | 3.70 beta 32 | Very Low | Medium | Mesh not smooth in 64-bit beta 32 | Closed | |
3.70 beta 33 |
Task Description
Beta 32 is failing to render a mesh2 smoothly on 64-bit XP - output shows flat triangles rather than smoothed triangles. Issue is not present in 32-bit build.
Reported in http://news.povray.org/49e51489%241%40news.povray.org. Demo image rendered using standard chessmesh scene.
|
|
277 | Other | Possible Bug | 3.70 RC7 | Very Low | Medium | Max Image Buffer Memory Does not Seem to Work | Closed | |
|
Task Description
In POV-Ray’s documentation it says:
3.2.2.2 Max Image Buffer Memory
This INI parameter sets the number of megabytes of RAM to allow for output image caching. If the output image happens to use more than this, a file backed temporary image is used instead.
I used this INI file option because the default value (128 megabytes) seemed insufficient. pov-state backend files were always created and they were remarkably larger than the resulting image (bmp) files. Consequently, I set
Max_Image_Buffer_Memory = 3096
in the INI file so that POV-Ray should, according to the documentation, now be able to use 3 gigabytes of RAM so no backend temporary file would be needed at all (this large they were never).
However, while POV-Ray was rendering I still discovered a pov-state file and it still had a similar size.
Now I am confused: did the INI option not work or have I misunderstood the documentation? If the former is the case, that would be a bug, wouldn’t it?
I tested both under Windows XP and Debian 6.0.5.
|
|
296 | Geometric Primitives | Definite Bug | 3.70 RC7 | Defer | Medium | max gradient computation is not thread safe (isosurface... | Tracked on GitHub | |
3.71 release |
Task Description
It appears as a side effect of investigation of #294: the code in isosurf.cpp, inside bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)
if(gradient < temp)
gradient = temp;
is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)
It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)
|
|
291 | Include files | Possible Bug | 3.70 RC7 | Very Low | Low | Math.inc: error in VDist function | Closed | |
|
Task Description
Included math.inc into scene and recieved this fatal error from povray:
File '/usr/local/share/povray-3.7/include/math.inc' line 248: Parse Error: Expected 'string expression', float function 'vlength' found instead
Appropriate place in math.inc:
245 > #end
246 >
247 > // Distance between V1 and V2
248 > #macro VDist(V1, V2) vlength(V1 - V2) #end
249 >
250 > // Returns a vector perpendicular to V
Running newly-downloaded/newly-compiled POV-Ray 3.7.0, on Linux x86_64 system
|
|
130 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | High | Master scene unit system variable | Closed | |
|
Task Description
Currently, many POV scenes/include files behave differently depending on the basic units used within the scene. Scaling them differently can affect things like ior and media. A master system variable that users can set to configure the scene’s units would be beneficial for sharing and collaboration purposes, so that person A’s glass interior works correctly in person B’s wine glass scene. Just like the #version system variable, it should have a default value but should be possible to explicitly override.
|
|
333 | User interface | Feature Request | 3.70 release | Very Low | Low | Make text in "about" alt+b dialog selectable with the m... | Tracked on GitHub | |
|
Task Description
When you press alt+b or access the “about” dialog in the Help menu it displays some text including software version number and list of contributors.
It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.
|
|
146 | Parser/SDL | Possible Bug | 3.70 beta 37a | Very Low | Low | Macros are finnicky about how you type your code | Closed | |
|
Task Description
Macros are finicky about how you type your code. What works outside macros sometimes fails inside them. For more information see the threads:
“Problems with macro (3.6)”, in p.a-u, 06-09-10 “Bad operands”, in p.g, 05-20-10
Still not sure *what* exactly the problem was, but one of my workarounds ended up working.
|
|
335 | Parser/SDL | Possible Bug | 3.70 release | Very Low | Low | macro works in variable but not in array | Tracked on GitHub | |
|
Task Description
This doesn’t work:
#declare pavement_object = array[2] {
object {trash_can_macro() scale 3/4 translate -x * 1/2},
object {potted_plant_macro(_CT_rand2) scale 3/4 scale 3/2 translate -x * 1/2}
}
This does work:
#declare trash_can_object = object {trash_can_macro()}; #declare potted_plant_object = object {potted_plant_macro(_CT_rand2)}; #declare pavement_object = array[2] {
object {trash_can_object scale 3/4 translate -x * 1/2},
object {potted_plant_object scale 3/4 scale 3/2 translate -x * 1/2}
}
Logically, I cannot see a reason for this to be so.
|
|
180 | Runtime error | Definite Bug | 3.70 beta 40 | Very Low | High | lseek64(fileno(fd), ...) is not the same as fseek64(fd, ... | Closed | |
3.70 RC1 |
Task Description
FileBackedPixelContainer uses a FILE* to manage the backing store and under Linux/Unix defines fseek64 to be a kind of incantation of lseek64.
Since fseek64 and fseek64 have return values that are logical opposites this causes an exception to be thrown.
Moreover since the buffer size on a FILE is quite a bit smaller than a line of pixels (in terms of bytes), mostly what’s being done in this function is a lot of sloshing of bytes that don’t do much... which is to say that the intended caching mechanism is getting a very low hit rate now that povray is working in 32×32 pixel per-thread chunks.
The cache miss problem and the volume of bytes read/written grows exponentially as the size of the image grows.
Attached is a replacement function that seems to be working well and should produce a performance increase even under Windows. I originally went with simply fixing the fseek/lseek problem but saw a 10% decrease in render time on 2048×1024-sized images when I made the cache target smaller.
|
|
70 | Photons | Unimp. Feature/TODO | 3.70 beta 34 | Low | High | load/save photons should be controlled via command line | Tracked on GitHub | |
|
Task Description
Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.
|
|
274 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | Low | light source fading doesn't work properly with area_ill ... | Closed | |
3.70 release |
Task Description
When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:
#version 3.7;
global_settings {
assumed_gamma 1.0
mm_per_unit 10
subsurface { samples 200,20 }
}
camera {
right x*image_width/image_height
angle 30
location <0,1.5,-4>
look_at <0,0,0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture {
pigment {
checker
color rgb <1.0, 0.8, 0.6>
color rgb <1.0, 0.0, 0.0>
scale 0.5
}
}
}
light_source {
<50,50,50>
color rgb 30
area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
area_illumination on
fade_distance 10
fade_power 2
}
cylinder {
<0,0,0>, <0,0.2,0> 1
texture {
pigment { color rgb 1 }
finish {
ambient 0
diffuse 0.7
specular albedo 0.3
reflection { 0.3 fresnel }
conserve_energy
subsurface { translucency 0.1 }
}
}
interior { ior 1.5 }
}
sphere {
<0,0.4,0>, 0.2
texture {
pigment { color rgb <1,0.6,0.0> }
finish {
ambient 0
diffuse 0.0
specular albedo 0.8 metallic
reflection { 1.0 metallic }
conserve_energy
}
}
}
|
|
22 | Parser/SDL | Definite Bug | 3.6 | Very Low | Medium | Known 3.6-only bug related to Splines and Token countin ... | Closed | |
3.65 |
Task Description
3.6x only bug with easy/known fix. Error message: “Identifier expected, incomplete function call or spline call found instead.” caused by token counter variable using the wrong special value. The symptom occurs when using a lot of splines. See this thread for details.
(I am using a self-compiled special build because I use a lot of splines in 3.6 but would rather use an official 3.6)
|
|
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
|
|
15 | Geometric Primitives | Definite Bug | 3.70 beta 32 | Very Low | Medium | julia fractal, trace and inside cause crash | Closed | |
3.70 beta 33 |
Task Description
Using trace or inside with a julia fractal causes a crash.
#declare Test = julia_fractal {
<-0.083,0.0,-0.83,-0.025>
quaternion
cube
max_iteration 8
precision 20
};
#declare Norm = <0,0,0>;
#declare Hit = trace(Test,<0,0,-10>,z,Norm);
#declare Center = inside(Test,<0,0,0>);
|
|
103 | Image format | Definite Bug | 3.70 beta 37 | Very Low | Low | JPEG output does not conform to baseline JFIF standard | Closed | |
3.70 beta 38 |
Task Description
POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.
As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.
|
|
24 | Geometric Primitives | Definite Bug | 3.70 beta 32 | Very Low | Critical | isosurface, bounding box & threads | Closed | |
3.70 beta 33 |
Task Description
Linux beta 32, 64bits, compiled from sources.
povray -w800 -h600 +a0.3 +kfi1 +kff78 -L/usr/local/share/povray-3.7/scenes/incdemo -Ii_internal.pov +WT5 +R4 +AM1 +MB1
Important issue: +WT5 +MB1
Seems Fine for +WT1 +MB1 Also fine for +WT5 +MB9
The intersection with the containing box displays some two-shades of grey random checkered patterns. Size of square looks like size of renderering thread. Position too.
Impacted frames (of 78): 01, 02, 03, 30, 48, 74, 76.
|
|
315 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with quadrics | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with quadrics.
Left: a sphere primitive as reference Right: a sphere-shaped quadric primitive (sphere-shaped)
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the quadric’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = sphere { 0, 1 inverse }
#declare TopRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 }
#declare BottomRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-1,-1,-1>, <0,1,1> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
316 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with fractals | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with fractals.
Left: a sphere primitive as reference Right: a julia fractal
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the fractal’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = object { TopLeft inverse }
#declare TopRight = julia_fractal{ <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 20 scale 0.9 }
#declare BottomRight = object { TopRight inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-2,-2,-2>, <0,2,2> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
331 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Medium | Intersection causes quadric to disappear | Closed | |
|
Task Description
The following paraboloid renders correctly:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
}
However, when I extend the clipping cylinder downward:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
}
the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray 3.6.1, it renders as expected.
POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered) POV-Ray 3.7.1-alpha.8150025.unofficial openSUSE 13.2 GNU/Linux
This scene file illustrates the problem:
// +w480 +h240
#version 3.6; //[sic]
global_settings { assumed_gamma 1 }
camera
{ location <0, 1, -7.5958>
look_at <0, 1, 0>
right 2 * x
up y
angle 43.1038
}
#default { finish { diffuse 0.6 ambient rgb 0.15618 } }
light_source
{ <-4.3125, 9.6250, -7.4695>,
rgb 6856.3
fade_power 2 fade_distance 0.10417
spotlight point_at <0, 1, 0> radius 45 falloff 90
}
box
{ -<9, 11, 9>, <9, 11, 9>
pigment { rgb 1 }
}
plane
{ y, 0
pigment { checker rgb 0.05 rgb 1 }
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
pigment { green 0.5 }
translate <-1.25, 1, 0>
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
pigment { green 0.5 }
translate <1.25, 1, 0>
}
On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.
|
|
4 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | Integrate Subsurface Scattering with standard lighting ... | Tracked on GitHub | |
Future release |
Task Description
Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.
|
|
5 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | Integrate Subsurface Scattering with Radiosity | Closed | |
Future release |
Task Description
Subsurface scattering must be made radiosity-aware.
|
|
6 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Integrate Subsurface Scattering with Photons | Tracked on GitHub | |
Future release |
Task Description
Subsurface scattering must be made photon-aware.
|
|
154 | Setup/Install | Possible Bug | 3.70 beta 37a | Very Low | Low | Installation on linux (unix ?) in $HOME/.povray/3.7 set ... | Closed | |
|
Task Description
Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.
Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.
Please fix ?
|
|
52 | Parser/SDL | Possible Bug | 3.70 beta 32 | Very Low | Low | inside() function does not accept meshes despite valid ... | Closed | |
|
Task Description
The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.
(see news://news.povray.org:119/4a983716@news.povray.org)
|
|
250 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | ini shell-outs always fail | Closed | |
|
Task Description
I’ve got an ini file that looks like this:
Post_Frame_Return=U Post_Frame_Command=notepad.exe
And when I render a scene using that ini file, it renders correctly but then gives me this error:
Render halted because the post-frame shell-out (’notepad.exe’) requested POV-Ray to generate a user abort. Render failed
.....and it doesn’t open notepad.
I’ve unchecked the “Disable Starting Other Programs” and I’ve tried various variations on what exe to run and whether to do it Pre/Post Frame/Scene, and nothing has worked.
|
|
134 | Image format | Feature Request | 3.70 beta 37a | Very Low | Low | INI option to overlay render information on output imag ... | Closed | |
|
Task Description
It would be nice to configure an INI option to add render information like render time, date, and input file to output images.
|
|
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.
|
|
230 | User interface | Feature Request | 3.70 RC3 | Very Low | Low | Improved handling of animations | Tracked on GitHub | |
|
Task Description
October to middle November, I prodduced a 5 minutes video mainly py POVRAY.
Here a part of the video.ini file
#
# szenes based on games.pov #
#game-pat #Initial_Frame=450 - time scale 1000 - 30 seconds #Final_Frame=899 #Initial_Clock=-12500 #Final_Clock=17500
#game-lost - time scale 1000 - 22 seconds #Initial_Frame=0 #Final_Frame=659 #Initial_Clock=2000 #Final_Clock=24000
#game-lost - time scale 3000 - 12 seconds - fast through the night #Initial_Frame=0 #Final_Frame=359 #Initial_Clock=24000 #Final_Clock=60000
#book-cover #clock=64000
#game-sunrise - time scale 1000 - 35 seconds #Initial_Frame=0 #Final_Frame=1049 #Initial_Clock=60000 #Final_Clock=95000
Now imagine all the problems:
One computer crashes often because of thermal problems. Last picture rendere 487.
Now calculate the setings, that this computer continues the task at 487
Or 2 computers should render a scene.
Sounds very easy. Something like computer 1 makes 0..499 computer 2 makes 500..999.
But the computers are different in speed and the pictures are very different in computation time.
So it would be best
computer 1: 0 to 999 computer 2: 999 to 0
They would meet in the middle, where ever this middle is.
So it would be much easier with
#game-sunrise - time scale 1000 - 35 seconds Initial_Frame=0 Final_Frame=1049 Initial_Clock=60000 Final_Clock=95000 Initial_Task=487 Final_Task=1049
So I have not to calculate the exact clock seting, when a computer sould continue a task after crashing at picture 487
#game-sunrise - time scale 1000 - 35 seconds Initial_Frame=0 Final_Frame=1049 Initial_Clock=60000 Final_Clock=95000 Initial_Task=1049 Final_Task=0
This would be the reverse calcualtion order. Starting with picture 1049 and going down 1048..1047
|
|
8 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Improve Radiosity "Cross-Talk" Rejection in Corners | Tracked on GitHub | |
Future release |
Task Description
Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.
It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.
|