|
194 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | command line parse error | Closed | |
3.70 RC4 |
Task Description
povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.
|
|
201 | Parser/SDL | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Low | repeated re-declaring of functions causes runaway memor ... | Closed | |
3.70 RC4 |
Task Description
original posting from povray.beta-test:
I get this error message:
"Parse Error: bad allocation Render failed"
- after the code below has been running for about 3 seconds.
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
#version 3.7;
#while (true)
#local Fn = function { transform { translate <0, 0, 0> } }
#undef Fn
#end // while
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
I'm using POV-Ray for Windows - Version 3.7.0.RC3.msvc9-sse2.win32
The operating system is Windows XP.
With the code above, the error messages has so far appeared every time
right after 3318K tokens have been parsed. But with other versions of
my code, the error message does not always show up. (Sometimes the
render finishes and sometimes the parsing stops at different "times".)
[...]
Other users report no error message, but memory consumption rising to about 1.2 GB.
|
|
207 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Attempted to redefine float identifier as function ide ... | Closed | |
Future release |
Task Description
#macro A()
#local f = function { x }
#end
#local f = 1;
A()
This gives:
File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
function identifier.
The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.
For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:
#include "transforms.inc"
#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );
The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:
// Do NOT allow to redefine functions! [trf]
// #declare foo = function(x) { x }
// #declare foo = function(x) { foo(x) } // Error!
// Reason: Code like this would be unreadable but possible. Is it
// a recursive function or not? - It is not recursive because the
// foo in the second line refers to the first function, which is
// not logical. Further, recursion is not supported in POV-Ray 3.5
// anyway. However, allowing such code now would cause problems
// implementing recursive functions after POV-Ray 3.5!
In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.
|
|
215 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Double Error Reporting | Closed | |
3.70 RC4 |
Task Description
Certain types of errors are being reported twice. For example:
Parse Error: Expected ‘numeric expression’, } found instead Parse Error: Expected ‘object’, undeclared identifier ‘foo’
The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.
During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>
Verified on linux and windows platforms.
|
|
221 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Undefined looks_like object causes hard crash | Closed | |
3.70 RC4 |
Task Description
The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:
light_source {
<0, 0, 0>
color rgb 0.5*<1,0.905882,0.211765>
fade_distance 500
fade_power 1.6
looks_like {_3024_dot_dat texture {
pigment { rgbf <1,0.905882,0.211765,0.90> }
finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
reflection 0.9
refraction 1 ior 1.25
}
}
} }
|
|
232 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | illegal map_type usage reporting | Closed | |
3.70 release |
Task Description
parser fails to report when an illegal map_type is used. For example map_type 10 and map_type 100 doesn’t produce an error
|
|
233 | Parser/SDL | Possible Bug | 3.70 RC3 | Very Low | Low | Picture index out of range. - Fatal error in renderer: ... | Closed | |
3.70 RC7 |
Task Description
As posted in povray.beta-test 2012-01-14 with the same subject.
OS Win7 32 bit
The following code fails with the following message: Picture index out of range. Picture index out of range. Fatal error in renderer: Uncategorized error. Render failed
The texture scale is relevant.
It does not fail in Pov 3.62 The image map can be downloaded from: http://www.mmedia.is/~bjj/data/s_rings/sat_ring_color.png
(Attached)
#version 3.7;
global_settings { adc_bailout 0.0039 ambient_light rgb <1.000,1.000,1.000> assumed_gamma 1.00 irid_wavelength rgb <0.250,0.180,0.140> max_trace_level 5 number_of_waves 10 noise_generator 3 charset ascii }
background { colour rgb <0.000,0.000,0.000> }
#declare Ring_Texture1 = texture { uv_mapping pigment {
image_map{
png "sat_ring_color.png"
interpolate 2
map_type 0
}
rotate <90.000,90.000,0.000>
}
finish {
ambient rgb <0.100,0.100,0.100>
brilliance 1.000
crand 0.000
diffuse 0.600
metallic 0.000
phong 0.000
phong_size 40.000
specular 0.000
roughness 0.050
}
}
#declare Camera0 = camera { perspective location <3843.816,38.892,-2660.667> up y right 1.333*x angle 33.000 sky ←0.004,1.000,0.002> look_at < 0.449, 18.943, 0.102 > } end Camera0
disc { Disc0 0,y,4.400000,2.500000 texture{ Ring_Texture1 }
scale <750.000000,750.000000,750.000000> // Fails 32 bit
scale <800.000000,800.000000,800.000000> Fails 64 bit scale <600.000000,600.000000,600.000000> does not fail rotate <0.000000,0.000000,-20.000000> translate ←3500.000000,900.000000,900.000000> } end Disc0
camera{ Camera0 }
///
|
|
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!”
|
|
70 | Photons | Unimp. Feature/TODO | 3.70 beta 34 | Low | High | load/save photons should be controlled via command line | Tracked on GitHub | |
|
Task Description
Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.
|
|
78 | Photons | Possible Bug | 3.70 beta 35a | Very Low | High | Wrong rendering of BeamTest-Scene in 3.7.beta.35a | Closed | |
3.70 beta 37 |
Task Description
Hi,
following scene will not be rendered correctly in 3.7.beta.35a:
http://lib.povray.org/collection/beamtest/cousin%20ricky%201.1/beamtest.html
maybe it is a configuration problem or it is a real bug.
|
|
95 | Photons | Definite Bug | 3.70 beta 36 | Low | High | Photons are over-attenuated by semi-transparent surface ... | Closed | |
3.70 beta 37 |
Task Description
The code to attenuate transmitted photons according to surface texture was apparently duplicated during refactoring of the source code for version 3.7. Behavior has changed from 3.6 to 3.7 (beta.36) accordingly, as can be demonstrated with the following scene:
global_settings {
assumed_gamma 1.0
max_trace_level 10
photons { spacing 0.02 }
}
camera {
right x*image_width/image_height
location <0,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.5
fade_power 1001
fade_distance 0.9
fade_color <0.5,0.8,0.6>
}
}
#declare M_PseudoGlass2=
material {
texture {
pigment {rgbf <0.8,0.2,0.2,0.8>}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.0
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,0.3>
material { M_PseudoGlass2 }
photons { target 1.0 refraction on reflection on }
}
|
|
93 | Photons | Definite Bug | 3.70 beta 36 | Very Low | Medium | Photons are unnaturally amplified by pass_through objec ... | Closed | |
3.70 release |
Task Description
The following scene shows how photons are “boosted” by pass_through objects; removing one of the boxes will reduce the effect; the effect can be seen with 3.6 as well as current betas:
global_settings {
max_trace_level 10 // makes a difference!
photons { spacing 0.02 }
}
camera {
right x*image_width/image_height
location <0,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,500,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.05
specular 0.6
roughness 0.005
reflection { 0.1, 1.0 fresnel on }
conserve_energy
}
}
interior {
ior 1.5
fade_power 1001
fade_distance 0.9
fade_color <0.5,0.8,0.6>
}
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
cylinder {
<-1.2,0.01,0.8>, <-1.2,2.5,0.8>, 1
material { M_Glass }
photons { // photon block for an object
target 1.0
refraction on
reflection on
}
}
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_Glass }
photons { pass_through }
}
box {
<2.9,0,-2.3>, <3.1,4,-0.3>
material { M_Glass }
photons { pass_through }
}
|
|
165 | Photons | Definite Bug | 3.6 | Very Low | Low | photon problem: image of projected image_map is clipped ... | Closed | |
3.70 RC4 |
Task Description
Hi,
I have a problem with photons. The following stripped down code simulates a slide projector:
#include "colors.inc"
global_settings {
#if (1) // switch photons on/off
photons { count 1000000 }
#end
}
camera { location <0, 0, 200> sky<0,1,0> look_at <0,200,-200> angle 90 }
// projection screen
plane { z, -200 texture { pigment { White } finish{ diffuse 1 ambient 0.1} } }
// slide
polygon {
5, <0,0,0>, <1,0,0>,<1,1,0>,<0,1,0>,<0,0,0>
pigment { image_map {jpeg "s7_0.9_320.jpg" interpolate 2 filter all 1.0 } }
translate <-0.5, 0.2, -0.3>
photons { target refraction on reflection off collect off }
}
// projector lamp
light_source { <0, 0, 0> color <1,1,1> }
——————————————-
A point light source projects through a image_map onto a screen.
Without photons the projected image is ok: http://img838.imageshack.us/i/test4woph.png/
With photons the left and right bottom corners of the image will be clipped: http://img101.imageshack.us/i/test4wph.png/
The size of clipped corners depends on the y-offset in the translate command.
The povray Version is: Persistence of Vision™ Ray Tracer Version 3.6.1 (Debian (x86_64-linux-gnu-g+ + 4.3.3 @ x86_64-pc-linux-gnu)) (the 3.7 beta has the same problem)
I posted this question in the general news group and got an answer by Christian Froeschlin, who could reproduce the problem and suggested as workaround to divide the slide into small stripes
http://news.povray.org/povray.general/thread/%3Cweb.4c972bdffcc128eac947b6de0%40news.povray.org%3E/
This works, but doesn’t explain the problem.
Does anyone have an idea, whats wrong?
Many thanks, Corvin
|
|
190 | Photons | Feature Request | 3.70 RC1 | Very Low | Low | photon message reporting | Closed | |
|
Task Description
couple of observations:
if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)
when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.
|
|
241 | Photons | Definite Bug | 3.70 RC4 | Very Low | Low | Photons not working correctly | Closed | |
3.70 RC6 |
Task Description
~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.
|
|
252 | Photons | Definite Bug | 3.70 RC6 | Very Low | Low | photons and light_group is broken | Tracked on GitHub | |
|
Task Description
photons are not working when used with a light_group. verified in NG posting in p.general a simple scene file is attached.
|
|
264 | Photons | Unimp. Feature/TODO | 3.70 RC6 | Defer | Low | Improve precision of photon direction information | Tracked on GitHub | |
|
Task Description
In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:
latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)
For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using
LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;
dirCode = LatBase[latCode] + lngCode;
For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.
|
|
2 | Platform-specific | Compatibility Issue | 3.61c | Low | High | POV-Ray 3.6x does not work properly in Vista | Closed | |
3.62 |
Task Description
There are a number of problems with the Windows version of POV-Ray under Windows Vista. To resolve these, the setup program needs to be re-written and the location of internal files changed.
|
|
235 | Platform-specific | Definite Bug | 3.70 RC3 | Very Low | High | Segmentation fault with animation of large image | Closed | |
|
Task Description
Hopefully platform specific, other ports are welcome to check their scaling code.
Reported originally in p.beta-test (28 january 2012) by Cousin Ricky (email dropped)
Symptom: crash on start of second frame rendering Environment: Unix, with display of rendered picture, rendered picture does not fit at 1:1 on the display
Demo (adjust the H/W to your setting to get them larger, both or any of them):
global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }
povray +H2000 +W2000 +KI0 +KF1 +KFI0 +KFF10 code.pov
|
|
23 | Platform-specific | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | X Window preview might lock | Closed | |
3.70 release |
Task Description
Beta 32, compiled from source on Linux/Ubuntu, amd64.
The random “window display lock” is back. (as the previous “solution” was to get no window display usable, that’s not so bad).
What is it: sometime, when the rendering window is activated, povray just draw the frame of the window, paint it black, does not display anything else but seems to perform the rendering in separate threads. Whenever the mouse move over the frame of the window, it unlock the updating process and big parts of the rendered image pop up.
What it is not fine: if you do not move the mouse over the window, povray will just stall. This is more a problem for animation rendering, as getting the display might be a wanted bonus to monitor the rendering images, and you just fall into that lock: your expected night rendering could very well be suspended on the first frame. Moreover, the “move the mouse over” works only for local display. In previous beta (not yet checked with 32), with a remote display, there was no way to unlock povray.
|
|
40 | Platform-specific | Compatibility Issue | 3.70 beta 32 | Very Low | Medium | Compilation on freebsd | Closed | |
3.70 beta 33 |
Task Description
Reported for freebsd 7.2 (current production version, true for previous version, unknown for 8.0 in beta now)
freebsd does not provide CLOCK_PROCESS_CPUTIME_ID (even if CLOCK... is posix).
As a consequence, compilation of the unix-source is currently not possible for freebsd target.
Might be a simple selection for Change 4356 ? (assuming a relevant test in ./configure) (getrusage() seems available on freebsd, but does it provide the pieces of information needed, I do not know that code good enough to assert that)
|
|
72 | Platform-specific | Possible Bug | 3.70 beta 34 | Very Low | Low | Editor not saving preferences | Closed | |
|
Task Description
Windows 7, Home Premium 64bit In Options/Editor Window/Editor Preferences/Language Tabs saving a tab size of 4 does not work - on restart it reverts to the default of 8
In Options/Editor Window/Editor Preferences/Misc saving a Line numbering style of Decimal and a Start number of 1, does not work, on restart the defaults are restored.
|
|
135 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | Right-click menu when clicking on editor tab | Closed | |
3.70 beta 38 |
Task Description
When right-clicking on a tab in the editor window a list of options should appear, such as:
* Close * Close all but this * Save * Save as * Print
See Notepad++, EditPad Lite, and Firefox for examples.
|
|
139 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Delete" option in File menu | Closed | |
|
Task Description
Would be nice to have a “Delete” option in the File menu to delete the current file from disk.
|
|
140 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Reload" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.
|
|
330 | Platform-specific | Definite Bug | 3.70 release | Very Low | Low | Typo in QUICKRES.INI | Closed | |
|
Task Description
Height=36084
[640×360, AA 0.3] Width=640 Height=36084 Antialias=On Antialias_Threshold=0.3
should be:
[640×360, AA 0.3] Width=640 Height=360 Antialias=On Antialias_Threshold=0.3
|
|
317 | Preview | Definite Bug | 3.70 release | Very Low | High | problem with +D option at specific output file dimensio ... | Closed | |
|
Task Description
Reported in p.beta-test by James Dietrich (2013-12-12)
when the display window must be scaled (because one or both dimensions are larger than the actual screen), the ratio of scale might be too large in some occasion, performing a memory corruption in two places and usually crashing povray.
How to reproduce, with a 1920×1080 display (or 1920×1200):
povray +W2596 +H1003 +Ispiral.pov +Ospiral.png +D
|
|
47 | Preview | Possible Bug | 3.70 beta 32 | Very Low | Low | Render Preveiw window can become disabled | Tracked on GitHub | |
|
Task Description
If a render is continued with the +c option and the render had completed, the render preview window will disappear and the show/hide render window button will be grayed. Even after the scene is modified and the command line options have been changed, the show/hide button will still be grayed.
Opening or changing to another scene and rendering will not restore the button, nor will rendering with +d. However, if a trace is started using -d, halted, then continued using +d (or allowed to finish completely with -d and a new one is started using +d), then the preview window is restored.
This behavior is different from 3.6.1, which correctly always showed the preview window (since +d is default) unless -d was specified.
|
|
114 | Preview | Definite Bug | 3.70 beta 37a | Very Low | Low | Mosaic Preview not displaying properly | Closed | |
|
Task Description
Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.
I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.
|
|
313 | Radiosity | Definite Bug | 3.70 release | Low | High | radiosity.cpp pov::RadiosityFunction::BeforeTile assert... | Tracked on GitHub | |
|
Task Description
With 3.7.0 final, rendering attached files (for Computer Engineering college course), which renders without issues in povray 3.6.1, fails with following error:
...
==== [Rendering...] ========================================================
povray: backend/lighting/radiosity.cpp:324: virtual void pov::RadiosityFunction::BeforeTile(int, unsigned int): Assertion `(pts >= PRETRACE_FIRST) && (pts <= PRETRACE_MAX)' failed.
Command line:
povray +K0.6500 \
+FN +Q9 +MB1 \
+W600 +H400 \
+AM1 +A0.0 +R2 \
+D +SP32 +EP4 \
+L/usr/share/povray-3.7/include \
+Imain.pov \
+Omain-0.6500.png
Using Arch Linux testing current: Linux archmidi 3.12.0-1-ARCH #1 SMP PREEMPT Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux
Downstream bug report: https://bugs.archlinux.org/task/37689
|
|
7 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Re-implement Radiosity render abort/continue support | Tracked on GitHub | |
|
Task Description
For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.
To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.
|
|
8 | Radiosity | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | Improve Radiosity "Cross-Talk" Rejection in Corners | Tracked on GitHub | |
Future release |
Task Description
Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.
It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.
|