|
247 | Other | Feature Request | 3.70 RC6 | Very Low | Low | Set no_radiosity in Screen_Object() | Closed | |
Future release |
Task Description
Suggestion:
In file screen.inc, have macro Screen_Object() set no_radiosity on the object.
|
|
250 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | ini shell-outs always fail | Closed | |
|
Task Description
I’ve got an ini file that looks like this:
Post_Frame_Return=U Post_Frame_Command=notepad.exe
And when I render a scene using that ini file, it renders correctly but then gives me this error:
Render halted because the post-frame shell-out (’notepad.exe’) requested POV-Ray to generate a user abort. Render failed
.....and it doesn’t open notepad.
I’ve unchecked the “Disable Starting Other Programs” and I’ve tried various variations on what exe to run and whether to do it Pre/Post Frame/Scene, and nothing has worked.
|
|
257 | Other | Definite Bug | 3.70 RC6 | Very Low | Low | POV-Ray cannot find input file when resuming to render ... | Closed | |
3.70 RC7 |
Task Description
How to reproduce:
# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png
What happens:
==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed
OS: Gentoo AMD64 unstable POV-Ray version: 3.7.0 rc5
|
|
265 | Other | Possible Bug | 3.70 RC6 | Very Low | Low | Warnings from clang that might need consideration | Closed | |
|
Task Description
Compiling the sources with clang instead of g++ (on ubuntu 12.10 with boost 1.50)
./configure COMPILED_BY=”your name here <also@email>” LIBS=-lboost_system –disable-io-restrictions CC=clang CXX=clang
there is a few warnings that catch the eyes (and other as well that I dismiss so far, such as cases not covered in switch and empty body in if, or extraneous parentheses in tests):
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
support/randomsequences.cpp:974:40: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<int>::PrecomputedNumberGenerator' requested here
SeedableIntGeneratorPtr generator(new PrecomputedIntGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:984:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<double>::PrecomputedNumberGenerator' requested here
SeedableDoubleGeneratorPtr generator(new PrecomputedDoubleGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:1011:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector3d>::PrecomputedNumberGenerator' requested here
return SequentialVectorGeneratorPtr(new PrecomputedVectorGenerator(factory, count));
^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
startIndex(startIndex)
^
support/randomsequences.cpp:1056:45: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector2d>::PrecomputedNumberGenerator' requested here
return SequentialVector2dGeneratorPtr(new PrecomputedVector2dGenerator(factory, count));
Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).
povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete nodeptr->handleroo;
^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete nodeptr->handler;
^
Maybe just a missing keyword (virtual) in the header file ? Or is it harder ?
shelloutprocessing.cpp:260:28: warning: expression result unused [-Wunused-value]
for (s = str.c_str(); *s; *s++)
^~~~
Why “*s++” ? why not just “s++” ?
renderfrontend.cpp:1165:57: warning: trigraph ignored [-Wtrigraphs]
default: t = "(???)"; break;
I guess it’s not an intended trigraph. Might nevertheless perturb some compiler/result.
|
|
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.
|
|
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.
|
|
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?
|
|
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.
|
|
109 | Other | Compatibility Issue | 3.70 beta 37a | Defer | Very Low | Debug_File No Longer Appends Frame by Frame Debug Data | Closed | |
Future release |
Task Description
The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a. In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.
In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.
This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.
Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.
Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.
|
|
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.
|
|
185 | Other | Definite Bug | 3.70 beta 41 | Very Low | Very Low | wrong message about image resolution | Closed | |
3.70 RC2 |
Task Description
‘povray -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays
Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)
instead of
Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)
or
Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10)
|
|
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.
|
|
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).
|
|
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.
|
|
51 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Critical | POV-Ray crashes hard on missing parenthesis | Closed | |
3.70 beta 35 |
Task Description
The following (bogus) SDL code causes POV-Ray 3.7 beta to crash hard with an access violation:
#include "fubar.inc"
Bar(42)
#macro FooBar() #end
//fubar.inc
#macro Foo(Fnord) #end
#macro Bar(Ignord) Foo(23 #end
|
|
130 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | High | Master scene unit system variable | Closed | |
|
Task Description
Currently, many POV scenes/include files behave differently depending on the basic units used within the scene. Scaling them differently can affect things like ior and media. A master system variable that users can set to configure the scene’s units would be beneficial for sharing and collaboration purposes, so that person A’s glass interior works correctly in person B’s wine glass scene. Just like the #version system variable, it should have a default value but should be possible to explicitly override.
|
|
208 | Parser/SDL | Definite Bug | 3.70 RC3 | Low | High | Use-after-free when returning local function or spline ... | Closed | |
3.70 RC4 |
Task Description
#macro A()
#local foo = function { x }
foo
#end
#local bar = A();
This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.
After some debugging I think this is what happens.
In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.
So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:
Temp_Data = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);
if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.
A similar problem occurs when foo is a spline.
A tentative patch for the function case is attached.
|
|
238 | Parser/SDL | Possible Bug | 3.70 RC4 | Very Low | High | Error during #read causes file to be kept open | Closed | |
3.70 RC7 |
Task Description
Consider the following script:
#fopen F "foo.txt" read
#read (F, Foo)
#debug concat ("'", Foo, "'\n")
#fclose F
Now assume that foo.txt erroneously contains unquoted text (which will result in a parse error):
Blah
When the error is reported, POV-Ray for Windows will helpfully open foo.txt, but any attempt to save a corrected version of foo.txt will fail until you exit the POV-Ray GUI, presumably because foo.txt is not properly closed by the parser.
|
|
10 | Parser/SDL | Feature Request | 3.70 beta 32 | Very Low | Medium | Add support for specifying input images' gamma pre-corr ... | Closed | |
3.70 beta 40 |
Task Description
Input image files may have been created with gamma pre-correction for some specific target gamma, which may vary from image to image. Some file formats like PNG or HDR support embedding gamma pre-correction information in the image file, but this information may be missing or faulty, and some formats don’t support it at all. Additionally, it may be desirable to tamper with an input image’s gamma for artistic reasons.
Therefore, I suggest adding a means to explicitly specify input images’ originally intended target gamma on a per-image basis, like:
image_map { jpeg "MyImage.jpg" assumed_gamma 1.8 }
|
|
22 | Parser/SDL | Definite Bug | 3.6 | Very Low | Medium | Known 3.6-only bug related to Splines and Token countin ... | Closed | |
3.65 |
Task Description
3.6x only bug with easy/known fix. Error message: “Identifier expected, incomplete function call or spline call found instead.” caused by token counter variable using the wrong special value. The symptom occurs when using a lot of splines. See this thread for details.
(I am using a self-compiled special build because I use a lot of splines in 3.6 but would rather use an official 3.6)
|
|
73 | Parser/SDL | Definite Bug | 3.70 beta 34 | Very Low | Medium | Blend map cannot get 256 entries | Closed | |
3.70 beta 35 |
Task Description
Reported by cshake + pov @ gmail . com in p.beta-test, 14th december 2009
I wrote a simple script to convert fractint color maps to povray color_maps so I could use ApoMap to make nice fractal colors for pov, but I ran into “Parse Error: Blend_Map too long.” The map has entries from 0/255 up to 255/255 (inclusive). I looked up the documentation which says that color_maps can have from 2 to 256 entries, and this is exactly 256 entries. I’m posting this in beta-test because I assume that the documentation is correct for v3.6, and that a previous version can handle 256 entries.
|
|
80 | Parser/SDL | Possible Bug | 3.70 beta 35a | Very Low | Medium | Bad behavior for missing image file | Closed | |
|
Task Description
The following SDL code
sphere {0, 1 pigment {image_map {png "missing.png"}}
yields “render failed” in 3.7b25 and the position of the error is not highlighted in source code, giving no clue what went wrong. In 3.6 this yields “Parse Error: Cannot open PNG file”.
|
|
163 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 38 | Very Low | Medium | no pigment warning | Closed | |
Future release |
Task Description
no warning is issued when an object/primitive has no pigment type given
|
|
198 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing closing brace in function definition causes mem ... | Closed | |
3.70 RC4 |
Task Description
Given the following two statements, a missing closing brace in the function declaration fn should throw a parse exception; instead it causes a memory access violation when trying to use fn in the second delcaration:
#local fn = function {
pigment { image_map { png "MultiPassBlobs3.png" gamma 1 map_type 0 once }}
#local clr = fn(0,0,0);
|
|
213 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Medium | Missing check for ios failbit/badbit: endless loop whil ... | Closed | |
3.70 RC4 |
Task Description
Hello,
this bug report relates to this thread: http://news.povray.org/povray.beta-test/thread/%3Cweb.4e0064d9a3970d212b256d410%40news.povray.org%3E/
In /unix/unixoptions.cpp around line 817:
while ( !Stream.eof() )
{
// get and preprocess line
std::getline(Stream, line);
line = pre_process_conf_line(line);
++line_number;
// skip empty line
if(line.length() == 0)
continue;
[...]
}
`Stream.eof()` could never be true as well as `line.length()` always can be zero, leading to an endless loop. In my case, the problem occurred due to my ~/.povray/3.7/povray.conf being a directory instead of a file.
To fix the problem, one has to consolidate this loop by not only checking for eofbit, but also for failbit and badbit of `Stream`. The getline() method on a directory does not set the eofbit, but it sets fail and bad (test: http://codepad.org/RiZGo3ia). According to http://www.cplusplus.com/reference/iostream/ios/operatornot/ fail and bad can be checked for by `!Stream`. A simple `if (!Stream) break;` within the loop fixes the problem (patch file attached).
Are there more missing checks on iostreams like this in the code? :) They should definitely be fixed.
Furthermore, one could think about using the boost filesystem library to be able to distinguish files and directories to provide good error messages.
Hope that helps,
Jan-Philip Gehrcke
|
|
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.
|
|
276 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Medium | SDL Access to Spline Derivatives | Closed | |
|
Task Description
I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.
In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.
I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)
Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).
|
|
9 | Parser/SDL | Feature Request | 3.70 beta 32 | Very Low | Low | Add support for tuning brightness of image-mapped sky s ... | Closed | |
3.70 RC4 |
Task Description
Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.
To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.
|
|
33 | Parser/SDL | Definite Bug | 3.70 beta 32 | Very Low | Low | parse accepting invalid vector float components | Closed | |
3.70 beta 33 |
Task Description
The parser is missing extra period characters when it parses a float as a vector component.
#local sample = <0.0.0.1,0,0>;
Doesn’t generate an error, but should.
|
|
52 | Parser/SDL | Possible Bug | 3.70 beta 32 | Very Low | Low | inside() function does not accept meshes despite valid ... | Closed | |
|
Task Description
The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.
(see news://news.povray.org:119/4a983716@news.povray.org)
|
|
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.
|
|
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.
|
|
102 | Parser/SDL | Definite Bug | 3.6 | Very Low | Low | #switch directive parsing problem | Closed | |
|
Task Description
The #switch directive isn’t parsing correctly. In the following construct NO warning or error is generated:
#switch (RF)
case (0)
rotate z*355
#break
case (144)
rotate z*7.5
#break
case (216)
rotate z*5
#break
#end
RF is a variable passed to the macro in which this construct resides. The first ‘case’ action IS executed, but none of the others are on successive calls to the macro. If I properly add ‘#’ to the second case the 1st and 2nd condition are executed but not the last. If ‘#’ is REMOVED from any of the break directives an error is generated and parsing halts.
|
|
107 | Parser/SDL | Definite Bug | 3.70 beta 37 | Very Low | Low | Failed to parse INI file, over network | Closed | |
3.70 beta 38 |
Task Description
I can no longer run a Myfile.ini over a network, on a different computer.
Possiblely related to:
http://bugs.povray.org/task/97 FS#97 (Forward-slash pathnames not fully supported in Windows version)
- Cannot open INI file ‘\\STEPHEN-POVRAY\Bishop3d\Objects\Industrial_enclosure\Telco_enclosure_extra.ini’. Failed to start render: Failed to parse INI file
|
|
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
|
|
111 | Parser/SDL | Definite Bug | 3.70 beta 37a | Very Low | Low | Remove_Bounds=off / -UR does not work properly | Closed | |
3.70 beta 38 |
Task Description
Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.
|
|
121 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Option to render pixels randomly, or in Nth pixel | Closed | |
|
Task Description
Assuming there are no performance issues, it would be nice to tell Povray to select the pixels to render randomly, so that the image gets filled in gradually instead of from top to bottom and from left to right.
Also, maybe an option to tell it to render every Nth pixel.
|
|
122 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #ELSEIF statement | Closed | |
3.70 beta 38 |
Task Description
Request an #ELSEIF statement in POV SDL.
|
|
123 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #BREAK statement inside #WHILE and #FOR loops | Closed | |
|
Task Description
Request #BREAK statement inside #WHILE and #FOR loops.
|
|
126 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Explicit #RETURN statement inside macros | Closed | |
|
Task Description
In POV SDL it can sometimes be ambiguous what exactly a macro returns. An explicit #RETURNS statement would make this unambiguous.
|
|
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.
|
|
128 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Mixed-type arrays | Closed | |
|
Task Description
Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.
|
|
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.
|
|
146 | Parser/SDL | Possible Bug | 3.70 beta 37a | Very Low | Low | Macros are finnicky about how you type your code | Closed | |
|
Task Description
Macros are finicky about how you type your code. What works outside macros sometimes fails inside them. For more information see the threads:
“Problems with macro (3.6)”, in p.a-u, 06-09-10 “Bad operands”, in p.g, 05-20-10
Still not sure *what* exactly the problem was, but one of my workarounds ended up working.
|
|
152 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Camera in object, union statements | Closed | |
|
Task Description
Currently, cameras placed inside object or union statements will halt the render with an error. Take for instance the following case:
#local temp_camera_1 = camera
{
orthographic
location z*-12
direction z
up y
right x*image_width/image_height
scale 32
}
#local temp_light_1 = light_source
{
0
color rgb 1
translate <-30, 30, -30>
}
#local temp_light_2 = light_source
{
0
color rgb 1
translate <-30, 30, +30>
}
union
{
object {temp_light_1}
object {temp_light_2}
// camera {temp_camera_1} // doesn't work!!!
}
//object {temp_camera_1} // doesn't work!!!
camera {temp_camera_1} // works!!!
Changing this behavior would make it possible to more easily apply transformations to scene objects and the camera at the same time in situations where the scene’s frame of reference is in motion relative to the rest of the scene, for instance in animations.
|
|
169 | Parser/SDL | Possible Bug | 3.6 | Very Low | Low | Error in Linux version using #while loop and SweepSplin ... | Closed | |
3.70 RC4 |
Task Description
I used POV-Ray to make an animation of my Morgan driving around a slalom course. (If you are curious, you can see the output on youtube under my user name, nojonushi.) To make the long swooping fenders I used Mike William’s SweepSpline macro.
The code rendered the 1189 frames in one go with no problems. But the wheels in that animation do not rotate, so I then added code to rotate the wheels. In the calculations I added I used a #while loop to step through the spline containing the route coordinates and total up the distance traveled. Running POV-Ray on this file produced a random number of images and then issued an error, e.g.
0:00:00 Processing Frame 456 of 1189
0:00:00 Parsing
File: mogslalom.pov Line: 1918 Parse Warning: Patch objects not allowed in intersection. File: mogslalom.pov Line: 2988 File Context (5 lines):
object {
SweepSpline(TFSpline,
Parse Error: Identifier expected, incomplete function call or spline call found instead.
Most of the parameters for the macro are missing. But this is after successfully generating, in this case, 455 images.
I have attached a text file with set-up and sample code that has given the error on two different machines.
|
|
189 | Parser/SDL | Possible Bug | 3.70 RC1 | Very Low | Low | segmentation fault | Closed | |
|
Task Description
I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.
FYI: I did a build off the depot last evening.(21:13)
|