|
248 | Parser/SDL | Feature Request | Not applicable | Very Low | Low | Implement mechanism to compute direction of a spline | Tracked on GitHub | |
Future release |
Task Description
The SDL currently provides no way to compute the exact direction of a spline at a given location, even though mathematically this is a piece of cake: The first-order derivative of any spline section gives you the “speed” as a vector function, and is trivial to compute for polynomial splines (which are behind all spline types that POV-Ray supports); the normalized “speed” vector, in turn, gives the “pure” direction.
For exact direction/speed computations, I propose to extend the SDL invocation syntax as follows to allow for evaluating a spline’s derivative:
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, SPLINE_TYPE] [, FLOAT] )
or
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, FLOAT] [, SPLINE_TYPE] )
where the second FLOAT will specify the order of derivative to evaluate (defaulting to 0). In order to compute the position, direction, and acceleration of an object traveling along a certain spline, one could then for instance use:
#declare S = spline { ... }
#declare Pos = S(Time);
#declare VSpeed = S(Time,1);
#declare VAccel = S(Time,2);
#declare Dir = vnormalize(VSpeed);
#declare Speed = vlength(VSpeed);
#declare AccelDir = vnormalize(VAccel);
#declare GForce = vlength(VAccel) / 9.81;
Alternatively, a mechanism may be devised to create a spline representing another spline’s derivative; however, it would be debatable whether the syntax should be parameter-like (being an added information that could be overridden again when creating other splines from such a derived spline), or operation-like (converting the spline), and in the latter case how it should affect spline type (and consequently control points); so the spline invocation parameter approach might be more straightforward, with less potential surprises for the user.
|
|
249 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | UTF-8 files with BOM not accepted | Closed | |
3.70 RC7 |
Task Description
POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.
According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.
|
|
259 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | Stack Overflow with the write-directive with missing cl ... | Closed | |
|
Task Description
As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.
With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.
I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.
Best regards,
Michael
|
|
263 | Parser/SDL | Feature Request | 3.70 RC6 | Very Low | Low | Functions and patterns for finish variations | Tracked on GitHub | |
|
Task Description
the pigment {} and normals {} sections allow spatial variation of color, transparency and normal map. On the other hand, the specular parameter is a fixed scalar. This removes many possibilities. For instance, specularity could vary in space (speckles of oil or water on a surface, worn-out finish, having specularity reduce where the pigment transparency increases) and have color components. With current settings, the light’s color is simply multiplied by the scalar specified by “specular”, whereas multiplying each component with different color could create diverse effects (the “metallic” keyword already acts similar to duplicating the specular color from the pigment). The syntax could be exactly the same as for the pigment (all the patterns, color maps, image maps and functions would apply, allowing reuse of most of the code).
The effect can now be partially faked by having patterned textures, but it requires a very complex code and the lack of layering of patterned textures makes it difficult to vary the specularity and pigment separately.
In a similar way, roughness and brilliance could also vary in space.
Doing the same for varying reflectivity would be more difficult, as it has angular dependence and possibilty of Fresnel calculation, but it could at least be a full color instead of a simple scalar multiplier. For instance, having a blue surface that reflects only red component of the light should not be impossible.
I think at least part of this functionality actually makes the scene description language more uniform and self-consistent.
|
|
268 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | "naked" pigment statement does not properly override pr ... | Closed | |
|
Task Description
A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
pigment { checker color red 1 color blue 1 scale 1.0 }
}
the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
texture {
pigment { checker color red 1 color blue 1 scale 1.0 }
} }
which behaves as expected.
The issue has been around at least since POV-Ray 3.6.2.
|
|
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.
|
|
304 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | #for-loop may fail to perform last iteration | Closed | |
3.70 release |
Task Description
Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:
#declare N = 2000000;
#debug concat(”N = “,str(N, 0,50),”\n”)
#debug concat(”N-5 = “,str(N-5,0,50),”\n\n”)
#for (I, N-5, N, 1)
#debug concat("I = ",str(I,0,50),"\n")
#end
(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)
As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.
The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:
if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
((Step < 0) && (*CurrentPtr <= End - EPSILON)) )
which should instead be:
if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
((Step < 0) && (*CurrentPtr < End - EPSILON)) )
|
|
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.
|
|
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.
|
|
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.
|
|
336 | Parser/SDL | Definite Bug | 3.70 release | Very Low | Low | #fopen w/o OPEN_TYPE crash povray (segfault) | Closed | |
3.71 release |
Task Description
#fopen directive w/o OPEN_TYPE (yeah, I forgot it, some other languages have ‘read’ as default value)
expected behavior:
Parse error msg “line XXX, OPEN_TYPE missing in #fopen directive”, then stop.
observed behavior:
crash - Segfault err (core dump) in Parsing stage
minimal working example attached
|
|
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”.
|
|
84 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | A for-loop construct | Closed | |
3.70 beta 37 |
Task Description
Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.
The only remaining question would be the syntax.
IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:
#for(<identifier name>, <initial value>, <final value> [, <step>])
<loop body>
#end
Example:
#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
#debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
#debug concat(str(Counter, 0, 0), "\n")
#end
I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).
Of course this raises a couple of questions:
1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:
2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:
// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
#debug concat(str(Counter, 0, 0), "\n")
#if(Counter = 3) #local Counter = 8; #end
#end
Alternatively the counter variable could be read-only.
Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).
|
|
86 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Add support for more RNG types | Tracked on GitHub | |
Future release |
Task Description
The current 32-bit linear congruential generator used as RNG in POV-Ray is sometimes quite limited for some purposes and in a few cases its poor quality shows up (as has been demonstrated more than once in the newsgroup). Thus it would be nice if POV-Ray offered additional, higher-quality random number generators, besides the current one (which should probably remain for backwards compatibility). These RNGs could include algorithms like the Mersenne Twister and the ISAAC RNG, both of which have very decent quality and have an enormous periods (while at the same time being very fast).
After a long discussion, the following syntax for specifying the RNG type and seed (which may be larger than 32 bits) has been suggested:
seed(<value>) | seed(<type>, <value> [, <values>])
For example:
#declare Seed1 = seed(123); // Use the current RNG, with seed 123
#declare Seed2 = seed(1, 123); // Identical to the previous one
#declare Seed3 = seed(2, 456, 789, 123); // Use RNG algorithm #2,
// with a large seed (96 bits specified here)
A C++ implementation of the ISAAC RNG can be found at http://warp.povusers.org/IsaacRand.zip
|
|
90 | Parser/SDL | Definite Bug | 3.70 beta 36 | Very Low | Very Low | POV-Ray accepts additional patterns after "slope" | Closed | |
3.70 beta 37 |
Task Description
The following code is erroneously accepted by POV-Ray (tested with 3.7.0.beta.36):
pigment{
slope { x }
checker
}
The result is a checker pattern.
Apparently there is an EXIT statement missing in the slope-pattern parsing code in parstxtr.cpp.
|
|
124 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | variable number of parameters in macros | Closed | |
Future release |
Task Description
Many programming languages support an indeterminate number of parameters in functions/macros.
JavaScript for instance supports an “arguments” object.
Lua for instance supports the “args” object.
I would like to see that added to POV as well.
Here’s an JavaScript example:
function ArgTest(a, b){
var i, s = "The ArgTest function expected ";
var numargs = arguments.length; //Get number of arguments passed.
var expargs = ArgTest.length; //Get number of arguments expected.
if (expargs < 2)
s += expargs + " argument. ";
else
s += expargs + " arguments. ";
if (numargs < 2)
s += numargs + " was passed.";
else
s += numargs + " were passed.";
s += "\n\n"
for (i =0 ; i < numargs; i++){ //Get argument contents.
s += " Arg " + i + " = " + arguments[i] + "\n";
}
return(s); //Return list of arguments.
}
|
|
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
|
|
129 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | Hash arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
|
|
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!”
|
|
217 | Other | Possible Bug | 3.70 RC3 | Very Low | High | raddem.ini with +C and some frames already done: failur ... | Closed | |
|
Task Description
How to do it: (with raddem.ini & raddem.pov from distributed scenes, copied in local directory)
1. run “povray raddem.ini” until frame 6 or more (irrelevant, at least frame 1 & 2 are needed), interrupt the render.
2. restart “povray raddem.ini +C”
It fails at frame 2 with
Possible Parse Error: Cannot find file ‘raddem.pov’, even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed
The detection of frame 1 is fine.
|
|
220 | Other | Compatibility Issue | 3.6 | Very Low | High | Error number -43 | Closed | |
|
Task Description
REcently I installed POV-Ray tracing software in my mac OS X version 10.6.8. When I run the software its displaying a fatal error occured and the error number is -43. I’m new to POV-Ray...pls help me guys...
|
|
270 | Other | Definite Bug | 3.70 release | Medium | High | render abort-continue (+C) sometimes skips blocks | Closed | |
|
Task Description
When aborting a render when there are unfinished blocks among finished ones, under certain conditions some of those blocks are skipped when continuing the render later.
|
|
283 | Other | Definite Bug | 3.70 RC7 | Very Low | High | Transparent or semi-transparent background color comes ... | Closed | |
|
Task Description
When using the ‘background’ directive with a transparent color, for example:
background { color rgbt <0, 0, 0, 1> }
the final image is still opaque (both the one displayed in the render window and the PNG actually saved to disk).
Expected behaviour is for it to be transparent.
|
|
13 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | 4k files crash | Closed | |
3.70 beta 33 |
Task Description
Files of exactly 4k length can cause a full crash exception when opened.
|
|
32 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | tiff file extention error | Closed | |
|
Task Description
The parser is failing to read the .tiff file extension from the input string...
bump_map { tiff "earth03_hf2.tiff" }
Results in file not found, but
bump_map { tiff "earth03_hf2" }
will find the file. It might be that it’s not a three character extension?
|
|
42 | Other | Definite Bug | 3.70 beta 32 | Very Low | Medium | command line parameters are not parsed properly on Unix | Tracked on GitHub | |
|
Task Description
POV-Ray does not follow common practice on command-line handling; for instance:
povray +i"My File"
entered on a Unix shell would be passed to POV-Ray as
povray
+iMy File
(each line representing a distinct parameter here), which POV-Ray would further dissect, interpreting it as
povray
+iMy
File
To achieve the desired effect, one would actually have to quote the string twice:
povray +i"'My File'"
which the shell would translate to
povray
+i'My File'
which POV-Ray would interpret as
povray
+iMy File
In both cases, this is obviously not what a Unix user would expect.
The further dissecting of individual command-line parameters may have had its valid roots in the peculiarities of DOS’ command-line handling, but to my knowledge all major contemporary operating systems follow a concept akin to Unix, passing a list of parameters instead of a monolithic command line, and burdening the respective command shells with the task of dissecting command lines into parameters.
Therefore I suggest to disable this anachronistic feature in favor of contemporary standards; a compiler flag might be used to allow for easy re-enabling of the feature, for compiling POV-Ray on exotic targets.
- edit -
It has been pointed out that the described behaviour differs from 3.6, so I’m promoting this to a bug and changing the title.
|
|
61 | Other | Definite Bug | 3.70 beta 34 | Low | Medium | Dispersion does not give proper results | Closed | |
|
Task Description
Source code inspection during examination of issues with the scene published at http://povray.sitewww.ch/?p=177 show the following issues with current (beta.34) implementation of dispersion in POV-Ray 3.7:
While this still allows to use dispersion for artistic effect, it is neither physically realistic, nor does it match 3.6 behavior.
|
|
76 | Other | Feature Request | 3.6 | Very Low | Medium | Povray returns incorrect exit code when aborting render | Closed | |
3.70 release |
Task Description
If you abort a render with ^C, Povray exits with a ‘success’ error code.
To test:
povray scene.ini
(^C to abort it)
echo $?
Right now 0 is returned (’success’). A non-zero value should be returned (’failure’).
This is particularly important for scripting, where command lines like:
povray scene.ini && halt
...can be used. I only want the halt to be executed if the scene renders successfully. If I change my mind and ^C it, I don’t want the machine to shut down!
|
|
167 | Other | Definite Bug | 3.70 beta 38 | Very Low | Medium | Core dump when rendering to huge dimensions | Closed | |
|
Task Description
From post in povray.general (circa 29 september 2010: “Maximum Resolution of Renders?”)
The ultimate goal would be a 41000×41000 image. However each time I have attempted to render that Pov-Ray has crashed on
me. Even when using a single, simple test object (a plain white sphere that
should use a single pixel). So I think this is running into a program limitation
at present.
It won’t be for the faint hearted: a 30500 x 30500 does still produces the bug, but you’d better have 24 GB of true ram to test it.
(it’s a render of a few “real” minutes if you do not swap, for any very quick scene (a 305 x 305 in 0.117s moved to 220s for 30500×30500 on my system when corrected))
With core-dumped enable, the issue is pointed in the creator of PixelContainer.
The problem is due to the resize() parameter: despite the parameter being a size_t (8 bytes long on 64bits), the computation ( h * w * 5 ) use unsigned int for h & w (and signed int for 5).
As a consequence, the value of resize is computed as a signed int... havoc might happen when the signed bit (#31) is propagated to the #63 to #32 of size_t... vector does not enjoy a negative value for resize (and destroy itself: no iterator on coming soon call! hence the crash when the values in the vector are to be initialised)
30500²: (in hex)
1 15 3C 71 50 floats
4 54 F1 C5 40 bytes
Basic solution: promote the 5 to an unsigned long, forcing the computation to happen on unsigned long, avoiding promotion of silly sign-bit, and keeping the resize’s value as a good number.
aka: resize( w * h * 5) becomes resize ( w * h * 5ul )
This solution has been tested and seems fine (it’s just that in base/image/image.cpp, there is a lot of resize()!).
For all resize(), the “ul” must be added. (and that means also that resize( w * h ) must be rewritten as ( w * h * 1ul ). )
|
|
195 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Medium | povray-3.7.0rc3 incompatible with NetBSD | Closed | |
|
Task Description
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe)
2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable.
3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix).
4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3.
5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is
#ifdef HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html.
Backtrace is
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004ac479 in boost::gregorian::date::date ()
(gdb) bt
#0 0x00000000004ac479 in boost::gregorian::date::date ()
#1 0x00000000004d29f7 in boost::gregorian::date::date ()
#2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName ()
#6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName ()
#7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName ()
#8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= ()
#9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>)
at /archive/cvs/src/lib/libpthread/pthread.c:473
#11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
|
|
273 | Other | Definite Bug | 3.70 RC6 | Very Low | Medium | No automatic backup files from inc files | Tracked on GitHub | |
|
Task Description
If enabled, POVray always created backups of pov and inc files once per session.
Now using 3.7 RC6 only pov file backups are created but not from inc files.
|
|
277 | Other | Possible Bug | 3.70 RC7 | Very Low | Medium | Max Image Buffer Memory Does not Seem to Work | Closed | |
|
Task Description
In POV-Ray’s documentation it says:
3.2.2.2 Max Image Buffer Memory
This INI parameter sets the number of megabytes of RAM to allow for output image caching. If the output image happens to use more than this, a file backed temporary image is used instead.
I used this INI file option because the default value (128 megabytes) seemed insufficient. pov-state backend files were always created and they were remarkably larger than the resulting image (bmp) files. Consequently, I set
Max_Image_Buffer_Memory = 3096
in the INI file so that POV-Ray should, according to the documentation, now be able to use 3 gigabytes of RAM so no backend temporary file would be needed at all (this large they were never).
However, while POV-Ray was rendering I still discovered a pov-state file and it still had a similar size.
Now I am confused: did the INI option not work or have I misunderstood the documentation? If the former is the case, that would be a bug, wouldn’t it?
I tested both under Windows XP and Debian 6.0.5.
|
|
27 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | Add texture support to background statement | Tracked on GitHub | |
Future release |
Task Description
Adding full texture statement support to the background statement (with a scale of 1/1) aligned with the image_map direction of an image would allow i.e. specifying an image as background easily.
|
|
41 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | improve command-line parsing error messages | Tracked on GitHub | |
|
Task Description
POV-Ray 3.6, upon encountering problems when parsing command line and/or .ini file options, would quote the offending option in the error message.
POV-Ray 3.7 currently just reports that there is some problem with the command line, without providing any details. I suggest changing this, as the information may be helpful at times.
|
|
69 | Other | Compatibility Issue | Not applicable | Very Low | Low | #version fails to raise error | Closed | |
|
Task Description
Scenes starting with the incorrect syntax
version 3.7;
do not raise an error, instead they render a black screen with an empty scene warning.
#version should fail with an error when the # is missing.
|
|
82 | Other | Possible Bug | 3.70 beta 35a | Very Low | Low | correction to Shapes.pov | Closed | |
|
Task Description
When I try to re-render the insert menu bitmaps,on the Windows version 3.7b36 there is an error with the
Shapes.pov file.
line 474: Parse Error: Unexpected additional ‘.’ in floating-point number
line 474 is:
<2.6, 0>, <3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>
The second vector has two decimal points
Change to <3.6,.9>
|
|
85 | Other | Feature Request | Not applicable | Defer | Low | Aspect ratio issues | Tracked on GitHub | |
Future release |
Task Description
Background
When rendering an image, there are actually three aspect ratios involved:
1) The aspect ratio of the camera, set with the up and right vectors.
2) The aspect ratio of the rendered image, set with the +W and +H parameters.
3) The aspect ratio of the pixels in the intended target medium. While this is very often 1:1, it’s definitely not always so (anamorphic images are common in some media, such as DVDs).
The aspect ratio of the camera does not (and arguably should not, although some people might disagree) define the aspect ratio of the image resolution, but the aspect ratio of the image as shown on the final medium. In other words, it defines how the image should be displayed, not what the resolution of the image should be.
This of course means that the aspect ratio of the target medium pixels has to be taken into account when specifying the image resolution. If the target medium pixels are not 1:1 (eg. when rendering for a medium with non-square pixels, or when rendering an anamorphic image eg. for a DVD), the proper resolution has to be specified so that the aspect ratio of the displayed image remains the same as the one specified in the camera block.
This isn’t generally a problem. It usually goes like “my screen is physically 4:3, so I design my scene for that aspect ratio, but the resolution of my screen is mxn which is not 4:3, but that doesn’t matter; I just render with +Wm +Hn and I get a correct image for my screen”.
However, problems start when someone renders an image using an image aspect ratio / pixel aspect ratio combination which does not match the camera aspect ratio. By far the most common situation is rendering a scene with a 4:3 camera for a screen with square pixels but with a non-4:3 resolution (most typically 16:9 or 16:10 nowadays). The image will be horizontally
stretched.
In a few cases the effect is the reverse: The scene (and thus the camera) has been designed for some less-typical aspect ratio, eg. a cinematic 2.4:1 aspect ratio, but then someone renders the image with a 4:3 resolution. The resulting image will be horizontally squeezed.
In a few cases this is actually the correct and desired behavior, ie. when you are really rendering the image in an anamorphic format (eg. for a DVD). However, often it’s an inadverted mistake.
Some people argue that this default behavior should be changed. However, there are also good arguments why it should not be changed. Some argue that POV-Ray should have more features (at the SDL level, at the command-line level or both) to control this behavior.
There are several possible situations, which is why this issue is so complicated. These situations may include:
- The scene author doesn’t really care what aspect ratio is used to render the image, even if it means that additional parts of the scenery become visible or parts are cropped away when using a different aspect ratio than what he used.
In this case the choice of camera aspect ratio should be up to the person who renders the image, and thus selectable on the command-line. However, he should have an easy choice of how changing the aspect ratio affects the image: Should it extend the viewing range, or should it crop part of it, compared to the original?
And this, of course, while still making it possible to render for an anamorphic format.
- The author wants to support different aspect ratios, but he wants to control precisely how it affects the composition of the image. Maybe he never wants anything cropped away within certain limits, but instead the image should always be extended in whichever direction is necessary due to the aspect ratio. Or maybe he wants to allow cropping the image, but only up to a certain point. Or whatever.
In this case the choice of camera aspect ratio should be up to the author, and thus selectable in the scene file, while still allowing some changes from the command-line.
- The author designed his scene for a precise aspect ratio and nothing else, and doesn’t want the image to be rendered in any other aspect ratio. Maybe he used some very peculiar aspect ratio (eg. something like 1:2, ie. twice as tall as wide) for artistic composition reasons, and wants the image rendered with that aspect ratio, period.
Perhaps the author should be able to completely forbid the change of camera aspect ratio in the command-line.
Of course anamorphic rendering should still be supported for targets with a different pixel aspect ratio.
Possible solution
This solution does not necessarily address all the problems described above perfectly, but could be a good starting point for more ideas:
Add a way to specify in the camera block minimum and maximum limits for the horizontal and vertical viewing angles (and if any of them is unspecified, it’s unlimited). Of course for this to be useful in any way, there should also be a way to change the camera and pixel aspect ratios from the command line.
The idea with this is that the author of the scene can use these angle limits to define a rectangular “protected zone” at the center of the view, using the minimum angle limits. In other words, no matter how the camera aspect ratio is modified, the horizontal and/or vertical viewing angles will never get smaller than these minimum angles. This ensures that the image will never be cropped beyond a certain limit, only extended either horizontally or vertically to ensure that the “protected zone” always remains fully visible regardless of what aspect ratio is used.
The maximum angles can be used for the reverse: They ensure that no scenery beyond a certain point will ever become visible, no matter what aspect ratio is used. This can be used to make sure that unmodelled parts of the scene never come into view. Thus the image will always be cropped to ensure this, depending on the aspect ratio.
I’m not completely sure what should be done if both minimum and maximum angles are specified, and the user specifies an aspect ratio which would break these limits. An error message could be a possibility. At least it would be a way for the author to make sure his scene is never rendered using an aspect ratio he doesn’t want. He can use these angle limits to give some leeway how much the aspect ratio can change, to an extent, or he could even force a specific aspect ratio and nothing else (by specifying that both the minimum and maximum angles are the same).
So in short:
- Add a “minimum/maximum horizontal/vertical angles” feature to the camera block. These can be used to define a “protected zone” in the image which must not be breached by command-line options.
- Add a command-line syntax to change the camera aspect ratio (which automatically obeys the “protected zone” settings). Could perhaps give an error message if the command-line options break the limits in the scene camera.
- Add a command-line syntax to specify a pixel aspect ratio other than 1:1. This can be used to render anamorphic versions of the image on purpose (iow. not by mistake).
This can probably be made backwards-compatible in that if none of these new features are used, the behavior could be the same as currently (or at least similar).
|
|
97 | Other | Possible Bug | 3.70 beta 36 | Very Low | Low | Forward-slash pathnames not fully supported in Windows ... | Closed | |
3.70 beta 38 |
Task Description
The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.
|
|
131 | Other | Feature Request | 3.70 beta 37a | Very Low | Low | Ability to change the order of editor tabs by dragging ... | Tracked on GitHub | |
Future release |
Task Description
See Notepad++ or EditPad Lite for examples.
It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.
|
|
156 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Crash when reading from DF3 file with no data, using in ... | Closed | |
3.70 RC4 |
Task Description
A df3 file is written, with header 00 00 00 00 00 00 and no data (hypothetically valid df3 file).
This file is used as density file for media, using interpolation. This causes a crash once Pov-Ray starts rendering the pixels that contain media.
All pixels rendered before that render fine. Using no interpolation does not cause a crash.
Sample Scene:
#fopen out “random.df3” write
#write (out, uint16be <0,0,0>)
#fclose out
box{0,1 pigment{rgbt 1} hollow interior{media{
density{density_file df3 “random.df3” interpolate 1}}}} // interpolate 2 also crashes, interpolate 0 does not.
System: Win7 x64, 3.7 Beta 38
|
|
158 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Antialias Gamma reporting error | Closed | |
3.70 beta 39 |
Task Description
value is erroneously clipped to the range 0..1 before being displayed
|
|
164 | Other | Feature Request | 3.70 beta 38 | Very Low | Low | Date/time stamp on rendered images | Closed | |
|
Task Description
I’d like to request the ability to create a date/time stamp on output images so that new renders don’t always overwrite old ones. Thanks.
|
|
173 | Other | Feature Request | 3.70 beta 39 | Very Low | Low | Prevent POV-Ray for Windows from stealing focus | Closed | |
|
Task Description
In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.
I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.
|
|
176 | Other | Feature Request | Not applicable | Very Low | Low | Raise maxpower of the Poly Oject to 16. | Closed | |
|
Task Description
At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.
|
|
197 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | -J by itself does nothing | Closed | |
3.70 RC4 |
Task Description
The documentation says:
“-J Sets aa-jitter off”
However, it seems to have no effect. -J0 will turn off jittering.
|
|
204 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Low | -V is not Verbose=off on Unix | Closed | |
3.70 RC4 |
Task Description
In vfe/unix/unixoptions.cpp, -V is defined as a synonym for --version, overriding its general meaning of Verbose=off.
|
|
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.
|
|
214 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | Failed to parse command-line option in Debian | Closed | |
3.70 RC4 |
Task Description
I tried to use 3.7 RC3. This was my first time with 3.7.
I got source, configured and compiled it and installed into Debian with checkinstall. And then I tried to use it. First run was with -benchmark (it took about 9 minutes, ok). Then I tried very simple scene:
rekcahx@oah:~/pov$ povray +Iaa.pov
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
Failed to parse command-line option
I tried to debug with strace:
rekcahx@oah:~/pov$ strace -o debug.strace povray +Iaa.pov
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (g++ 4.6.1 @
x86_64-unknown-linux-gnu)
This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.
POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins
Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Primary POV-Ray 3.7 Architects/Developers: (Alphabetically)
Chris Cason Thorsten Froehlich Christoph Lipka
With Assistance From: (Alphabetically)
Nicolas Calimet James Holsenback Christoph Hormann Nathan Kopp
Juha Nieminen
Past Contributors: (Alphabetically)
Steve Anger Eric Barish Dieter Bayer David K. Buck
Nicolas Calimet Chris Cason Aaron A. Collins Chris Dailey
Steve Demlow Andreas Dilger Alexander Enzmann Dan Farmer
Thorsten Froehlich Mark Gordon James Holsenback Christoph Hormann
Mike Hough Chris Huff Kari Kivisalo Nathan Kopp
Lutz Kretzschmar Christoph Lipka Jochen Lippert Pascal Massimino
Jim McElhiney Douglas Muir Juha Nieminen Ron Parker
Bill Pulver Eduard Schwan Wlodzimierz Skiba Robert Skinner
Yvo Smellenbergh Zsolt Szalavari Scott Taylor Massimo Valentini
Timothy Wegner Drew Wells Chris Young
Other contributors are listed in the documentation.
Support libraries used by POV-Ray:
ZLib 1.2.3.4, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.44, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 62, Copyright 1998 Thomas G. Lane
LibTIFF 3.9.5, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.46, http://www.boost.org/
OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.
Parser Options
Input file: aa.pov
Remove bounds........On
Split unions.........Off
Library paths:
/usr/share/povray
/usr/share/povray/ini
/usr/share/povray/include
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....320 by 240 (rows 1 to 240, columns 1 to 320).
Output file..........aa.png, 24 bpp PNG
Dithering............Off
Graphic display......Off
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
[Parsing...]
Parse Warning: This scene did not contain a #version directive. Please be aware
that as of POV-Ray 3.7, unless already specified via an INI option, a #version
is expected as the first declaration in a scene file. POV-Ray may apply
settings to some features that are intended to maintain compatibility with
pre-3.7 scenes. You are strongly encouraged to add a #version statement to the
scene to make your intent clear. Future versions of POV-Ray may make the
presence of a #version statement mandatory.
Parser Statistics
Finite Objects: 1
Infinite Objects: 0
Light Sources: 1
Total: 2
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
—————————————————————————-
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........Off
[Rendering...]
Rendered 76800 of 76800 pixels (100%)
Render Statistics
Image Resolution 320 x 240
Pixels: 76800 Samples: 0 Smpls/Pxl: 0.00
Rays: 76800 Saved: 0 Max Level: 1/5
Ray→Shape Intersection Tests Succeeded Percentage
Box 78226 1426 1.82
Shadow Ray Tests: 1426 Succeeded: 0
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 0 seconds (0.016 seconds)
using 4 thread(s) with 0.036 CPU-seconds total
POV-Ray finished
—
Every now and then all other command line options than –version, -version, -V, –help, -help -h, -?, –benchmark and –benchmark without leading strace in command line produces “Faild to parse command-line option” error.
My system: ebian GNU/Linux unstable (sid), quadcore AMD Phenom 2.6 GHz, 8GB ram.
Povray:
rekcahx@oah:~/pov$ povray –version
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
POV-Ray 3.7.0.RC3
This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Built-in features:
I/O restrictions: disabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.6.1
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
245 | Other | Feature Request | All | Defer | Low | POVMS message queue can fill up with GB of data for ver... | Tracked on GitHub | |
Future release |
Task Description
With very fast renders and very large output files, the message queue can fill up because the producers are not limited by IO, while the consumer performance is limited by disk IO. Consequently, the message queue can fill up to exhaust all available memory. The solution is to build in some better control of pending output data in the message queue on the producer side. This will also pave the way for message communication over slow links (i.e. a network).
|
|
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.
|
