|
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
|
|
26 | Geometric Primitives | Definite Bug | 3.61 | Very Low | Low | Artifacts rendering a cloth which has two-side textures | Tracked on GitHub | |
Future release |
Task Description
Dear PovRay maintainers and developers, congratulations for your great RayTracer!
We think that we have found a bug while we were rendering a piece of cloth.
In this piece of cloth were defined two textures, one for one side and one for the another side:
texture { mesh_tex0_0 }
interior_texture { mesh_tex0_1 }
these definitions in their original context.
We have found some artifacts in the final rendering, in concrete near some wrinkles, please, look at the attached file “render_artifacts.tga”, I have painted a big green arrow near the artifacts, maybe you’ll need to do a zoom to see them more accurately.
They are as though the texture of the other side was painted in the incorrect side.
Fortunately, we have a patch to fix this bug (thanks to Denis Steinemann, he made the implementation for PovRay 3.5, so I have adapted these changes to release 3.6.1)
Although we have found this bug in the Windows and Linux 3.6.1 releases, the patch was generated in Linux (using the source code release of “povray-3.6.1”).
To apply this patch, inside the parent folder of the directory “povray-3.6.1” execute:
patch -p0 < other_side_artifacts.patch
And the “povray-3.6.1” will be patched and you will get a console output like this:
patching file povray-3.6.1/source/lighting.cpp
patching file povray-3.6.1/source/mesh.cpp
patching file povray-3.6.1/source/render.cpp
We don’t know if this “hack” is enough smart to apply in the next release, but we think that it fixes the bug (the artifacts dissapear).
Best regards and thank you very much for your great RayTracer!
|
|
42 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | command line parameters are not parsed properly on Unix | Tracked on GitHub | |
|
Task Description
POV-Ray does not follow common practice on command-line handling; for instance:
povray +i"My File"
entered on a Unix shell would be passed to POV-Ray as
povray
+iMy File
(each line representing a distinct parameter here), which POV-Ray would further dissect, interpreting it as
povray
+iMy
File
To achieve the desired effect, one would actually have to quote the string twice:
povray +i"'My File'"
which the shell would translate to
povray
+i'My File'
which POV-Ray would interpret as
povray
+iMy File
In both cases, this is obviously not what a Unix user would expect.
The further dissecting of individual command-line parameters may have had its valid roots in the peculiarities of DOS’ command-line handling, but to my knowledge all major contemporary operating systems follow a concept akin to Unix, passing a list of parameters instead of a monolithic command line, and burdening the respective command shells with the task of dissecting command lines into parameters.
Therefore I suggest to disable this anachronistic feature in favor of contemporary standards; a compiler flag might be used to allow for easy re-enabling of the feature, for compiling POV-Ray on exotic targets.
- edit -
It has been pointed out that the described behaviour differs from 3.6, so I’m promoting this to a bug and changing the title.
|
|
60 | Geometric Primitives | Definite Bug | 3.70 beta 34 | Very Low | Medium | Artifacts using prism in CSG | Tracked on GitHub | |
Future release |
Task Description
Using prisms in intersecion or difference CSG objects may cause artifacts in POV-Ray 3.6.2 as well as 3.7.0.beta.34, as demonstrated by the following code:
camera {
right -x
up y*image_height/image_width
location <-24,19,12>
look_at <0,0,0>
}
light_source { <100,200,100> color rgb 1 }
plane { y, -2 pigment { color rgb 1 } }
#declare KeyValue = 1.366; // pick any you like
difference {
prism {
linear_sweep -0.5,0.5, 4
<-3,20-17>,
<-3,KeyValue>,
<-6,-3>,
<-0,-5>
}
intersection {
cylinder { <-7,-0.51,1>, <-7, 0.51,1>, 4.0 }
plane { z, KeyValue }
}
pigment { color rgb 0.5 }
}
Apparently the surface of the other object becomes visible when it exactly coincides with a vertex of the prism; probably there is a failure of the inside() test for such values.
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
252 | Photons | Definite Bug | 3.70 RC6 | Very Low | Low | photons and light_group is broken | Tracked on GitHub | |
|
Task Description
photons are not working when used with a light_group. verified in NG posting in p.general a simple scene file is attached.
|
|
273 | Other | Definite Bug | 3.70 RC6 | Very Low | Medium | No automatic backup files from inc files | Tracked on GitHub | |
|
Task Description
If enabled, POVray always created backups of pov and inc files once per session. Now using 3.7 RC6 only pov file backups are created but not from inc files.
|
|
275 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | circular area lights exhibit anisotropy | Tracked on GitHub | |
Future release |
Task Description
circular area lights exhibit some anisotropy, being brighter along the diagonals than on average, as can be demonstrated with the following scene:
//+w800 +h800
#version 3.7;
global_settings{assumed_gamma 1}
plane{-z,-10 pigment{rgb 1} finish{ambient 0 brilliance 0}}
disc{0,z,10000,0.5}
camera{orthographic location z look_at 10*z up y*12 right x*12}
light_source{-10*z rgb 10 area_light 10*x 10*y 257 257 adaptive 4 circular}
|
|
287 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | area_illumination shadow calculation | Tracked on GitHub | |
Future release |
Task Description
not sure if this is something needing further work or an intended effect.
Shadows from and area light with area_illumination on seem to follow the same shadow calculation as a standard area light by giving more weight to lights near the center of the array. I would assume the shadows would be calculated similarly to individual lights in the same pattern as the array by evenly distributing the amount of shadow equally for each light. But this is not what I see.
The code sample below when rendered with scene 1 will show shadows grouped near the center from the area light with area_illumination. If scene 1 is commented out and scene 2 is uncommented then rendered, you will see evenly distributed shadows from individual lights. Area lighting with area_illumination I would assume should give a result identical to scene 2. If scene 1 is rendered with area_illumination off, the shadow calculation is exactly the same as with area_illumination on.
example images rendered on win32 XP
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb .7 } }
torus { 1.5,.1 rotate 90*x translate 4*z pigment { rgb .2 } }
plane { -z,-7 pigment { rgb .7 } }
/*
// scene 1
light_source{
y
1
area_light 3*x, z, 7, 1
area_illumination on
}
union {
sphere { 0,.05 }
sphere { .5*x,.05 }
sphere { x,.05 }
sphere { 1.5*x,.05 }
sphere { -.5*x,.05 }
sphere { -x,.05 }
sphere { -1.5*x,.05 }
translate y
hollow pigment { rgbt 1 } interior { media { emission 10 } }
}
// end scene 1
*/
// scene 2
#declare Light = light_source {
0
1/7
looks_like { sphere { 0,.05 hollow pigment { rgbt 1 } interior { media { emission 10 } } } }
}
union {
object { Light }
object { Light translate .5*x }
object { Light translate x }
object { Light translate 1.5*x }
object { Light translate -.5*x }
object { Light translate -x }
object { Light translate -1.5*x }
translate y
}
// end scene 2
|
|
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.
|
|
301 | Other | Definite Bug | 3.70 RC7 | Very Low | Low | Fallback to default image size causes wrong values to b... | Tracked on GitHub | |
|
Task Description
When resolution is not specified (neither via POVRAY.INI nor via QUICKRES.INI nor via command line or custom .ini file), random values are displayed for image resolution in the Image Output Options message output. (The actual render will be performed at the default size of 160×120 pixels though.)
|
|
306 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | High | finish subsurface block before global_settings subsurfa... | Tracked on GitHub | |
3.71 release |
Task Description
The following scene causes a crash:
sphere {
<0,0,0>, 1
finish { subsurface { translucency 1.0 } }
}
global_settings {
subsurface { }
}
|
|
309 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | Warning Message Missing | Tracked on GitHub | |
3.71 release |
Task Description
Draw_Vistas, Light_Buffer, and Vista_Buffer (plus associated switches) do not issue warning when used, even tho code has been disabled.
|
|
321 | Other | Definite Bug | 3.70 release | Very Low | Low | bounding threshold inconsistency | Tracked on GitHub | |
|
Task Description
User reported documentation inconsistency. Investigation led to the discovery of a bug in the setting of the current default value.
~source/frontend/renderfrontend.cpp reports the value “3” while ~source/backend/scene/scene.cpp sets a default value of “1”
Before for addressing this issue, are there any thoughts as to what the default value should be?
|
|
324 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | High | 3.7 mesh2 rendering artifact, regression from 3.6 | Tracked on GitHub | |
|
Task Description
Povray 3.7 has rendering artifact in meshes with polygons that meet at shallow angles. Please see the attached file.
The part of concern is the mesh2, which produces the partly-transparent faces of a shallow pyramid. The file result-3_6.png shows the output of povray-3.6, and the file result-3_7.png shows the output of povray-3.7. In 3.7, you can see a thin light-colored margin all around the base of the pyramid, especially thick under the top cylinder. In 3.6, this artifact is absent. For comparison purposes, I have inserted a “#version 3.6;” directive at the top of the file so that the output images are as close to each other as possible. However, the artifact is still present in 3.7 without this directive.
The attached scene file is only a small part of a much larger scene, where this artifact shows up in numerous very obvious places, where it doesn’t in 3.6. I have hunted in the documentation and online for ways to solve this problem, but haven’t found anything. Because of this, I am forced to stay with 3.6 for production use, which is quite unfortunate since I’d like to take advantage of the new features of 3.7.
|
|
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.
|
|
328 | User interface | Definite Bug | 3.70 release | Very Low | Medium | Ascii char '=' in filenames causes command line parsing... | Tracked on GitHub | |
|
Task Description
The following command fails with parsing error: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.pov +W1000 +H1000
The following command succeeds: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.pov +W1000 +H1000
Any option that gets a filename as parameter will fail if it contains ‘=’.
It is a regression, as it worked fine with 3.6.
|
|
25 | Animation | Definite Bug | 3.70 beta 32 | Defer | Low | Pause sometimes fails when rendering animation | Tracked on GitHub | |
|
Task Description
There is an issue where the pause button in POVWIN will sometimes not work during an animation (primarily where the frame rate is high), and furthermore, POVWIN can then get into a state where it’s not possible to use the pause until it is re-started.
Newsgroup report.
|
|
237 | User interface | Definite Bug | 3.70 RC3 | Defer | Very Low | Glitch in displaying rendered pixels and percentage | Tracked on GitHub | |
|
Task Description
When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal are first displayed like this: Rendered 126202 of 360000 pixels (35%) Then on the second stage the output text becomes shorter and you see Rendered 25344 of 360000 pixels (7%)%) The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.
I’m running Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu) compiled for the Arch Linux package.
|
|
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)
|
|
303 | Other | Definite Bug | 3.70 RC7 | Defer | Very Low | wrong bit depth reported for OpenEXR file format | Tracked on GitHub | |
|
Task Description
When using OpenEXR output file format, POV-Ray erroneously reports it as “24 bpp EXR” in the message output, while in fact it generates a 3×16 = 48 bpp file.
|
|
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.
|
|
27 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | Add texture support to background statement | Tracked on GitHub | |
Future release |
Task Description
Adding full texture statement support to the background statement (with a scale of 1/1) aligned with the image_map direction of an image would allow i.e. specifying an image as background easily.
|
|
28 | Frontend | Feature Request | 3.70 beta 32 | Very Low | Low | #debug message not displayed. | Tracked on GitHub | |
Future release |
Task Description
The #debug message stream is only being flushed when it hits a newline character, instead of after each #debug statement. This means that some final strings don’t show up.
#debug "This line prints,\n but this line doesn't."
|
|
41 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | improve command-line parsing error messages | Tracked on GitHub | |
|
Task Description
POV-Ray 3.6, upon encountering problems when parsing command line and/or .ini file options, would quote the offending option in the error message.
POV-Ray 3.7 currently just reports that there is some problem with the command line, without providing any details. I suggest changing this, as the information may be helpful at times.
|
|
44 | Radiosity | Feature Request | All | Very Low | Low | Improve Normals Handling in Radiosity | Tracked on GitHub | |
Future release |
Task Description
Currently, radiosity does not make use of the fact that pertubed normals would theoretically just require a different weighting of already-sampled rays, leading to the following issues:
Honoring normal pertubations in radiosity leads to an increased number of samples, slowing down sample cache lookup.
The increased number of samples is generated from a proportionally higher number of sample rays, slowing down pretrace even further.
Low-amplitude pertubations tend to be smoothed out; “reviving” these is only possible by increasing the general sample density.
Handling of multi-layered textures with different normal pertubations is currently poorly implemented.
As a solution, I propose to store for each radiosity sample not only the resulting illumination for a perfectly unpertubed normal, but from the same set of sample rays also compute the illumination for an additional set of about a dozen standardized pertubed-normal directions, and interpolate among these when computing the radiosity-based illumination for a particular point that has a pertubed normal.
For backwards compatibility, this method of dealing with pertubed normals in radiosity might be activated by a different value for the “normal” statement in the radiosity block, say, “normal 2”.
|
|
65 | Parser/SDL | Feature Request | 3.70 beta 34 | Very Low | Low | Add support for vectors with functions | Tracked on GitHub | |
Future release |
Task Description
Being able to have functions operate on vectors would be pretty nice to have.
|
|
79 | Source code | Feature Request | 3.70 beta 35a | Very Low | Low | Full-Featured Test-Scene to check the correctness of po... | Tracked on GitHub | |
Future release |
Task Description
Hi,
it would be nice if there exists a test scene (not a benchmark) which has a high coverage of povray source and can be used as correctness validation of povray. It schould be produce an image which can be compared to a golden reference image.
It may be also possible to create a regression test suite which does automatic comparision of the render results.
|
|
96 | Texture/Material/Finish | Feature Request | Not applicable | Very Low | Low | User-defined warps | Tracked on GitHub | |
Future release |
Task Description
User-defined warps would be nice to have, something along the lines of:
warp {
function { MyFnX(x,y,z) } // function to compute pattern-space x-coordinate from object-space <x,y,z> coordinate
function { MyFnY(x,y,z) } // ditto for pattern-space y coordinate
function { MyFnZ(x,y,z) } // ditto for pattern-space z coordinate
}
// a displacement warp:
warp {
function { x + MyFnX(x,y,z) }
function { y + MyFnY(x,y,z) }
function { z + MyFnZ(x,y,z) }
}
|
|
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
|
|
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.
|
|
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.
|
|
127 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Expandable arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, arrays are of a fixed size. You can’t add or remove items to/from an array. I think it would like arrays to be expandable with no fixed and pre-determined size.
|
|
131 | Other | Feature Request | 3.70 beta 37a | Very Low | Low | Ability to change the order of editor tabs by dragging ... | Tracked on GitHub | |
Future release |
Task Description
See Notepad++ or EditPad Lite for examples.
It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.
|
|
138 | User interface | Feature Request | 3.70 beta 37a | Very Low | Low | "Rename" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great if there were a “Rename” option in the editor File menu to rename the current file name. Otherwise, you have to close the file, rename it in file manager, then open the file again, thus loosing the current tab position and undo history for the file.
|
|
140 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Reload" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.
|
|
142 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | camera_view pigment from MegaPOV | Tracked on GitHub | |
Future release |
Task Description
I probably don’t have to explain why the camera_view pigment in MegaPOV was important, but I will list some reasons anyway:
1) post-processing could be performed in-scene 2) new types of focal blur effects could be created 3) feedback fractals were possible
I’m sure there are many others, as this is one of those features that has undetermined potential!
|
|
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.
|
|
177 | Light source | Feature Request | 3.70 beta 39 | Very Low | Low | Add support for conserve_energy to shadow computations | Tracked on GitHub | |
|
Task Description
The following scene gives a comparison of current conserve_energy handling in standard shadow computations vs. photons.
Note how the rather highly reflective slabs fail to cast shadows, except where the photons target sphere enforces computation of shadow brightness to be done by the photons algorithm.
For more realistic shadowing without the need to enable photons, I suggest do add proper conserve_energy handling to the shadow computation code (which shouldn’t be too much effort).
global_settings {
max_trace_level 10
photons { spacing 0.003 media 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
photons {
refraction on
reflection on
}
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb 0.7 } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0
specular 0.2 // just to give a hint where the sphere is
}
}
interior { ior 1.0 }
}
#declare M_PseudoGlass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.5
specular 0.6
roughness 0.005
reflection { 0.3, 1.0 fresnel on }
conserve_energy
}
}
interior { ior 1.5 }
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
// behind target object
box {
<-0.2,0,-2.3>, <0.0,4,0.3>
material { M_PseudoGlass }
rotate z*1 // just to better see the reflection of the horizon
}
// before target object
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_PseudoGlass }
photons { pass_through }
rotate z*1 // just to better see the reflection of the horizon
}
|
|
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
}
|
|
229 | Image format | Feature Request | 3.70 RC3 | Very Low | Low | Clock value into EXIF data for PNG | Tracked on GitHub | |
|
Task Description
The best time for a picture....
I set the day time and so the position of the sun by “clock=”
Normal I document my source very good, but this time, I forgot the clock seting for the picture of my book cover.
So I would find it very practicall to put the clock value and other setings for rendering into EXIF data of the picture.
|
|
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
|
|
240 | Geometric Primitives | Feature Request | 3.70 RC3 | Very Low | Low | Object for efficient automatic periodic pavement | Tracked on GitHub | |
|
Task Description
Whenever some object is to be periodically repeated in some kind of grid, you can achieve this with macros, but it a) wastes a lot of resources
even if object references are implemented in the future, wrapper with its own transformation matrix still takes space and bookkeeping
b) is not infinite
annoying when making infinite planar tiling with arbitrary objects
like an approximate water surface or tiling with real bricks
or anything that needs to extend to horizon
c) is not optimized for periodicity
I think it can be very efficiently implemented as an object that takes a finite object argument (like CSG functions) and can be periodic in either 1D,2D or (possibly dangeorous?) 3D with specified period. In each dimension, the number of repetitions can be any integer or even infinity (or max_int). Something like periodicity <2,2,Infinity> 2 copies in 1 direction, 2 in the other, infinite in the third grid_separation <1,2,2> 1 unit size in first direction, 2 unit sizes in the other two
All the code needs to do is raytrace in the current unit cell and if the ray passes uninterrupted, pass it through the neighbouring unit cell (which means trace a translated ray through the same object). The object itself would just feel an additional clipping box, everything else would work seamlessly.
In case of infinite column of transparent object, max_trace stops the infinite loop anyway.
This is just a suggestion, I realize this is more of a long-term change but it is quite easy to implement and would simplify a large number of projects.
|
|
248 | Parser/SDL | Feature Request | Not applicable | Very Low | Low | Implement mechanism to compute direction of a spline | Tracked on GitHub | |
Future release |
Task Description
The SDL currently provides no way to compute the exact direction of a spline at a given location, even though mathematically this is a piece of cake: The first-order derivative of any spline section gives you the “speed” as a vector function, and is trivial to compute for polynomial splines (which are behind all spline types that POV-Ray supports); the normalized “speed” vector, in turn, gives the “pure” direction.
For exact direction/speed computations, I propose to extend the SDL invocation syntax as follows to allow for evaluating a spline’s derivative:
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, SPLINE_TYPE] [, FLOAT] )
or
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, FLOAT] [, SPLINE_TYPE] )
where the second FLOAT will specify the order of derivative to evaluate (defaulting to 0). In order to compute the position, direction, and acceleration of an object traveling along a certain spline, one could then for instance use:
#declare S = spline { ... }
#declare Pos = S(Time);
#declare VSpeed = S(Time,1);
#declare VAccel = S(Time,2);
#declare Dir = vnormalize(VSpeed);
#declare Speed = vlength(VSpeed);
#declare AccelDir = vnormalize(VAccel);
#declare GForce = vlength(VAccel) / 9.81;
Alternatively, a mechanism may be devised to create a spline representing another spline’s derivative; however, it would be debatable whether the syntax should be parameter-like (being an added information that could be overridden again when creating other splines from such a derived spline), or operation-like (converting the spline), and in the latter case how it should affect spline type (and consequently control points); so the spline invocation parameter approach might be more straightforward, with less potential surprises for the user.
|
|
256 | Texture/Material/Finish | Feature Request | 3.70 RC6 | Very Low | Low | CSG texturing modes | Tracked on GitHub | |
|
Task Description
At times, the current method of specifying texture for CSG components and compounds is restricting. The issue pops up now and then, see e.g.
http://news.povray.org/povray.pov4.discussion.general/thread/%3Cweb.4799def8e1857b77c150d4c10%40news.povray.org%3E/
http://news.povray.org/povray.general/thread/%3Cweb.4fc892634f065c00e32b83540@news.povray.org%3E/
http://news.povray.org/povray.general/thread/%3Cweb.5073e9f7dae1fbb2d97ee2b90%40news.povray.org%3E/
There should be a new CSG option “texture_mode” or similar, which could take one of the following values:
preserve (the current behavior) cutaway (the current behavior when specifying cutaway_textures) override (replace all individual textures with compound texture) layer (layer the compound texture over the existing textures)
and possibly, more involved
modify/merge: if both element and compund textures are simple, i.e. not layered or mapped, override all default values of the element textures with the values from the compound texture. The idea would be to, e.g., have the elements already pigmented but then apply common normal or finish properties.
|
|
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.
|
|
278 | Backend | Feature Request | 3.70 RC7 | Very Low | Medium | Implement Lens Flare Rendering | Tracked on GitHub | |
|
Task Description
Currently POV-Ray does not support rendering lens flare effects, however, they can be simulated using a macro (include file) by Chris Colefax.
I would like to suggest adding a feature to POV-Ray to support lens effects “natively” since
as far as I know the macro has been designed for POV-Ray 3.1 so with each new POV-Ray version it gets more likely that this macro does not work properly any more
the macro does not work when rendering with radiosity, probably because the macro creates the lens effect by using a pigment with a high ambient value (which is ignored by POV-Ray 3.7’s radiosity algorithm).
Additionally, the macro is not quite easy to employ because
it needs to know the exact camera parameters (location etc.) and defines an own camera itself so any important camera information has to be stored if the effect has to work as expected
it does not (actually cannot) take into account that objects may (partially) hide the lens effect
reflections and refractions (of light sources) cannot be combined with it properly - the user would have to calculate both the point where the reflected/refracted light source can be observed and the shape it then has due to distortion, and in more complex scenes such computations are nearly impossible in SDL.
I would suggest integrating such a lens flare rendering feature with the “looks like” mechanism you already have for light sources. Several parameters that can currently be set for the macro - including effect brightness and intensity, lens options and whether to create a flare at all - could be set for the light source.
Then POV-Ray could store the location and colour of each ray that finally intersected the “looks like” object of a light source and, having finished the main rendering, from that data compute a partially transparent “lens flare layer” eventually mixed into the rendered image. By this, the above mentioned problems could be avoided:
an object fully or partially intersecting a light source’s “looks like” object would also reduce the number of pixels used to create a flare - and therefore reduce that flare until fully hiding it
the same goes for reflected and/or refracted versions of the “looks like” object
the camera’s location and other properties would be used automatically
and finally, as a feature supported by POV-Ray itself, there would be neither compatibility issues nor problems like the effect not fitting together with radiosity.
Do not get me wrong, I would not expect POV-Ray to really calculate intersections that naturally happen in a camera lens, causing lens flares. Effects looking appropriate can actually be created just in 2D space (as some graphics programs do support) so the work to be done would, as far as I have any overview, be:
storing, as mentioned above, the relevant data for pixels showing “looks like” objects
calculating a lens flare from that data after the render has finished
overlaying the rendered image with the newly created lens effect.
|