|
242 | Other | Feature Request | All | Defer | Very Low | Algorithm to fix the so-called shadow line artifact | Tracked on GitHub | |
|
Task Description
The so-called shadow line artifact (http://wiki.povray.org/content/Knowledgebase:The_Shadow_Line_Artifact) which affects objects with a ‘normal’ statement as well as smooth meshes and heightfields can be really annoying sometimes. Currently the only way to remove it is to make the object shadowless, which isn’t a good solution except in very special cases.
This algorithm could remove the artifact: If the actual normal vector of the object points away from the light source (its dot-product with the light vector is negative) but the perturbed normal points towards it (dot-product positive), then ignore the first shadow-test intersection with the object itself.
There are alternative ways of implementing an equivalent functionality:
- Don’t check the condition (if it’s too difficult to check due to how the code is designed) but always ignore the first intersection with the objects itself. This will work properly with closed surfaces but not with open ones, so it might need to be a feature for the user to turn on with a keyword (similar to eg. ‘double_illuminate’).
- Alternatively, don’t ignore the first intersection, but instead ignore the “opposite side” of the object’s surface (again, possibly only if a keyword has been specified). In other words, if we are rendering the outer side of the object, ignore its inner side when shadow-testing, and vice-versa.
- Perhaps simply add a feature to make surfaces one-sided (similarly to how they can be made so in OpenGL and similar scanline rendering systems). In other words, the inner side of a surface is completely ignored everywhere, making the object virtually invisible from the inside. The advantage of this feature would be that it can have uses other than simply removing the shadow line artifact.
|
|
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.
|
|
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
|
|
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.
|
|
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
}
|
|
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
}
|
|
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.
|
|
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!
|
|
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.
|
|
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.
|
|
133 | Geometric Primitives | Feature Request | 3.70 beta 37a | Defer | Very Low | Subdivision support | Tracked on GitHub | |
Future release |
Task Description
Someone built a version of Povray with internal support for automatic subdivision of meshes. See:
http://www.cise.ufl.edu/~xwu/Pov-Sub/
Would like to see this feature added natively to Povray.
|
|
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.
|
|
129 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | Hash arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
|
|
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.
|
|
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.
|
|
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
|
|
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) }
}
|
|
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
|
|
87 | Geometric Primitives | Feature Request | Not applicable | Defer | Very Low | Add new feature: Reference object | Tracked on GitHub | |
Future release |
Task Description
When you instantiate an object several times, eg:
object { MyObj translate -x*10 }
object { MyObj translate x*10 }
POV-Ray will copy that object in memory, at least for most types of objects. Not for all of them, though. Most famously if MyObj is a mesh, it won’t be copied, but only a reference to the original will be used, thus saving memory. (There are a few other primitives which also don’t cause a copy, such as bicubic_patch and blob, but those are naturally not so popular as mesh, so it’s a less known fact.)
AFAIK the reason why referencing (rather than copying) is not used for all types of objects is rather complicated, and mostly related to how transformations are applied to these objects. For example if the object being instantiated is a union, the translates above will be (AFAIK) applied to the individual members of the union rather than to the union object itself.
Copying, however, can be quite detrimental in some situations. For example if you have a huge union, and you want to instantiate it many times, the memory usage will be that many times larger (compared to just one instance). This is sometimes something which the user would not want, even if it made the rendering slightly slower as a consequence. (In other words, better to be able to render the scene in the first place, rather than running out of memory.)
Redesigning POV-Ray so that all objects would be referenced rather than copied would probably be a huge job, and in some cases a questionable one. There probably are situations where the current method really produces faster rendering times, so redesigning POV-Ray so that it would always reference instead of copy, could make some scenes render slower.
So this got me thinking about an alternative approach: How hard would it be to create a special object which sole purpose is to act as a reference to another object, without copying it? This special reference object would act as any regular object, would have its own transformation matrix and all that data related to objects, but its sole purpose is to simply be a “wrapper” which references an existing object. It could be, for example, like this:
object_ref { MyObj translate -x*10 }
object_ref { MyObj translate x*10 }
The end result would be exactly identical as earlier, but the difference is that now MyObj behaves in the same way as a mesh (in the sense that it’s not instantiated twice, but only once, even though it appears twice in the scene), regardless of what MyObj is.
In some cases this might render slightly slower than the first version (because POV-Ray has to apply the transformations of the object_ref first, after which it applies whatever transformations are inside MyObj), but that’s not the point here. The point is to save memory if MyObj is large.
An object_ref would behave like any other object, so you could do things like:
#declare MyObjRef = object_ref { MyObj };
object { MyObjRef translate -x*10 }
object { MyObjRef translate x*10 }
(The only thing being instantiated (and copied) here is the “MyObjRef” object, not the object it’s referring to, so that actual object is still stored in memory only once.)
In some situations it might even be so that referenced objects actually render faster than if the objects were copied because references increase data locality, lessening cache misses.
I believe this could be a rather useful feature and should be seriously considered, unless there are some major obstacles in implementing it.
|
|
86 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Add support for more RNG types | Tracked on GitHub | |
Future release |
Task Description
The current 32-bit linear congruential generator used as RNG in POV-Ray is sometimes quite limited for some purposes and in a few cases its poor quality shows up (as has been demonstrated more than once in the newsgroup). Thus it would be nice if POV-Ray offered additional, higher-quality random number generators, besides the current one (which should probably remain for backwards compatibility). These RNGs could include algorithms like the Mersenne Twister and the ISAAC RNG, both of which have very decent quality and have an enormous periods (while at the same time being very fast).
After a long discussion, the following syntax for specifying the RNG type and seed (which may be larger than 32 bits) has been suggested:
seed(<value>) | seed(<type>, <value> [, <values>])
For example:
#declare Seed1 = seed(123); // Use the current RNG, with seed 123
#declare Seed2 = seed(1, 123); // Identical to the previous one
#declare Seed3 = seed(2, 456, 789, 123); // Use RNG algorithm #2,
// with a large seed (96 bits specified here)
A C++ implementation of the ISAAC RNG can be found at http://warp.povusers.org/IsaacRand.zip
|
|
85 | Other | Feature Request | Not applicable | Defer | Low | Aspect ratio issues | Tracked on GitHub | |
Future release |
Task Description
Background
When rendering an image, there are actually three aspect ratios involved:
1) The aspect ratio of the camera, set with the up and right vectors.
2) The aspect ratio of the rendered image, set with the +W and +H parameters.
3) The aspect ratio of the pixels in the intended target medium. While this is very often 1:1, it’s definitely not always so (anamorphic images are common in some media, such as DVDs).
The aspect ratio of the camera does not (and arguably should not, although some people might disagree) define the aspect ratio of the image resolution, but the aspect ratio of the image as shown on the final medium. In other words, it defines how the image should be displayed, not what the resolution of the image should be.
This of course means that the aspect ratio of the target medium pixels has to be taken into account when specifying the image resolution. If the target medium pixels are not 1:1 (eg. when rendering for a medium with non-square pixels, or when rendering an anamorphic image eg. for a DVD), the proper resolution has to be specified so that the aspect ratio of the displayed image remains the same as the one specified in the camera block.
This isn’t generally a problem. It usually goes like “my screen is physically 4:3, so I design my scene for that aspect ratio, but the resolution of my screen is mxn which is not 4:3, but that doesn’t matter; I just render with +Wm +Hn and I get a correct image for my screen”.
However, problems start when someone renders an image using an image aspect ratio / pixel aspect ratio combination which does not match the camera aspect ratio. By far the most common situation is rendering a scene with a 4:3 camera for a screen with square pixels but with a non-4:3 resolution (most typically 16:9 or 16:10 nowadays). The image will be horizontally stretched.
In a few cases the effect is the reverse: The scene (and thus the camera) has been designed for some less-typical aspect ratio, eg. a cinematic 2.4:1 aspect ratio, but then someone renders the image with a 4:3 resolution. The resulting image will be horizontally squeezed.
In a few cases this is actually the correct and desired behavior, ie. when you are really rendering the image in an anamorphic format (eg. for a DVD). However, often it’s an inadverted mistake.
Some people argue that this default behavior should be changed. However, there are also good arguments why it should not be changed. Some argue that POV-Ray should have more features (at the SDL level, at the command-line level or both) to control this behavior.
There are several possible situations, which is why this issue is so complicated. These situations may include:
- The scene author doesn’t really care what aspect ratio is used to render the image, even if it means that additional parts of the scenery become visible or parts are cropped away when using a different aspect ratio than what he used.
In this case the choice of camera aspect ratio should be up to the person who renders the image, and thus selectable on the command-line. However, he should have an easy choice of how changing the aspect ratio affects the image: Should it extend the viewing range, or should it crop part of it, compared to the original?
And this, of course, while still making it possible to render for an anamorphic format.
- The author wants to support different aspect ratios, but he wants to control precisely how it affects the composition of the image. Maybe he never wants anything cropped away within certain limits, but instead the image should always be extended in whichever direction is necessary due to the aspect ratio. Or maybe he wants to allow cropping the image, but only up to a certain point. Or whatever.
In this case the choice of camera aspect ratio should be up to the author, and thus selectable in the scene file, while still allowing some changes from the command-line.
- The author designed his scene for a precise aspect ratio and nothing else, and doesn’t want the image to be rendered in any other aspect ratio. Maybe he used some very peculiar aspect ratio (eg. something like 1:2, ie. twice as tall as wide) for artistic composition reasons, and wants the image rendered with that aspect ratio, period.
Perhaps the author should be able to completely forbid the change of camera aspect ratio in the command-line.
Of course anamorphic rendering should still be supported for targets with a different pixel aspect ratio.
Possible solution
This solution does not necessarily address all the problems described above perfectly, but could be a good starting point for more ideas:
Add a way to specify in the camera block minimum and maximum limits for the horizontal and vertical viewing angles (and if any of them is unspecified, it’s unlimited). Of course for this to be useful in any way, there should also be a way to change the camera and pixel aspect ratios from the command line.
The idea with this is that the author of the scene can use these angle limits to define a rectangular “protected zone” at the center of the view, using the minimum angle limits. In other words, no matter how the camera aspect ratio is modified, the horizontal and/or vertical viewing angles will never get smaller than these minimum angles. This ensures that the image will never be cropped beyond a certain limit, only extended either horizontally or vertically to ensure that the “protected zone” always remains fully visible regardless of what aspect ratio is used.
The maximum angles can be used for the reverse: They ensure that no scenery beyond a certain point will ever become visible, no matter what aspect ratio is used. This can be used to make sure that unmodelled parts of the scene never come into view. Thus the image will always be cropped to ensure this, depending on the aspect ratio.
I’m not completely sure what should be done if both minimum and maximum angles are specified, and the user specifies an aspect ratio which would break these limits. An error message could be a possibility. At least it would be a way for the author to make sure his scene is never rendered using an aspect ratio he doesn’t want. He can use these angle limits to give some leeway how much the aspect ratio can change, to an extent, or he could even force a specific aspect ratio and nothing else (by specifying that both the minimum and maximum angles are the same).
So in short:
- Add a “minimum/maximum horizontal/vertical angles” feature to the camera block. These can be used to define a “protected zone” in the image which must not be breached by command-line options.
- Add a command-line syntax to change the camera aspect ratio (which automatically obeys the “protected zone” settings). Could perhaps give an error message if the command-line options break the limits in the scene camera.
- Add a command-line syntax to specify a pixel aspect ratio other than 1:1. This can be used to render anamorphic versions of the image on purpose (iow. not by mistake).
This can probably be made backwards-compatible in that if none of these new features are used, the behavior could be the same as currently (or at least similar).
|
|
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.
|
|
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.
|
|
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”.
|
|
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.
|
|
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."
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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?
|
|
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
|
|
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.
|
|
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 { }
}
|
|
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.
|
|
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.)
|
|
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)
|
|
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.
|
|
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
|
|
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}
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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
|
|
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.
|