|
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.
|
|
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 { }
}
|
|
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)
|
|
272 | Other | Feature Request | 3.70 RC6 | Defer | Very Low | Minor change, significant speedup in cubic polynomial s... | Tracked on GitHub | |
3.71 release |
Task Description
While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.
In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).
solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.
I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).
These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].
This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.
The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).
|
|
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.
|
|
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.
|
|
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.
|