All Projects

IDProjectCategoryTask TypeReported InPrioritySeveritySummaryStatusProgressDue Date
 317 POV-RayPreviewDefinite Bug3.70 releaseVery LowHigh 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

 314 POV-RayComments/TyposDefinite Bug3.70 releaseVery LowHigh reading Gif is bugged in 3.7 Closed
Task Description

In gif.cpp (source/base/image), circa line 150:

			case ',': /* Start of image object. Get description. */
				for (int i = 0; i < 9; i++)
					if ((data = file->Read_Byte()) == EOF)
						throw POV_EXCEPTION(kFileDataErr, "Unexpected EOF reading GIF file");
					buffer[i] = (unsigned char) data;

				/* Check "interlaced" bit. */
				if ((buffer[9] & 0x40) != 0)
					throw POV_EXCEPTION(kFileDataErr, "Interlacing in GIF image unsupported");

The loop reads the 9 bytes of the Image Block, but is testing the tenth byte for interlacing.

Reference for image format:

When the gif is generated by Gimp, the Image block is preceded by the comment block which default to “Created with GIMP”... the comment is read in the buffer, and the “i” will be in buffer[9], any letter after @ will indeed block povray.

This bug was not present in 3.1g nor in 3.6.1 (due to different source to handle gif).

If not created by Gimp, or with shorter comment, the content of buffer[9] is more random, yet it might trigger the bug depending on the previous blocks and their handling.

 308 POV-RayGeometric PrimitivesDefinite Bug3.70 RC7Very LowMedium Heightfield computation from color (not palette) red/gr ...Closed
Task Description

Due to a recent thread in povray.general (7th September 2013), I dive
into the code of height field creation.

There is 2 TODO FIXME in source/backend/support/imageutil.cpp, for
image_height_at() (circa line 512)

The first one is about using the index of palette-image: As far as *257
would indeed perform a better job to cover the full range than *256, it
would break backward compatibility with previous versions of povray (3.6
included) which only promoted the index as the Most significant byte,
keeping the least one at 0.

But on the second one, the new formula is plain wrong: (r*255+g)*255
should be (r*256+g)*255.
In previous versions, r*255 was the Most significant byte, and g*255 was
the least one.
Ergo, the value was r*255*256 + g*255, which can and should be only
factored as (r*256+g)*255;

I know it is damn late in the release schedule, but can that be either
be fixed before final official delivery or a memo added to the release
note that it would be fixed later and backward-bug will not be
maintained for that specific point (using rgb-8 or less bit per
channel-image for height field)

(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit
of 3.7 that would should that bug)

If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top.
With 3.6, it matched exactly (hence the noise on the top pixels row) the view.
With 3.7, it cannot reach the top and leave a white area
(another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)

If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov

The white line at the bottom is expected, as the minimal value of the height field is “full green”

 298 POV-RayGeometric PrimitivesDefinite Bug3.70 RC7Very LowLow the warning for isosurface does not appears as often as ...Closed
Task Description

From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)

William F Pokorny wrote:
> It seems to be the case the gradient warnings are only generated if the
> isosurface is naked. If it is wrapped in an object as was the case with
> my thread safety example, we get no warnings.

Confirmed. If only I still had the concentration required to investigate
computer code.

#version 3.7;

#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end

{ assumed_gamma 1
  radiosity {} //force isosurface calculations from all directions

light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }

{ location <0.0000, 1.0000, -5.6713>
  look_at <-0.7969, 1.2000, -0.0598>
  angle 10.7447

#include ""

#if (Naked)
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  #declare Test = isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  object { Test }

On the command line, try:

declare=MG=1 declare=Naked=1


declare=MG=1 declare=Naked=0

To lose the warning, I had to declare the isosurface. Just wrapping the naked
isosurface in an object{} generated a warning.

Further analysis

isCopy seems to be intended to avoid displaying the same warning over
and over for the same isosurface (as duplicated isosurface indeed are
not copied but reference the same sub-structure).

#declare Ob = isosurface{...}; that’s not a copy
object {Ob ... }
that’s a copy

Previously (3.6.1) the warning was displayed at the destruction of the
isosurface (when the sub-structure was actually referenced by no one else)

if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))

In 3.7, isCopy was introduced with change 4707, 16th February 2009,
along with the change introducing means for objects to submit message on
It was reported in windows source with change 4714, 21th February 2009.

If the symptom “isosurface embbeded in object (CSG) does not show the
warning” is correct, it might be a “feature/bug”. The parser copied the
isosurface object and deleted the original before the render started.
When the render ends, it find only copies and because the refcnt is not
used anymore (for that purpose), it miss the last remaining true data to

Instead of isCopy, what about adding in mginfo a boolean
“printed_warning” (actual name should be more appropriate), set to false
on creation, and turn to true on the first call (instead of last for
3.6.1) of the warning displaying function (test for false, set to true
if false) ? (and dropping isCopy in the process)

For instance, i’m afraid the following sequence would fails with current

#declare Foo = isosurface{ ... };
#declare Bar = object { Foo ... };
#undef Foo;

(or any pop of #local context, such as building the isosurface via macro
or loop, or replacing the value of a previous #declare/#local )

296POV-RayGeometric PrimitivesDefinite Bug3.70 RC7DeferMediummax gradient computation is not thread safe (isosurface...Tracked on GitHub
Task Description

It appears as a side effect of investigation of #294: the code in isosurf.cpp, inside
bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)

	if(gradient < temp)
		gradient = temp;

is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)

It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)

 265 POV-RayOtherPossible Bug3.70 RC6Very LowLow 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]
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]
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]
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]
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.

246POV-RayOtherPossible Bug3.70 RC6Very LowLowRegression 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 {
  texture {T_sky}
  interior_texture {T_cosmos}
  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.

 239 POV-RaySetup/InstallDefinite Bug3.70 RC4Very LowMedium Owner and group of user's local configurations on insta ...Closed
Task Description

I reinstall a system, (so ~/.povray was not existant), and then
installed povray from sources, as a normal user (excepted the
installation step):

$ ./configure ...
$ make
$ make check
$ sudo make install

I find these steps pretty much standard.

The problem I’m noticing is that the $HOME/.povray hierarchy get owned
by root (hey, it’s *MY* directory !). There is a chown in the Makefile
for the target files (povray.ini & povray.conf), as well as subtree but:

* povowner & povgroup are hard coded to 0 (I would expect a copy of the
owner & group of $HOME, wouldn’t I ?)

For getting povowner, I would suggest `stat -c “%u” $HOME`
For povgroup, `stat -c “%g” $HOME`

Are they portable enough ? (I could ask on Monday a Solaris system, but
I do not have bsd and the other flavours of unix)

(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)

Side note: This is fine to install for the local user, but new later
users could benefit also from a ~/.povray/3.7/ subtree ; what about also
filling the /etc/skel (when available) ? (and in /etc/skel, root owner
is fine!)

 235 POV-RayPlatform-specificDefinite Bug3.70 RC3Very LowHigh 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

 218 POV-RaySample scenesDefinite Bug3.70 RC3Very LowCritical Benchmark must be updated to not reference a #local arr ...Closed
Task Description

Lines 1217, 1241 and 1242 of benchmark.cpp must be change to use #declare instead of local for A and its elements.
(because A is returned by the macro)

	"#macro L_GetVN(ResSpl)\n"
	"   #local I = 0;\n"
	"   #declare A = array[ResSpl+1][2]\n"                      //  <============== this is line 1217
	"   #while (I<=ResSpl)\n"
	"      #local P0 = 0+<FnA(I/ResSpl), I/ResSpl, 0>;\n"
	"      #if (P0.x=0 & P0.z=0)\n"
	"         #local P0 = <1e-25,P0.y,1e-25>;\n"
	"      #end\n"
	"      #if (I=0)\n"
	"         #local P1 = 0+<FnA(((I-0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #else\n"
	"         #local P1 = P2;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #end\n"
	"      #local P3 = vrotate(P0,<0,1,0>);\n"
	"      #local P4 = vrotate(P0,<0,-1,0>);\n"
	"      #local B1 = P4-P0;\n"
	"      #local B2 = P2-P0;\n"
	"      #local B3 = P3-P0;\n"
	"      #local B4 = P1-P0;\n"
	"      #local N1 = vcross(B1,B2);\n"
	"      #local N2 = vcross(B2,B3);\n"
	"      #local N3 = vcross(B3,B4);\n"
	"      #local N4 = vcross(B4,B1);\n"
	"      #local N = vnormalize((N1+N2+N3+N4)*-1);\n"
	"      #declare A[I][0] = P0;\n"                               // <============== this is line 1241
	"      #declare A[I][1] = N;\n"
	"      #local I = I+1;\n"
	"   #end\n"
	"   A\n"

Same update should also be reported into the distributed scene benchmark.pov

 217 POV-RayOtherPossible Bug3.70 RC3Very LowHigh 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.

 216 POV-RaySample scenesDefinite Bug3.70 RC3Very LowLow raddem.ini is not parsable by 3.7RC3 Closed
Task Description

in the sample scenes, animations/raddem/raddem.ini is not parsable by current versions of povray. (3.7RC3 and upto #5476)

Radiosity= is a gone away option.(from a bit of time in the 3.7 branch)

 209 POV-RayGeometric PrimitivesDefinite Bug3.70 RC3Very LowMedium Weighted texture of CSG Closed
Task Description

in change #3319, csg got a new computation for its weighted textures.

But I’m confused by the computation of the weight: (circa end of csg.cpp file)

COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);

I would have used a max() rather than a min().

It is transparent when there is only one texture, but:

  • should there be no texture (an error...): it would be a division by 0
  • should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n

Or did I get a confusion about min() ?

min(0,1) == 0
min(4,1) == 1

Using max would protect against the division by 0 and the right value when multiple textures are used.

Any thought ?

 167 POV-RayOtherDefinite Bug3.70 beta 38Very LowMedium 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 ). )

 157 POV-RayInclude filesDefinite Bug3.70 beta 37aVery LowMedium Warnings when parsing include file provided by distribu ...Closed
Task Description

Include file still provides warnings when parsed, a shame for a standard include file.
( is ok, I did not test the other includes)

File '/usr/local/share/povray-3.7/include/' line 118: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 119: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 129: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 130: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 140: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 141: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 151: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 152: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 162: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/' line 163: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
 155 POV-RayRuntime errorDefinite Bug3.70 beta 38Very LowMedium Not able to run --benchmark Closed
Task Description

Compiled on linux (revision #5066),
./configure COMPILED_BY=”###” –disable-io-restrictions

the command: povray –benchmark

is failing:
Failed to parse INI file

povray –version

povray: this pre-release version of POV-Ray for Unix expires in 27 day(s) and 5 hour(s)
POV-Ray 3.7.0.beta.38

This is a time-limited beta test version which expires 31 Dec 2010.
General distribution is strongly discouraged.

Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2010 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.4.3
Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread 
 154 POV-RaySetup/InstallPossible Bug3.70 beta 37aVery LowLow Installation on linux (unix ?) in $HOME/.povray/3.7 set ...Closed
Task Description

Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.

Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.

Please fix ?

91POV-RayTexture/Material/FinishFeature Request3.70 beta 36DeferLowSlope pattern applied to object is not transformed afte...Tracked on GitHub
Task Description

There is an big issue with the slope pattern: when the object it is applied to is instanced (again) with a transformation (in particular a rotation, as a translation would not impact.. but a shear might), the colours of the surfaces are changed.

object { p translate -5*x }
object { p rotate 220*y+20*x    translate 3*x }       

Nobody would expect the object to be different in appearance.
If slope {} is replaced with wood, all is fine. (as for others textures, i guess)

IMHO, the slope vector need to be adjusted for the later transformation(s) (so as to compensate the issue of using the Perturbed Normal vector).

This should not impact the AOI/FACING (experimental) patterns, as AOI definition is pretty clear about duplicating & transform if you think about it a bit, as well as FACING: for these two, it is expected to either use the ray(current point of view) or a fixed 3D point as reference. At the limit, discussion about moving the 3D point of FACING might also be opened to interpretation.

AOI/FACING are in task #19

 73 POV-RayParser/SDLDefinite Bug3.70 beta 34Very LowMedium Blend map cannot get 256 entries Closed
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.

 40 POV-RayPlatform-specificCompatibility Issue3.70 beta 32Very LowMedium Compilation on freebsd Closed
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)

 24 POV-RayGeometric PrimitivesDefinite Bug3.70 beta 32Very LowCritical isosurface, bounding box & threads Closed
Task Description

Linux beta 32, 64bits, compiled from sources.

povray -w800 -h600 +a0.3 +kfi1 +kff78
-Ii_internal.pov +WT5 +R4 +AM1 +MB1

Important issue: +WT5 +MB1

Seems Fine for +WT1 +MB1
Also fine for +WT5 +MB9

The intersection with the containing box displays some two-shades of grey
random checkered patterns.
Size of square looks like size of renderering thread. Position too.

Impacted frames (of 78):
01, 02, 03, 30, 48, 74, 76.

 23 POV-RayPlatform-specificCompatibility Issue3.70 beta 32Very LowMedium X Window preview might lock Closed
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.

Showing tasks 1 - 22 of 22 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing