|
288 | Geometric Primitives | Possible Bug | 3.70 RC7 | Very Low | Low | Tolerance problem with refraction in blobs in CSG inter... | Tracked on GitHub | |
|
Task Description
If a blob is intersected by something else, the composite object has incorrect refractions if it is too small (in absolute units). Having the same object constructed without a blob, the errors happen at much smaller scales. The errors don’t affect solid objects, just refractions.
An example shows a half-sphere, constructed as CSG sphere + plane, and identical half-pshere, constructed as CSG blob + plane. When the scale of the entire construction is changed, the refractions disappear first for the blob, and at 100x times smaller scale, also for the sphere. The right side shows the solid version, showing that the surface intersection test is ok, it’s just the refraction that fails.
The problem is not present when looking from the curved side (the blob side). So the ray that hits the blob, gets refracted correctly, but the ray that hits the intersecting plane first, and should then refract in the blob from the inside, doesn’t work. If in attached sphere, you exchange -y with y in clipping planes, everything is ok.
The scale when this happens is not very small - blobs of radius 0.02 already fail (noticed because in 1=1metre scale, blob raindrops on a glass plate didn’t have intersections when looking from the back).
Examples are named by factor=9,0.9,0.09,0.009 and you can see first the blob (top) refraction gets smaller and disappears, then later the bottom (sphere) also gets the same problem.
|
|
289 | Light source | Possible Bug | 3.70 RC7 | Very Low | Low | area_illumination with light fading and scattering medi... | Tracked on GitHub | |
|
Task Description
with reference to http://bugs.povray.org/task/46
still some issue with area illumination and light fading when interacting with media
seems light fade is not taken into account with scattering media. emission and absorption media seem to work fine. occurs with all scattering types.
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
#declare Light = 3; // light 1 = individual lights
// light 2 = standard area light
// light 3 = area light with area illumination
#declare Fade = 1; // light fading: 1 on, 0 off
#declare Media = 1; // media 1 = scattering
// media 2 = emission
// media 3 = absorption
#declare Type = 1; // scattering media type
#switch(Light)
#case(1)
#declare Ls = light_source {
0
1/7
#if(Fade) fade_distance 2 fade_power 2 #end
}
union {
object { Ls }
object { Ls translate .5*x }
object { Ls translate x }
object { Ls translate 1.5*x }
object { Ls translate -.5*x }
object { Ls translate -x }
object { Ls translate -1.5*x }
translate y
}
#break
#case(2)
light_source{
y
1
area_light 3*x, z, 7, 1
#if(Fade) fade_distance 2 fade_power 2 #end
}
#break
#case(3)
light_source{
y
1
area_light 3*x, z, 7, 1
#if(Fade) fade_distance 2 fade_power 2 #end
area_illumination on
}
#break
#end
cylinder { <0, .01, 0>, <0, 5, 0>, 2 pigment { rgbt 1 } hollow no_shadow
interior {
media {
#if(Media = 1) scattering {Type, 30 } #end
#if(Media = 2) emission 2 #end
#if(Media = 3) absorption 2 #end
density { cylindrical turbulence 1.5 scale <1, .14, 1> }
}
}
scale <.15, 1, .4> translate 4*z
}
plane { y,0 pigment { rgb .7 } }
plane { -z,-7 pigment { gradient y color_map { [.5 rgb 1][.5 rgb 0] } } }
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 } }
}
|
|
291 | Include files | Possible Bug | 3.70 RC7 | Very Low | Low | Math.inc: error in VDist function | Closed | |
|
Task Description
Included math.inc into scene and recieved this fatal error from povray:
File '/usr/local/share/povray-3.7/include/math.inc' line 248: Parse Error: Expected 'string expression', float function 'vlength' found instead
Appropriate place in math.inc:
245 > #end
246 >
247 > // Distance between V1 and V2
248 > #macro VDist(V1, V2) vlength(V1 - V2) #end
249 >
250 > // Returns a vector perpendicular to V
Running newly-downloaded/newly-compiled POV-Ray 3.7.0, on Linux x86_64 system
|
|
292 | Geometric Primitives | Unimp. Feature/TODO | 3.70 RC7 | Very Low | Low | Arbitrary containing object for isosurfaces | Tracked on GitHub | |
|
Task Description
A low priority thought for the future: isosurface now only allows contained_by to be a sphere or a box. It would be more intuitive to allow the same objects that are allowed in clipped_by and bounded_by (although it probably needs to be finite). It would enable allow much faster rendering in many cases:
1) There are a lot of cases when the sphere or a box are very bad in bounding - if an object has a hole, a torus may be better, and in many cases, cylindrical bounding would help a lot. 2) Sometimes, having a too large contained_by object includes far-away parts of the iso-function, and expose large gradients that you want to avoid. If a bounding object is better, you can decrease the max_gradient and speed up the render. 3) The isosurface is usually much more expensive to calculate than any normal bounding object, so it’s an improvement even if the intesection test is not as fast as bounding box. 4) A typical case: if you use texture-like functions to make the surface realistically rough, you know almost exactly what the bounding object is - it can be the original unmodified object. 5) For isosurface terrains, a preprocessing macro could create a rough mesh-like bounding object to contain the “mountains”, thus making everything faster. 6) In case you want clipping, having the contained_by set to the same object probably avoits calculating too many intersections.
The main modification is probably that the intersections of bounding objects can be split into more than one interval - but it’s probably worth it, the isosurfaces are usually a speed bottleneck.
|
|
293 | User interface | Possible Bug | 3.70 RC7 | Very Low | Low | POV-Ray Shown Twice in Windows Taskbar | Tracked on GitHub | |
|
Task Description
When rendering for some time, it occasionally happens that POV-Ray appears twice in the Windows taskbar. One button is the normal one, the other one does not open any window when clicked on and reads something like “99% complete” (see attached image), like the render window’s title, but obviously unrelated to it (probably the title the render window had shortly before?). After stopping the render, the odd taskbar button remains there until POV-Ray is closed.
Observed under Windows XP
POV-Ray 3.7.0.RC7.msvc10-sse2.win32
When applications are summarized into groups in the taskbar by Windows, the odd POV-Ray button is attached to the Windows Explorer group
Run with render priority set to “high”
Is this a Bug in Windows or in POV-Ray?
|
|
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.
|
|
297 | Other | Feature Request | 3.70 RC7 | Very Low | Low | Have a user-definable epsilon | Closed | |
|
Task Description
There are times when scaling an entire scene up or down is difficult or just not feasible.
One suggestion is a global_settings option.
Also, I’ve noticed that in some situations, such as interactions between certain transparent objects, the epsilon seems to kick in quite early. Perhaps there could be situational or contextual epsilons, such as the “tolerance” of sphere_sweep or the “accuracy” of isosurface.
|
|
298 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Low | the warning for isosurface does not appears as often as ... | Closed | |
|
Task Description
From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)
William F Pokorny anonymous@anonymous.org wrote: > It seems to be the case the gradient warnings are only generated if the > isosurface is naked. If it is wrapped in an object as was the case with > my thread safety example, we get no warnings.
Confirmed. If only I still had the concentration required to investigate computer code.
#version 3.7;
#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end
global_settings
{ assumed_gamma 1
radiosity {} //force isosurface calculations from all directions
}
light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }
camera
{ location <0.0000, 1.0000, -5.6713>
look_at <-0.7969, 1.2000, -0.0598>
angle 10.7447
}
#include "functions.inc"
#if (Naked)
isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
#else
#declare Test = isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
object { Test }
#end
On the command line, try:
declare=MG=1 declare=Naked=1
and
declare=MG=1 declare=Naked=0
To lose the warning, I had to declare the isosurface. Just wrapping the naked isosurface in an object{} generated a warning.
Further analysis
isCopy seems to be intended to avoid displaying the same warning over and over for the same isosurface (as duplicated isosurface indeed are not copied but reference the same sub-structure).
#declare Ob = isosurface{...}; that’s not a copy object {Ob ... } that’s a copy
Previously (3.6.1) the warning was displayed at the destruction of the isosurface (when the sub-structure was actually referenced by no one else)
if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))
In 3.7, isCopy was introduced with change 4707, 16th February 2009, along with the change introducing means for objects to submit message on shutdown. It was reported in windows source with change 4714, 21th February 2009.
If the symptom “isosurface embbeded in object (CSG) does not show the warning” is correct, it might be a “feature/bug”. The parser copied the isosurface object and deleted the original before the render started. When the render ends, it find only copies and because the refcnt is not used anymore (for that purpose), it miss the last remaining true data to display.
Instead of isCopy, what about adding in mginfo a boolean “printed_warning” (actual name should be more appropriate), set to false on creation, and turn to true on the first call (instead of last for 3.6.1) of the warning displaying function (test for false, set to true if false) ? (and dropping isCopy in the process)
For instance, i’m afraid the following sequence would fails with current code:
#declare Foo = isosurface{ ... }; #declare Bar = object { Foo ... }; #undef Foo;
(or any pop of #local context, such as building the isosurface via macro or loop, or replacing the value of a previous #declare/#local )
|
|
299 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Low | Object Properties Feature | Tracked on GitHub | |
|
Task Description
Up to POV-Ray 3.7 RC7 it has not been possible so far to declare custom properties for POV-Ray’s objects, which would be especially useful for complex objects defined in include files.
Currently, if you want to have an object (e.g. a car) with certain variable parameters (e.g. colour, wheel rotation, ...) defined in an include file and the parameters set by a scene file which uses the include file, you have to choose one of the following approaches:
1. use a macro
#macro car(colour, wheelrot, ...)
...
#end
or, 2. check parameters declared before, e.g.
#declare car =
union {
#ifdef (colour)
#local colour_internal = colour;
#else
#local colour_internal = default_colour;
#end
}
The resulting object would be used in the following way:
#include "car.inc" // include file once
object {
car(rgb <1,0,0>, 0, ...) // macro approach
}
// other approach
#declare colour = rgb <1,0,0>;
#declare wheelrot = 0;
...
#include "car.inc" // include file every time you want to have a car object instance
object {
car
}
Needless to say, both approaches are not quite optimal.
The macro approach needs only one #include directive and name conflicts will (hopefully) not be a problem. However, one would have to look up the parameter order of the macro in the include file, in the worst case every time the macro is used.
The other approach needs as many #include directives as car objects shall be instantiated, there can arise name conflicts with other inculde files used in the scene, and a (potentially long) list of parameters has to be declared before each #include. On the other hand, with this approach for any value it is clear which information it gives, e.g. #declare colour = rgb <1,0,0> can easily be read as ‘set car colour to “red”‘.
My suggestion would be creating an SDL feature to
One step up could be to even declare object classes along with them.
This could look like this:
// include file code
class car { // alternatively (without classes) use #declare car = object { ...
property colour = rgb <1,0,0>; // with default colour
union {
...
}
}
// scene file code
car { // alternatively (without classes) use object { car ... }
colour rgb <0,0,1>
}
Note that this solution makes the declarations much more concise and easy-to-read. Especially in scenes with many includes and animation scenes where objects’ properties have to be manipulated according to sometimes complex functions, this would be very useful. Please also consider that such user-defined objects can have dozens of properties.
|
|
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.)
|
|
302 | Other | Possible Bug | 3.70 RC7 | Very Low | Low | confusing error message when .ini file cannot be parsed | Tracked on GitHub | |
|
Task Description
When a command-line parameter in an .ini file cannot be parsed (such as “+a.3”), POV-Ray reports a “Problem with setting”, quoting the command line, rather than indicating that the problem occurred in an .ini file. This leads the user to think that the problem is with the command line itself, unnecessarily confusing him.
|
|
305 | Geometric Primitives | Feature Request | 3.70 RC7 | Very Low | Low | remove maximum component limit for blobs | Closed | |
|
Task Description
Blobs are currently limited to 1,000,000 components (with each cylindrical component counting as three: one cylinder + two end hemispheres); this limit may have served a historic purpose, but is now entirely arbitrary: The remaining code is limited only by the available RAM and the numeric limits of the int data type. The arbitrary maximum components limit per blob should therefore be removed.
Aside from unnecessarily limiting the power of the blob component, another drawback of the current test is that it is only performed after parsing of all the blob’s components, potentially hours after the limit had actually been reached.
|
|
307 | Image format | Definite Bug | 3.70 RC7 | Very Low | Low | netpbm, ppm, read bug where first data byte CR char | Closed | |
|
Task Description
I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.
Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.
The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.
The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.
I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.
The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.
Thanks for your time. Bill P.
|
|
310 | Editor | Feature Request | 3.70 RC7 | Very Low | Low | Editor should remember bookmarks | Tracked on GitHub | |
|
Task Description
Now the editor remembers only the cursor positions of the loaded files when starting a new PR session. It would be more friendly to remember whether the window was split or not, as well as the bookmarks.
|
|
312 | Other | Possible Bug | 3.70 release | Very Low | Low | Rendering stuck at 99% | Closed | |
|
Task Description
After a long parse period and a relatively quick rendering, POVray gets stuck at 99% when rendering the attached file.
Rendered at 6144x3072px with antialiasing set to 0.3.
Can anyone confirm?
|
|
319 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | Add interior to #default directive | Tracked on GitHub | |
|
Task Description
When working with predefined materials, it would be useful to have something like:
#if (!Use_photons)
#default { interior { caustics 1 } }
#end
#include "my_predefined_materials.inc"
Default medias or IORs could also be useful.
|
|
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?
|
|
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.
|
|
327 | Parser/SDL | Feature Request | 3.70 release | Very Low | Low | Support for non-ASCII characters in filename strings | Tracked on GitHub | |
|
Task Description
pov 3.7 Can not identify the Chinese.I give the texture map filename in chinese,it turns out parse error.
|
|
329 | Documentation | Possible Bug | 3.70 release | Very Low | Low | Mesh_camera type 0 output seems | Closed | |
|
Task Description
When using mesh_camera type ‘0’
The first line of the mesh output seems to be repeated resulting in incorrect light colour values.
If the first line of the texture is skipped then the values seem to be correct.
|
|
330 | Platform-specific | Definite Bug | 3.70 release | Very Low | Low | Typo in QUICKRES.INI | Closed | |
|
Task Description
Height=36084
[640×360, AA 0.3] Width=640 Height=36084 Antialias=On Antialias_Threshold=0.3
should be:
[640×360, AA 0.3] Width=640 Height=360 Antialias=On Antialias_Threshold=0.3
|
|
332 | User interface | Feature Request | 3.70 release | Very Low | Low | Progress animation in taskbar tabs | Closed | |
|
Task Description
On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.
Here is an example of Chrome downloading something and showing the progress in the taskbar:
http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg
Here is an example with Paint.NET instead:
http://www.getpaint.net/images/pdn351_superbarProgress.png
I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.
|
|
333 | User interface | Feature Request | 3.70 release | Very Low | Low | Make text in "about" alt+b dialog selectable with the m... | Tracked on GitHub | |
|
Task Description
When you press alt+b or access the “about” dialog in the Help menu it displays some text including software version number and list of contributors.
It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.
|
|
334 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | HLS colors | Tracked on GitHub | |
|
Task Description
It would be nice to be able to specify colors in HLS as well as RGB.
Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.
|
|
335 | Parser/SDL | Possible Bug | 3.70 release | Very Low | Low | macro works in variable but not in array | Tracked on GitHub | |
|
Task Description
This doesn’t work:
#declare pavement_object = array[2] {
object {trash_can_macro() scale 3/4 translate -x * 1/2},
object {potted_plant_macro(_CT_rand2) scale 3/4 scale 3/2 translate -x * 1/2}
}
This does work:
#declare trash_can_object = object {trash_can_macro()}; #declare potted_plant_object = object {potted_plant_macro(_CT_rand2)}; #declare pavement_object = array[2] {
object {trash_can_object scale 3/4 translate -x * 1/2},
object {potted_plant_object scale 3/4 scale 3/2 translate -x * 1/2}
}
Logically, I cannot see a reason for this to be so.
|
|
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.
|
|
30 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Custom progress information during parsing | Closed | |
|
Task Description
For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.
|
|
125 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Very Low | System variable to track whether a file has been includ ... | Closed | |
|
Task Description
Request a system variable to test whether a scene file has been included by another scene file.
For instance:
#if (is_included)
camera {...}
#end
|
|
136 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | String concatenation operator | Closed | |
|
Task Description
Using the concat function is tedious. Why not just have an operator with which to concatenate strings?
“Hello " + “world!”
“Hello " . “world!”
|
|
160 | Other | Feature Request | All | Very Low | Very Low | Parallel GPU processing support | Closed | |
|
Task Description
...for instance nVidia’s CUDA architecture, discussed here and other places.
General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.
|
|
193 | Sample scenes | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Very Low | "pure white" typo in "Insert Menu" bitmap - simple solu ... | Closed | |
|
Task Description
In the folder “ready made scenes”, there is the file “B0 - Basic scene 11 - pure white background.txt”. The text string to be rendered lacks the “e” in “pure”. Unfortunately, this makes the typo visible in the “Insert menu” preview image.
If the “e” is added, the text needs to be scaled a bit smaller (0.43 instead of 0.44) to fit inside the view.
The following code contains a possible “fix” (whatever). It would be great if someone could fix this easy issue:
text { ttf "arial.ttf", "pure white background", 0.02, 0.0 // thickness, offset
texture{ pigment{ color rgb<1,0.6,0>*0.5 }
finish { phong 0.1 }
} // end of texture
scale<1,1.25,1>*0.43
translate<-2.10,-0.30,0.00 >
} // end of text object ---------------------------------------------
|
|
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.
|
|
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.
|
|
300 | Other | Feature Request | 3.70 RC7 | Defer | Very Low | Reference Documentation Support | Tracked on GitHub | |
|
Task Description
As emerged as an idea during the discussion of FS#299, an SDL / POV-Ray editor feature would be useful that allows API documentation via formal comments, e.g. in include files:
/**
* Creates a car object.
* @param a
* description of param a
* ...
*/
#macro car(a,b,c)
...
#end
In addition to the ability of (auto-)generating a documentation file from such comments, an editor window feature would be convenient that allows popup display of a macro’s (object’s / parameter’s / ...) documentation section.
|
|
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.
|
|
323 | User interface | Possible Bug | 3.70 release | Very Low | Very Low | Tooltip for render speed status bar has wrong unit | Tracked on GitHub | |
|
Task Description
Tooltip popup for render speed always displays as “Pixels per Second” rather than matching status bar. I’ve noticed it in 3 renders so far. Most of my renders are fast enough not to see any other unit besides PPS, but I should be able to reproduce again if necessary.
|