|
71 | User interface | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Low | raise warning when command line option has no effect | Tracked on GitHub | |
|
Task Description
Warnings should be raised when a command line option has no effect, for example...
pvengine +am
is legal, but without the number after it, it has no effect.
pvengine +am7
should be an error, and also raises no warnings.
|
|
4 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | Integrate Subsurface Scattering with standard lighting ... | Tracked on GitHub | |
Future release |
Task Description
Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.
|
|
6 | Subsurface Scattering | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Integrate Subsurface Scattering with Photons | Tracked on GitHub | |
Future release |
Task Description
Subsurface scattering must be made photon-aware.
|
|
98 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Medium | Refactor Windows UI code for Unicode support | Tracked on GitHub | |
Future release |
Task Description
Windows UI code should be refactored to use _TCHAR throughout instead of char, as well as the corresponding string function macros, to head for Unicode support.
|
|
99 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Very Low | Refactor engine (front- & back-end) code for Unicode su... | Tracked on GitHub | |
Future release |
Task Description
Front- & Back-end code should be refactored for full Unicode support in scene files and strings.
|
|
227 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 RC3 | Very Low | High | Fixed Vector Limitations | Tracked on GitHub | |
|
Task Description
See this documentation entry for more details.
|
|
7 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Re-implement Radiosity render abort/continue support | Tracked on GitHub | |
|
Task Description
For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.
To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.
|
|
8 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Improve Radiosity "Cross-Talk" Rejection in Corners | Tracked on GitHub | |
Future release |
Task Description
Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.
It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.
|
|
70 | Photons | Unimp. Feature/TODO | 3.70 beta 34 | Low | High | load/save photons should be controlled via command line | Tracked on GitHub | |
|
Task Description
Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.
|
|
264 | Photons | Unimp. Feature/TODO | 3.70 RC6 | Defer | Low | Improve precision of photon direction information | Tracked on GitHub | |
|
Task Description
In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:
latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)
For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using
LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;
dirCode = LatBase[latCode] + lngCode;
For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.
|
|
58 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | allow SDL code to detect optional features | Tracked on GitHub | |
|
Task Description
Some features are optional in custom builds of POV-Ray (I’m thinking about OpenEXR in particular); it would be nice to have a syntax for an SDL script to check for support of such features, so it may take some fallback action if the feature is not supported.
|
|
172 | Image format | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Re-implement progressive image output | Tracked on GitHub | |
Future release |
Task Description
With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.
|
|
75 | Geometric Primitives | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Medium | Replace POV_MALLOC with std::vector in shape code | Tracked on GitHub | |
Future release |
Task Description
In the files bezier.cpp, fpmetric.cpp, fractal.cpp, hfield.cpp, isosurf.cpp, lathe.cpp, poly.cpp, polygon.cpp, prism.cpp, sor.cpp, and sphsweep.cpp the use of POV_MALLOC can be replaced by std::vector quite easily because the containing class already is a C++ class. As this is a low hanging fruit for continued code cleanup, it should be done sooner rather than later.
|
|
243 | Geometric Primitives | Unimp. Feature/TODO | All | Defer | Low | Sphere sweep behaves wrong when scaled | Tracked on GitHub | |
Future release |
Task Description
The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.
The effect is present for all three types of splines.
I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.
I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.
|
|
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.
|
|
205 | Documentation | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Low | Syntax documentation uses inconsistent notation | Tracked on GitHub | |
|
Task Description
The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.
|
|
106 | Distribution | Unimp. Feature/TODO | 3.70 beta 37 | Very Low | Low | Update sample scenes and include files for POV-Ray 3.7 ... | Tracked on GitHub | |
|
Task Description
Most sample scenes and include files were designed at times when POV-Ray did not to any proper gamma handling, or still used the inferior 3.6 “assumed_gamma” mechanism.
All the scenes and include files should be reviewed, and updated to fit the new 3.7 gamma model.
The primary task will probably be gamma-adjusting literal color values and ambient parameters; I suggest using macros (which ideally should be defined in an include file) to be set according to the #version statement, so the scene/include file could be kept compatible with older versions.
|
|
181 | Backend | Unimp. Feature/TODO | 3.70 beta 40 | Very Low | Medium | Unimplemented, altered or missing features to document ... | Tracked on GitHub | |
|
Task Description
This is a list of unimplemented features and things to fix with respect to 3.7 vs 3.6 compatibility. They either need to be fixed in code, or failing that, to be documented prior to release.
Create_INI works differently from 3.6. Prior versions of POV-Ray would write all options to the file, even if they were not supplied by the user (non-supplied options would take the default value). Currently in 3.7, only supplied options are written, because the front-end does not send unused options to the back-end. The proper fix for this would be to have a set of defines that establish the defaults all in one place (currently we rely on hard-coded values scattered around the code), and for the Output_INI_Option() function to look up and use the default when not supplied. As this is not likely to be done before 3.7 release, we need to document it as a temporary situation.
The following messages are marked as ‘currently not supported by code’ in povmsgid.h. We need to check where this comment is correct and if so the docs need to be updated to indicate this (for items that are already documented). Some items may be re-implemented later, and some may never be:
kPOVAttrib_TestAbort
kPOVAttrib_TestAbortCount
kPOVAttrib_VideoMode
kPOVAttrib_Palette
kPOVAttrib_DisplayGammaType
kPOVAttrib_FieldRender
kPOVAttrib_OddField
kPOVAttrib_AntialiasGammaType
kPOVAttrib_LightBuffer
kPOVAttrib_VistaBuffer
kPOVAttrib_DrawVistas
This bug should be edited to add/remove items as time goes by.
|
|
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?
|
|
311 | User interface | Possible Bug | 3.70 release | Very Low | Low | Elepsed time error on very long renders | Tracked on GitHub | |
3.71 release |
Task Description
On a very long render, around day 24, the elapsed time display becomes incorrect, showing 4294967272d 4294967272h 4294967272m 4294967272s.
Found on Windows 7 64 bits and reproduced on Windows 7 32 bits. NOT reported on other platforms.
|
|
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.
|
|
183 | Texture/Material/Finish | Possible Bug | 3.70 beta 40 | Very Low | Low | cutaway_textures broken with child unions | Tracked on GitHub | |
Future release |
Task Description
When using cutaway_textures in a CSG object that has union children, results are not as expected; instead, surfaces in the union children that have no explicit texture will be rendered with the default texture instead. This is not the case for e.g. difference children.
Example:
#default { texture { pigment { rgb 1 } } }
camera {
right x*image_width/image_height
location <0,1.5,-4>
look_at <0,1,0>
}
light_source { <500,500,-500> color rgb 1 }
#declare U = union {
sphere { <0,-0.1,-1>, 0.3 }
sphere { <0, 0.1,-1>, 0.3 pigment { color red 1 } }
}
intersection {
sphere { <0,0,0>, 1 pigment { color green 1 } }
object { U }
cutaway_textures
rotate y*90
}
When declaring U as an intersection instead, the results are as expected, with the surface of the first sphere in U being rendered with the texture defined in the outer intersection.
|
|
269 | Texture/Material/Finish | Possible Bug | 3.70 RC6 | Very Low | Low | Transparent Objects inside Media Cause Artefacts | Tracked on GitHub | |
|
Task Description
When placing a transparent object inside another object which contains media, artefacts may occur (see attached file). They look similar to specular highlights or are just strange white spots in the image.
I discovered artefacts of that kind first in the image of which MediaArtefactDetail.png is a cropped part. The code I managed to reproduce such artefacts with contained a “starfield” sphere
sphere {
<0,0,0>, 1
pigment { rgbt 1 }
interior {
media {
emission rgb 1/10
density {
crackle form <1,0,0>
density_map {
[0.0 rgb 1]
[0.05 rgb 0]
}
scale 0.002
}
}
}
scale 1000
hollow on
}
and a transparent sphere
sphere {
<0,0,0>, 1
pigment { rgbt 1 }
scale 2
hollow on
}
which is, obviously, completely inside the other sphere. So is the camera.
Since the sphere has a pigment { rgbt 1 }, it should be completely invisible, which is correctly rendered as long as the scaling factor is 1 and hollow off (MediaArtefact1.png). Changing hollow to on does not yet produce the artefact, but the right half of the output image seems to be shifted by one pixel (MediaArtefact2.png). Changing the scaling factor to 2 (as it is in the above code) produces the artefact (MediaArtefact3.png). Changing the camera location (MediaArtefact4.png) does not change anything, the artefact just “moves with the sphere”. Changing the sphere size again, however, seems to stir up the “stars” in the “starfield” sphere while not removing the artefacts (MediaArtefact5.png). Changing hollow to off again does neither (MediaArtefact6.png).
The artefacts are definitely no specular highlights. There is not even a light source in the scene that could produce any. I used POV-Ray 3.7 RC6 to render the images, but the artefact shown in MediaArtefactDetail.png already occured in POV-Ray 3.6 which I used to render that image.
|
|
286 | Texture/Material/Finish | Possible Bug | 3.70 RC7 | Very Low | Low | reflection exponent other than 1 causes black artifacts... | Tracked on GitHub | |
|
Task Description
[EDIT: Original title was “radiosity causing black patches when using emission less than 0”]
see attached image for reference.
mountain on left has emission set to -.13 and black patches show up, when emmission set to 0 or greater no patches
changing max_trace or any radiosity settings has no effect
setting no_radiosity on mountain fixed problem as a temp fix
code sample ...
#version 3.7;
#default { finish { ambient 0 } }
#declare rad_lvl = 4;
global_settings {
assumed_gamma 1
max_trace_level max(5,rad_lvl*3)
adc_bailout .007
ambient_light 0
radiosity {
pretrace_start 64/max(image_width,image_height)
#if(rad_lvl)
pretrace_end max(2,int(8/rad_lvl))/max(image_width,image_height)
#else
pretrace_end 32/max(image_width,image_height)
#end
count pow(rad_lvl+1,2)*10
nearest_count 1
#if(rad_lvl) error_bound 1/rad_lvl #end
low_error_factor max(.4,(8-rad_lvl)/10)
recursion_limit 1
gray_threshold .25
brightness 1
max_sample 1
normal on
media off
always_sample off
minimum_reuse min(.008,8/max(image_width,image_height))
maximum_reuse .1
adc_bailout .02
}
}
#declare sunC = rgb <1, 1, .9925>; // actual D65 standard illuminant
#declare SkyC = rgb <.3195, .5745, .8805>;
#macro GammaAdj(C,G) rgb <pow(C.red,G),pow(C.green,G),pow(C.blue,G)> #end
light_source {
50000*y
sunC*1.06
area_light <-300, 0, -300>, <300, 100, 300>, 3, 3
rotate <-28, 0, 14>
adaptive 0
circular
}
sphere { 0, 1
texture {
pigment{
gradient y
pigment_map{
[.07 GammaAdj(SkyC,.5)]
[.2 average pigment_map { [.5 GammaAdj(SkyC,.75)][1 wrinkles turbulence .65 octaves 5 lambda 3 omega .9 color_map { [.2 rgb 1][.5 SkyC] } scale <10, .1, 1>] }]
[.4 GammaAdj(SkyC,1.15)]
[.5 GammaAdj(SkyC,1.35)]
}
rotate -75*y scale <1, 1, 100>
}
finish { diffuse .72 }
}
scale 100000
inverse
}
#declare Cam_pos = Cam_pos + <0, 20, -40>;
#declare Cam_lkt = Cam_lkt + <0, 10, 50>;
camera {
location Cam_pos
direction <0,0,1>
right 1.33*x
up y
sky <0,1,0>
#if(Cam_agl) angle Cam_agl #end
look_at Cam_lkt
}
#macro sinai(HillQ)
#local F = function { pattern { granite poly_wave 4 turbulence .01 lambda 2.1 omega .9 scale 5 translate <.2, 0, 18.08> scale <2, 1, 3> } }
#local N = function { pigment { crackle ramp_wave turbulence .3 lambda 2.2 omega .76 color_map {[0 rgb 0][1 rgb 1] } scale .07 translate <-.15, -.12, .13> } }
height_field {
function HillQ, HillQ { F(x,y,z) + N(x,y,z).grey/47 }
water_level .05
clipped_by { box { <0, .05, .3>, <1, 1, 1> } }
translate <-.5, -.05, -.5>
rotate 20*y
texture {
pigment{ crackle color_map { [0 rgb <161, 107, 71>/255][.25 rgb <193, 132, 93>/255][.35 rgb <218, 163, 123>/255][.45 rgb <212, 153, 112>/255][.55 rgb <222, 166, 125>/255][.65 rgb <236, 178, 124>/255][.75 rgb <220, 154, 102>/255][.85 rgb <160, 121, 103>/255] } turbulence .75 lambda 3 omega .7 scale .1 }
finish{ diffuse albedo .56 emission -.13 specular .25 roughness .02 brilliance 1.5 metallic 1.3 }
normal { crackle poly_wave .7 turbulence .4 omega .8 scale <.007, .03, .007> }
}
rotate 12*y
scale <2400, 2000, 3000>*1.5
translate <1900, 0, 1900>
scale <-1,1,1>
no_radiosity
}
#end
sinai(1600)
plane { y,0 pigment { rgb <1, 1, 1> } }
//courtyard gating not included due to size of code and many external files needed. add anything around <0,0,0> to try to reproduce effect of error
|
|
50 | Runtime error | Possible Bug | 3.70 beta 32 | Very Low | Medium | Frequent segfaults with photon scenes | Tracked on GitHub | |
|
Task Description
I observe frequent segfaults with POV-Ray 3.7 betas when rendering scenes using photons:
Segfaults are sporadic but frequent (occurring in roughly 50% of all photon renders).
|
|
151 | Runtime error | Possible Bug | 3.70 beta 37a | Very Low | Low | No way to cancel save while parsing, never ending error... | Tracked on GitHub | |
|
Task Description
On Windows, when I try and save a file while it is being parsed prior to rendering, I get an error, “Failed to save file: The operation completed successfully”, with a single OK button to click. Despite the weird wording, I’m OK with that.
However after clicking OK I get the error, “Failed to save file ‘...’“, with three buttons: Cancel, Try Again, Continue. Not sure what “Continue” means in this context, given that the possibilities would seem to be covered by the other two buttons. Whatever.
Also, sometimes I get a message with only a single “Retry” button. Not sure what the exact message was.
Anyway, the real problem is that, regardless of which button I press, the program continues to spawning the same error message endlessly. Luckily there is a delay between them, but still it would be nice to have at least one of the three buttons *stop* POV-Ray from asking me again.
Also, once the program finishes parsing the file and it becomes possible once again to save the file, it does nothing. I.e. it doesn’t save the file. So what’s the point of the message and all the options? Why not just say, “Unable to save the file, file is parsing” and be done with it?
I think I recall the same behavior in 3.6.2, so it’s nothing new that’s been introduced.
|
|
47 | Preview | Possible Bug | 3.70 beta 32 | Very Low | Low | Render Preveiw window can become disabled | Tracked on GitHub | |
|
Task Description
If a render is continued with the +c option and the render had completed, the render preview window will disappear and the show/hide render window button will be grayed. Even after the scene is modified and the command line options have been changed, the show/hide button will still be grayed.
Opening or changing to another scene and rendering will not restore the button, nor will rendering with +d. However, if a trace is started using -d, halted, then continued using +d (or allowed to finish completely with -d and a new one is started using +d), then the preview window is restored.
This behavior is different from 3.6.1, which correctly always showed the preview window (since +d is default) unless -d was specified.
|
|
251 | Parser/SDL | Possible Bug | 3.70 RC6 | Very Low | Medium | Scene / include files of >2GB size may cause problems | Tracked on GitHub | |
3.71 release |
Task Description
Code inspection shows that we’re still using fseek() and ftell() in various places (including text file input), which can’t handle file positions of 2GB and beyond (except on 64-bit linux machines); those calls need to be examined and (where appropriate) replaced with the fseek64() macro we’re already defining (but currently not using), and a to-be-defined ftell64() macro.
One potential (untested) error scenario would be a scene file calling a macro that is defined at the end of a > 2GB long include file.
|
|
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.
|
|
206 | Other | Possible Bug | 3.70 RC3 | Very Low | Low | "Cannot open file" error when text output files specifi... | Tracked on GitHub | |
3.71 release |
Task Description
I created an INI file which specifies the Input_File_Name, Output_File_Name, and also the Render_File and the remaining four text outputs as double-quoted absolute paths on my disk. When I run the render, I get the following output:
Preset INI file is ‘C:\USERS\TPREAL\DOCUMENTS\POV-RAY\V3.7\INI\QUICKRES.INI’, section is ‘[512×384, No AA]’. Preset source file is ‘D:\Ruby\POV-Rb\ini\20110521_004037_Noix.ini’. Rendering with 2 threads. - Cannot open file. Render failed - CPU time used: kernel 0.06 seconds, user 0.02 seconds, total 0.08 seconds. Elapsed time 0.52 seconds.
And the render does not start. The five text output files are not even created, and where the output image should be, there is a file with extension pov-state. The render works as it should only when I remove all five lines defining the five text output files. The paths I specify for the files are correct (paths exist and files do not, no white-spaces or anything), read/write restrictions are disabled in POV-Ray. This used to work in 3.6 and does not work now in 3.7 RC3. The error happens no matter if I run the render using GUI or command line.
(Also please note that the error message is really not useful here, it does not say which file it failed to open, and not even if it was an attempt to open for read or for write.)
I’d be really glad if you could correct this as it’s a critical functionality for me. I’m generating the POV-Ray code automatically and I need to parse the text output automatically to return the status to the generator.
|
|
246 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | Regression on scale limit between 3.7 and previous rele... | Tracked on GitHub | |
|
Task Description
From Thomas de Groot
Using the following code for a (sky) sphere in a scene, with light source well outside the sphere; works correctly until the above scale value. Use a value of >=100*10e4 and the sphere becomes black.
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#declare T_sky =
texture {
pigment {
gradient y
pigment_map {
[0.0 srgb <1.0,0.7,0.6>*1 transmit 0.5]
[1.0 srgb <0.8,0.1,0.0>*1 transmit 0.5]
}
}
finish {
emission 0.9
diffuse 0.0
}
}
#declare T_cosmos =
texture {
pigment {
color rgbt <0,0,0,1>
}
finish {
ambient 0.0
diffuse 0.0
}
}
sphere {
<0,0,0>,1
texture {T_sky}
interior_texture {T_cosmos}
no_shadow
no_reflection
inverse
scale 99.9*10e4
}
Working with windows version of POV-Ray and Win7 x64
Is this normal for version 3.7 RC5? I seem to remember that with lower versions of POV-Ray on could go at least to 10e6. Especially with the Ringworld scenes back in 2010 the scales used where much larger without any black out.
I can indeed confirm that the Ringworld scene does not render correctly anymore, with identical black out.
|
|
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.
|
|
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 } }
}
|
|
226 | Geometric Primitives | Possible Bug | 3.70 RC3 | Very Low | Low | Near-coincident surface accuracy | Tracked on GitHub | |
|
Task Description
This is a transparent box very close to a plane.
box {
-1, 1
pigment { rgbf <0, 0, 1, 1> }
}
plane {
#if (version < 3.7)
y, -1.0000007
#else
y, -1.00007
#end
pigment { rgb 1 }
finish { ambient 1 }
}
camera {
location <1, 2, 3>
look_at 0
}
The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).
So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)
|
|
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.
|
|
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.
|
|
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.
|
|
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
|
|
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.
|
|
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
|
|
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) }
}
|
|
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.
|
|
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!
|
|
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
}
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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”.
|
|
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.
|