POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

IDCategoryTask TypeReported InPriority  descSeveritySummaryStatusProgressDue In Version
7RadiosityUnimp. Feature/TODO3.70 beta 32LowMediumRe-implement Radiosity render abort/continue supportTracked on GitHub
0%
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.

313RadiosityDefinite Bug3.70 releaseLowHighradiosity.cpp pov::RadiosityFunction::BeforeTile assert...Tracked on GitHub
20%
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

70PhotonsUnimp. Feature/TODO3.70 beta 34LowHighload/save photons should be controlled via command lineTracked on GitHub
0%
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.

309Parser/SDLDefinite Bug3.70 RC7Very LowLowWarning Message MissingTracked on GitHub
0%
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.

96Texture/Material/FinishFeature RequestNot applicableVery LowLowUser-defined warpsTracked on GitHub
0%
Future release Task Description

User-defined warps would be nice to have, something along the lines of:

warp {
  function { MyFnX(x,y,z) } // function to compute pattern-space x-coordinate from object-space <x,y,z> coordinate
  function { MyFnY(x,y,z) } // ditto for pattern-space y coordinate
  function { MyFnZ(x,y,z) } // ditto for pattern-space z coordinate
}

// a displacement warp:
warp {
  function { x + MyFnX(x,y,z) }
  function { y + MyFnY(x,y,z) }
  function { z + MyFnZ(x,y,z) }
}
106DistributionUnimp. Feature/TODO3.70 beta 37Very LowLowUpdate sample scenes and include files for POV-Ray 3.7 ...Tracked on GitHub
0%
Task Description

Most sample scenes and include files were designed at times when POV-Ray did not to any proper gamma handling, or still used the inferior 3.6 “assumed_gamma” mechanism.

All the scenes and include files should be reviewed, and updated to fit the new 3.7 gamma model.

The primary task will probably be gamma-adjusting literal color values and ambient parameters; I suggest using macros (which ideally should be defined in an include file) to be set according to the #version statement, so the scene/include file could be kept compatible with older versions.

181BackendUnimp. Feature/TODO3.70 beta 40Very LowMediumUnimplemented, altered or missing features to document ...Tracked on GitHub
0%
Task Description

This is a list of unimplemented features and things to fix with respect to 3.7 vs 3.6 compatibility. They either need to be fixed in code, or failing that, to be documented prior to release.


Create_INI works differently from 3.6. Prior versions of POV-Ray would write all options to the file, even if they were not supplied by the user (non-supplied options would take the default value). Currently in 3.7, only supplied options are written, because the front-end does not send unused options to the back-end. The proper fix for this would be to have a set of defines that establish the defaults all in one place (currently we rely on hard-coded values scattered around the code), and for the Output_INI_Option() function to look up and use the default when not supplied. As this is not likely to be done before 3.7 release, we need to document it as a temporary situation.

The following messages are marked as ‘currently not supported by code’ in povmsgid.h. We need to check where this comment is correct and if so the docs need to be updated to indicate this (for items that are already documented). Some items may be re-implemented later, and some may never be:

  • kPOVAttrib_TestAbort
  • kPOVAttrib_TestAbortCount
  • kPOVAttrib_VideoMode
  • kPOVAttrib_Palette
  • kPOVAttrib_DisplayGammaType
  • kPOVAttrib_FieldRender
  • kPOVAttrib_OddField
  • kPOVAttrib_AntialiasGammaType
  • kPOVAttrib_LightBuffer
  • kPOVAttrib_VistaBuffer
  • kPOVAttrib_DrawVistas

This bug should be edited to add/remove items as time goes by.

269Texture/Material/FinishPossible Bug3.70 RC6Very LowLowTransparent Objects inside Media Cause ArtefactsTracked on GitHub
0%
Task Description

When placing a transparent object inside another object which contains media, artefacts may occur (see attached file). They look similar to specular highlights or are just strange white spots in the image.

I discovered artefacts of that kind first in the image of which MediaArtefactDetail.png is a cropped part. The code I managed to reproduce such artefacts with contained a “starfield” sphere

sphere {
  <0,0,0>, 1
  
  pigment { rgbt 1 }
  
  interior {
    media {
      emission rgb 1/10
      density {
        crackle form <1,0,0>
        density_map {
          [0.0 rgb 1]
          [0.05 rgb 0]
        }
        scale 0.002
      }
    }
  }
  
  scale 1000
  
  hollow on
}

and a transparent sphere

sphere {
  <0,0,0>, 1
  
  pigment { rgbt 1 }
  
  scale 2
  
  hollow on
}

which is, obviously, completely inside the other sphere. So is the camera.

Since the sphere has a pigment { rgbt 1 }, it should be completely invisible, which is correctly rendered as long as the scaling factor is 1 and hollow off (MediaArtefact1.png). Changing hollow to on does not yet produce the artefact, but the right half of the output image seems to be shifted by one pixel (MediaArtefact2.png). Changing the scaling factor to 2 (as it is in the above code) produces the artefact (MediaArtefact3.png). Changing the camera location (MediaArtefact4.png) does not change anything, the artefact just “moves with the sphere”. Changing the sphere size again, however, seems to stir up the “stars” in the “starfield” sphere while not removing the artefacts (MediaArtefact5.png). Changing hollow to off again does neither (MediaArtefact6.png).

The artefacts are definitely no specular highlights. There is not even a light source in the scene that could produce any. I used POV-Ray 3.7 RC6 to render the images, but the artefact shown in MediaArtefactDetail.png already occured in POV-Ray 3.6 which I used to render that image.

323User interfacePossible Bug3.70 releaseVery LowVery LowTooltip for render speed status bar has wrong unitTracked on GitHub
0%
Task Description

Tooltip popup for render speed always displays as “Pixels per Second” rather than matching status bar. I’ve noticed it in 3 renders so far. Most of my renders are fast enough not to see any other unit besides PPS, but I should be able to reproduce again if necessary.

288Geometric PrimitivesPossible Bug3.70 RC7Very LowLowTolerance problem with refraction in blobs in CSG inter...Tracked on GitHub
0%
Task Description

If a blob is intersected by something else, the composite object has incorrect refractions if it is too small (in absolute units). Having the same object constructed without a blob, the errors happen at much smaller scales. The errors don’t affect solid objects, just refractions.

An example shows a half-sphere, constructed as CSG sphere + plane, and identical half-pshere, constructed as CSG blob + plane. When the scale of the entire construction is changed, the refractions disappear first for the blob, and at 100x times smaller scale, also for the sphere. The right side shows the solid version, showing that the surface intersection test is ok, it’s just the refraction that fails.

The problem is not present when looking from the curved side (the blob side). So the ray that hits the blob, gets refracted correctly, but the ray that hits the intersecting plane first, and should then refract in the blob from the inside, doesn’t work. If in attached sphere, you exchange -y with y in clipping planes, everything is ok.

The scale when this happens is not very small - blobs of radius 0.02 already fail (noticed because in 1=1metre scale, blob raindrops on a glass plate didn’t have intersections when looking from the back).

Examples are named by factor=9,0.9,0.09,0.009 and you can see first the blob (top) refraction gets smaller and disappears, then later the bottom (sphere) also gets the same problem.

205DocumentationUnimp. Feature/TODO3.70 RC3Very LowLowSyntax documentation uses inconsistent notationTracked on GitHub
0%
Task Description

The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.

327Parser/SDLFeature Request3.70 releaseVery LowLowSupport for non-ASCII characters in filename stringsTracked on GitHub
0%
Task Description

pov 3.7 Can not identify the Chinese.I give the texture map filename in chinese,it turns out parse error.

145Parser/SDLFeature Request3.70 beta 37aVery LowLowStack trace report on errorTracked on GitHub
10%
Task Description

In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.

Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.

Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.

Not sure how much of this is achievable in Povray.

81Geometric PrimitivesDefinite Bug3.62Very LowMediumsphere_sweep generating artifactsTracked on GitHub
0%
Task Description

I’m running POV-Ray for (64 bit) Windows v3.62 on (64 bit) Windows Vista

This pov file:


#include "colors.inc"
#include "metals.inc"

light_source { <6, 9, -21> color White }
camera { location <0, 0, -3> look_at <0, 0, 0> }

sphere_sweep {
                cubic_spline
                6
                <-2.0, 0, 0> 0.05

                <0.000,0,0> 0.2
                <0.025,0,0> 0.2
                <0.050,0,0> 0.2
                <0.075,0,0> 0.2

                <3.0,0,0> 0.2
                pigment { color White }
}

Produces two strange artifacts: A disk at the center of the sweep, and a faint “halo” or veil which shows as 4 faint hyperbolas centered around the origin.

I have tried tweaking tolerance (for no other reason than I saw that someone else was tweaking it to solve a problem) but this does not seem to change things.

For a look at MY result when I run this, view this image:

riventree.comarchivebugdatapovrayspheresweepartifacts.jpg

Alain reports the same behavior in the latest version: “It’s still there with the latest version: 3.7 beta 35a.” This MAY move the status to “confirmed”, but I can’t do that

Someone else says that changing the scale (!) “solves” the problem by moving the disk and the halo offscreen, but that sounds like a bad idea to me.

-Jeff Evarts, first-time POVRay bug reporter

251Parser/SDLPossible Bug3.70 RC6Very LowMediumScene / include files of >2GB size may cause problemsTracked on GitHub
0%
3.71 release Task Description

Code inspection shows that we’re still using fseek() and ftell() in various places (including text file input), which can’t handle file positions of 2GB and beyond (except on 64-bit linux machines); those calls need to be examined and (where appropriate) replaced with the fseek64() macro we’re already defining (but currently not using), and a to-be-defined ftell64() macro.

One potential (untested) error scenario would be a scene file calling a macro that is defined at the end of a > 2GB long include file.

326OtherDefinite Bug3.70 releaseVery LowLowrestricted setting ignored in 3.7Tracked on GitHub
0%
Task Description

Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.

Fixing this reveals some other issues:

  • %INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc, not /usr/local/etc
  • read+write paths are added to the read list only, so writing is impossible

See attached patch.

Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc.

Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.

75Geometric PrimitivesUnimp. Feature/TODO3.70 beta 34Very LowMediumReplace POV_MALLOC with std::vector in shape codeTracked on GitHub
30%
Future release Task Description

In the files bezier.cpp, fpmetric.cpp, fractal.cpp, hfield.cpp, isosurf.cpp, lathe.cpp, poly.cpp, polygon.cpp, prism.cpp, sor.cpp, and sphsweep.cpp the use of POV_MALLOC can be replaced by std::vector quite easily because the containing class already is a C++ class. As this is a low hanging fruit for continued code cleanup, it should be done sooner rather than later.

20User interfaceFeature Request3.70 beta 32Very LowVery Lowrender window behaviorTracked on GitHub
0%
Task Description

When changing the behavior of the render window, “Keep above main”, requires restarting the POV editor to take effect. It would be nice either to get a warning to restart, or to get it to work without restarting.

47PreviewPossible Bug3.70 beta 32Very LowLowRender Preveiw window can become disabledTracked on GitHub
0%
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.

246OtherPossible Bug3.70 RC6Very LowLowRegression on scale limit between 3.7 and previous rele...Tracked on GitHub
0%
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.

286Texture/Material/FinishPossible Bug3.70 RC7Very LowLowreflection exponent other than 1 causes black artifacts...Tracked on GitHub
0%
Task Description

[EDIT: Original title was “radiosity causing black patches when using emission less than 0”]

see attached image for reference.

mountain on left has emission set to -.13 and black patches show up, when emmission set to 0 or greater no patches

changing max_trace or any radiosity settings has no effect

setting no_radiosity on mountain fixed problem as a temp fix

code sample ...

#version 3.7;

#default { finish { ambient 0 } }
#declare rad_lvl = 4;

global_settings {
  assumed_gamma 1
  max_trace_level max(5,rad_lvl*3)
  adc_bailout .007
  ambient_light 0
  radiosity {
   pretrace_start 64/max(image_width,image_height)
   #if(rad_lvl)
    pretrace_end max(2,int(8/rad_lvl))/max(image_width,image_height)
   #else
    pretrace_end 32/max(image_width,image_height)
   #end
   count pow(rad_lvl+1,2)*10
   nearest_count 1
   #if(rad_lvl) error_bound 1/rad_lvl #end
   low_error_factor max(.4,(8-rad_lvl)/10)
   recursion_limit 1
   gray_threshold .25
   brightness 1
   max_sample 1
   normal on
   media off
   always_sample off
   minimum_reuse min(.008,8/max(image_width,image_height))
   maximum_reuse .1
   adc_bailout .02
  }
}

#declare sunC = rgb <1, 1, .9925>; // actual D65 standard illuminant
#declare SkyC = rgb <.3195, .5745, .8805>;
#macro GammaAdj(C,G) rgb <pow(C.red,G),pow(C.green,G),pow(C.blue,G)> #end

light_source {
  50000*y
  sunC*1.06
  area_light <-300, 0, -300>, <300, 100, 300>, 3, 3
  rotate <-28, 0, 14>
  adaptive 0
  circular
}

 sphere { 0, 1
  texture {
   pigment{
    gradient y
    pigment_map{
     [.07 GammaAdj(SkyC,.5)]
     [.2 average pigment_map { [.5 GammaAdj(SkyC,.75)][1 wrinkles turbulence .65 octaves 5 lambda 3 omega .9 color_map { [.2 rgb 1][.5 SkyC] } scale <10, .1, 1>] }]
     [.4 GammaAdj(SkyC,1.15)]
     [.5 GammaAdj(SkyC,1.35)]
    }
    rotate -75*y scale <1, 1, 100>
   }
   finish { diffuse .72 }
  }
  scale 100000
  inverse
 }


#declare Cam_pos = Cam_pos + <0, 20, -40>;
#declare Cam_lkt = Cam_lkt + <0, 10, 50>;
camera {
  location Cam_pos
  direction <0,0,1>
  right 1.33*x
  up y
  sky <0,1,0>
  #if(Cam_agl) angle Cam_agl #end
  look_at Cam_lkt
}

#macro sinai(HillQ)
 #local F = function { pattern { granite poly_wave 4 turbulence .01 lambda 2.1 omega .9 scale 5 translate <.2, 0, 18.08> scale <2, 1, 3> } }
 #local N = function { pigment { crackle ramp_wave turbulence .3 lambda 2.2 omega .76 color_map {[0 rgb 0][1 rgb 1] } scale .07 translate <-.15, -.12, .13> } }
 height_field {
  function HillQ, HillQ { F(x,y,z) + N(x,y,z).grey/47 }
  water_level .05
  clipped_by { box { <0, .05, .3>, <1, 1, 1> } }
  translate <-.5, -.05, -.5>
  rotate 20*y
  texture {
   pigment{ crackle color_map { [0 rgb <161, 107, 71>/255][.25 rgb <193, 132, 93>/255][.35 rgb <218, 163, 123>/255][.45 rgb <212, 153, 112>/255][.55 rgb <222, 166, 125>/255][.65 rgb <236, 178, 124>/255][.75 rgb <220, 154, 102>/255][.85 rgb <160, 121, 103>/255] } turbulence .75 lambda 3 omega .7 scale .1 }
   finish{ diffuse albedo .56 emission -.13 specular .25 roughness .02 brilliance 1.5 metallic 1.3 }
   normal { crackle poly_wave .7 turbulence .4 omega .8 scale <.007, .03, .007> }
  }
  rotate 12*y
  scale <2400, 2000, 3000>*1.5
  translate <1900, 0, 1900>
  scale <-1,1,1>
  no_radiosity
 }
#end


sinai(1600)
plane { y,0 pigment { rgb <1, 1, 1> } }

//courtyard gating not included due to size of code and many external files needed. add anything around <0,0,0> to try to reproduce effect of error
172Image formatUnimp. Feature/TODO3.70 beta 39Very LowLowRe-implement progressive image outputTracked on GitHub
0%
Future release Task Description

With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.

71User interfaceUnimp. Feature/TODO3.70 beta 34Very LowLowraise warning when command line option has no effectTracked on GitHub
0%
Task Description

Warnings should be raised when a command line option has no effect,
for example...

pvengine +am

is legal, but without the number after it, it has no effect.

pvengine +am7

should be an error, and also raises no warnings.

293User interfacePossible Bug3.70 RC7Very LowLowPOV-Ray Shown Twice in Windows TaskbarTracked on GitHub
0%
Task Description

When rendering for some time, it occasionally happens that POV-Ray appears twice in the Windows taskbar. One button is the normal one, the other one does not open any window when clicked on and reads something like “99% complete” (see attached image), like the render window’s title, but obviously unrelated to it (probably the title the render window had shortly before?). After stopping the render, the odd taskbar button remains there until POV-Ray is closed.

  • Observed under Windows XP
  • POV-Ray 3.7.0.RC7.msvc10-sse2.win32
  • When applications are summarized into groups in the taskbar by Windows, the odd POV-Ray button is attached to the Windows Explorer group
  • Run with render priority set to “high”

Is this a Bug in Windows or in POV-Ray?

252PhotonsDefinite Bug3.70 RC6Very LowLowphotons and light_group is brokenTracked on GitHub
0%
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.

299Parser/SDLFeature Request3.70 RC7Very LowLowObject Properties FeatureTracked on GitHub
0%
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

  • declare which properties a certain object can have
  • set these properties inside the object statement in which the object is used.

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.

240Geometric PrimitivesFeature Request3.70 RC3Very LowLowObject for efficient automatic periodic pavementTracked on GitHub
0%
Task Description

Whenever some object is to be periodically repeated in some kind of grid, you can achieve this with macros, but it
a) wastes a lot of resources

 even if object references are implemented in the future, wrapper with its own transformation matrix still takes space and bookkeeping

b) is not infinite

 annoying when making infinite planar tiling with arbitrary objects
 like an approximate water surface or tiling with real bricks
 or anything that needs to extend to horizon

c) is not optimized for periodicity

I think it can be very efficiently implemented as an object that takes a finite object argument (like CSG functions) and can be periodic in either 1D,2D or (possibly dangeorous?) 3D with specified period. In each dimension, the number of repetitions can be any integer or even infinity (or max_int). Something like
periodicity <2,2,Infinity> 2 copies in 1 direction, 2 in the other, infinite in the third
grid_separation <1,2,2>
1 unit size in first direction, 2 unit sizes in the other two

All the code needs to do is raytrace in the current unit cell and if the ray passes uninterrupted, pass it through the neighbouring unit cell (which means trace a translated ray through the same object). The object itself would just feel an additional clipping box, everything else would work seamlessly.

In case of infinite column of transparent object, max_trace stops the infinite loop anyway.

This is just a suggestion, I realize this is more of a long-term change but it is quite easy to implement and would simplify a large number of projects.

202Geometric PrimitivesDefinite Bug3.70 RC3Very LowLowNumerical oddities in Julia_FractalTracked on GitHub
0%
Task Description

I understand that some things have changed in the way certain computations in POV-Ray decide when something is “good enough” and I think this is biting me in Julia_Fractal (where, of course, the highest-resolution computations are needed).

The bug has been posted here:

http://news.povray.org/povray.bugreports/thread/%3Cweb.4dbf2e26b56a53c15b4449250%40news.povray.org%3E/

Including a short .pov file and instructions that reproduce it.

(It pops up in other configurations and view angles as well, but this one captures in in a way that makes it clear it’s a bug: the distance of the camera from the origin appears to change the shape of the rendered object).

This appeared first on a Windows Server 2003 machine, it is apparently confirmable on at least one other system as per that thread.

151Runtime errorPossible Bug3.70 beta 37aVery LowLowNo way to cancel save while parsing, never ending error...Tracked on GitHub
0%
Task Description

On Windows, when I try and save a file while it is being parsed prior to rendering, I get an error, “Failed to save file: The operation completed successfully”, with a single OK button to click. Despite the weird wording, I’m OK with that.

However after clicking OK I get the error, “Failed to save file ‘...’“, with three buttons: Cancel, Try Again, Continue. Not sure what “Continue” means in this context, given that the possibilities would seem to be covered by the other two buttons. Whatever.

Also, sometimes I get a message with only a single “Retry” button. Not sure what the exact message was.

Anyway, the real problem is that, regardless of which button I press, the program continues to spawning the same error message endlessly. Luckily there is a delay between them, but still it would be nice to have at least one of the three buttons *stop* POV-Ray from asking me again.

Also, once the program finishes parsing the file and it becomes possible once again to save the file, it does nothing. I.e. it doesn’t save the file. So what’s the point of the message and all the options? Why not just say, “Unable to save the file, file is parsing” and be done with it?

I think I recall the same behavior in 3.6.2, so it’s nothing new that’s been introduced.

273OtherDefinite Bug3.70 RC6Very LowMediumNo automatic backup files from inc filesTracked on GitHub
0%
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.

226Geometric PrimitivesPossible Bug3.70 RC3Very LowLowNear-coincident surface accuracyTracked on GitHub
0%
Task Description

This is a transparent box very close to a plane.

box {
    -1, 1
    pigment { rgbf <0, 0, 1, 1> }
}

plane {
    #if (version < 3.7)
        y, -1.0000007
    #else
        y, -1.00007
    #end
    pigment { rgb 1 }
    finish { ambient 1 }
}

camera {
    location <1, 2, 3>
    look_at 0
}

The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).

So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)

108Parser/SDLFeature Request3.70 beta 37Very LowLowmotion_blur feature similar to Megapov versionTracked on GitHub
0%
Future release Task Description

motion_blur which is a simple and effective feature to use in Megapov to simulate motion blur of, e.g. bird wings, propellers or running animals, would be a neat addition to version 3.7 and later.

In Megapov, the feature requires a line of code in the global_settings{} e.g.: motion_blur 10, 2
and a declaration for the moving object. e.g.:

motion_blur {
  type 0
  object{MyObject  material{MyMaterial rotate x*clock*2}}
  rotate x*clock*10
}

type represents several types of pre-defined motions.

Thanks,

Thomas

196Subsurface ScatteringDefinite Bug3.70 RC3Very LowLowMore SSLT CaveatsTracked on GitHub
90%
Future release Task Description

when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.

118Light sourceFeature Request3.70 beta 37aVery LowLowMore efficient handling of fading lightsTracked on GitHub
0%
3.71 release Task Description

Currently, fading light sources are used for lighting and shadow
calculations even when so far away as to no longer have any effect
on the outcome. The proposed solution is to add a new keyword
fade_cutoff_distance which tells povray to ignore the light
source when alluminating a point at larger distance.

A sample implementation is provided in the attached files. These
changes are still based on beta 34 as sources for the current beta
are not yet available, and starting to merge changes to beta 35
only at this time didn’t seem worth the effort. Also, please
disregard, changes in the CVS header comments (I also use
CVS locally for managing source files).

Further considerations regarding this feature:

- For special effects this feature can also be used if the light
source does not actually use fading. On the other hand, cutting
the light at some distances can be considered an extreme form
of fading which may justify the keyword name anyhow.

- Depending on how  FS#46  is implemented, the test for cutoff may
then be needed at another location as well.

- The default value currently is 0 (or *no* cutoff distance). For
#version 3.7 of higher, the default could be chosen automatically
based on the light source intensity and adc_bailout, although it
may then need to be overriden by the user for extreme pigments.

115Texture/Material/FinishFeature Request3.70 beta 37aVery LowLowMore cutaway_texturesTracked on GitHub
0%
Future release Task Description

Think this is still a problem. See the attached scene file. Find the WindowFrameSegment declaration for more info. The scene as-is shows the problem (SOME portions of the difference inherit the color of the room) the window opening is scaled larger to show that they AREN’T touching. The problem goes away when (in WindowFrameSegment) the 1st occurrence of the applied texture is commented out and the 2nd occurrence is uncommented, and cutaway_textures is commented out.

178Texture/Material/FinishFeature Request3.70 beta 39Very LowLowModify metallic reflection code to better work with con...Tracked on GitHub
0%
Task Description

The combination of metallic reflection with conserve_energy causes the reflection to lose colour, as demonstrated by the following scene:

global_settings {
  max_trace_level 10
}

camera {
  right x*image_width/image_height
  location  <-2,2.6,-10>
  look_at   <0,0.75,0>
}

light_source {
  <500,300,150>
  color rgb 1.3
}

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 0.7 } }
}

#declare M=
material {
  texture {
    pigment {rgbt <1.0,0.7,0.2,0.99>}
    finish {
      ambient 0.0
      diffuse 0.5
      specular 0.6
      roughness 0.005
      reflection { 0.8, 1.0 metallic }
      conserve_energy
    }
  }
  interior { ior 1.5 }
}

box {
  <-0.2,0,-2.3>, <0.0,4,0.3>
  material { M }
  rotate z*5
  rotate x*2
}
295User interfaceDefinite Bug3.70 RC7Very LowLowMinor GUI BugsTracked on GitHub
0%
Task Description

Here are two low-priority bugs in POV-Ray’s GUI, observed by me under Windows XP, which should be easy to fix I think:

  • In the “Insert” menu, there are sub-menus (e.g. “Radiosity and Photons”) in which there are menu seperators at the end of the popped-up menu bar.
  • The progress bar in the top-right corner of the editor window seems to be too large for the window (203px) and therefore clipped. As a result, progress seems to be 100% when it is not yet, e.g. at 90% progress. (Have not measured exactly.)

Both bugs are not severe at all, but it would be nice if they could be fixed.
By the way, a second progress bar could be added to visualize the number of frames already rendered in an animation.

333User interfaceFeature Request3.70 releaseVery LowLowMake text in "about" alt+b dialog selectable with the m...Tracked on GitHub
0%
Task Description

When you press alt+b or access the “about” dialog in the Help menu it displays some text including software version number and list of contributors.

It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.

335Parser/SDLPossible Bug3.70 releaseVery LowLowmacro works in variable but not in arrayTracked on GitHub
0%
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.

4Subsurface ScatteringUnimp. Feature/TODO3.70 beta 32Very LowLowIntegrate Subsurface Scattering with standard lighting ...Tracked on GitHub
90%
Future release Task Description

Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.

222Geometric PrimitivesDefinite Bug3.70 RC3Very LowLowincorrect render of CSG merge with radiosityTracked on GitHub
0%
Future release Task Description

The problem arises when I am trying to trace a radiosity scene without conventional lighting that has a GSG merge object. There are a coincident surfaces, but these surfaces are first merged, then the texture applied. The texture is a simple solig color non-transfluent pigment, default normal, default finish etc..

Problem consists when adding antialiasing, changing resolution, changing camera view-point etc.; when I replace merge with union, the problem disappeared.

The scene was checked on two different machines with different versions of POV-Ray:

  1. Gentoo Linux, kernel 2.6.39-r3, i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel, 2G RAM (this is Dell PowerEdge 2650 server with 2 dual-core Intel Xeon MP processors); Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (i686-pc-linux-gnu-g++ 4.5.3 @ i686-pc-linux-gnu)
  2. Gentoo Linux, kernel 2.6.37-r4, x86_64 AMD Athlon™ X2 Dual Core Processor BE-2350, 2G RAM (non-branded machine); Persistence of Vision™ Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++ 4.4.4 @ x86_64-pc-linux-gnu)

(scene has been adapted slightly to be rendered with 3.6, the adaptation was to change “emission” with “ambient” and replace gamma “srgb” with “2.2”)

Both machines generate similar images.

The attachment is an archive containing sources of minimal scenes with these problems, and sample pictures I generated from them on my machines.

230User interfaceFeature Request3.70 RC3Very LowLowImproved handling of animationsTracked on GitHub
0%
Task Description

October to middle November, I prodduced a 5 minutes video mainly py POVRAY.

Here a part of the video.ini file

#

# szenes based on games.pov
#

#game-pat
#Initial_Frame=450 - time scale 1000 - 30 seconds
#Final_Frame=899
#Initial_Clock=-12500
#Final_Clock=17500

#game-lost - time scale 1000 - 22 seconds
#Initial_Frame=0
#Final_Frame=659
#Initial_Clock=2000
#Final_Clock=24000

#game-lost - time scale 3000 - 12 seconds - fast through the night
#Initial_Frame=0
#Final_Frame=359
#Initial_Clock=24000
#Final_Clock=60000

#book-cover
#clock=64000

#game-sunrise - time scale 1000 - 35 seconds
#Initial_Frame=0
#Final_Frame=1049
#Initial_Clock=60000
#Final_Clock=95000

Now imagine all the problems:

One computer crashes often because of thermal problems.
Last picture rendere 487.

Now calculate the setings, that this computer continues the task at 487

Or 2 computers should render a scene.

Sounds very easy. Something like computer 1 makes 0..499 computer 2 makes 500..999.

But the computers are different in speed and the pictures are
very different in computation time.

So it would be best

computer 1: 0 to 999
computer 2: 999 to 0

They would meet in the middle, where ever this middle is.

So it would be much easier with

#game-sunrise - time scale 1000 - 35 seconds
Initial_Frame=0
Final_Frame=1049
Initial_Clock=60000
Final_Clock=95000
Initial_Task=487
Final_Task=1049

So I have not to calculate the exact clock seting,
when a computer sould continue a task after crashing at picture 487

#game-sunrise - time scale 1000 - 35 seconds
Initial_Frame=0
Final_Frame=1049
Initial_Clock=60000
Final_Clock=95000
Initial_Task=1049
Final_Task=0

This would be the reverse calcualtion order.
Starting with picture 1049 and going down 1048..1047

44RadiosityFeature RequestAllVery LowLowImprove Normals Handling in RadiosityTracked on GitHub
0%
Future release Task Description

Currently, radiosity does not make use of the fact that pertubed normals would theoretically just require a different weighting of already-sampled rays, leading to the following issues:

  • Honoring normal pertubations in radiosity leads to an increased number of samples, slowing down sample cache lookup.
  • The increased number of samples is generated from a proportionally higher number of sample rays, slowing down pretrace even further.
  • Low-amplitude pertubations tend to be smoothed out; “reviving” these is only possible by increasing the general sample density.
  • Handling of multi-layered textures with different normal pertubations is currently poorly implemented.

As a solution, I propose to store for each radiosity sample not only the resulting illumination for a perfectly unpertubed normal, but from the same set of sample rays also compute the illumination for an additional set of about a dozen standardized pertubed-normal directions, and interpolate among these when computing the radiosity-based illumination for a particular point that has a pertubed normal.

For backwards compatibility, this method of dealing with pertubed normals in radiosity might be activated by a different value for the “normal” statement in the radiosity block, say, “normal 2”.

41OtherFeature Request3.70 beta 32Very LowLowimprove command-line parsing error messagesTracked on GitHub
0%
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.

248Parser/SDLFeature RequestNot applicableVery LowLowImplement mechanism to compute direction of a splineTracked on GitHub
0%
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.

278BackendFeature Request3.70 RC7Very LowMediumImplement Lens Flare RenderingTracked on GitHub
0%
Task Description

Currently POV-Ray does not support rendering lens flare effects, however, they can be simulated using a macro (include file) by Chris Colefax.

I would like to suggest adding a feature to POV-Ray to support lens effects “natively” since

  • as far as I know the macro has been designed for POV-Ray 3.1 so with each new POV-Ray version it gets more likely that this macro does not work properly any more
  • the macro does not work when rendering with radiosity, probably because the macro creates the lens effect by using a pigment with a high ambient value (which is ignored by POV-Ray 3.7’s radiosity algorithm).

Additionally, the macro is not quite easy to employ because

  • it needs to know the exact camera parameters (location etc.) and defines an own camera itself so any important camera information has to be stored if the effect has to work as expected
  • it does not (actually cannot) take into account that objects may (partially) hide the lens effect
  • reflections and refractions (of light sources) cannot be combined with it properly - the user would have to calculate both the point where the reflected/refracted light source can be observed and the shape it then has due to distortion, and in more complex scenes such computations are nearly impossible in SDL.

I would suggest integrating such a lens flare rendering feature with the “looks like” mechanism you already have for light sources. Several parameters that can currently be set for the macro - including effect brightness and intensity, lens options and whether to create a flare at all - could be set for the light source.

Then POV-Ray could store the location and colour of each ray that finally intersected the “looks like” object of a light source and, having finished the main rendering, from that data compute a partially transparent “lens flare layer” eventually mixed into the rendered image. By this, the above mentioned problems could be avoided:

  • an object fully or partially intersecting a light source’s “looks like” object would also reduce the number of pixels used to create a flare - and therefore reduce that flare until fully hiding it
  • the same goes for reflected and/or refracted versions of the “looks like” object
  • the camera’s location and other properties would be used automatically
  • and finally, as a feature supported by POV-Ray itself, there would be neither compatibility issues nor problems like the effect not fitting together with radiosity.

Do not get me wrong, I would not expect POV-Ray to really calculate intersections that naturally happen in a camera lens, causing lens flares. Effects looking appropriate can actually be created just in 2D space (as some graphics programs do support) so the work to be done would, as far as I have any overview, be:

  • storing, as mentioned above, the relevant data for pixels showing “looks like” objects
  • calculating a lens flare from that data after the render has finished
  • overlaying the rendered image with the newly created lens effect.
334Texture/Material/FinishFeature Request3.70 releaseVery LowLowHLS colorsTracked on GitHub
0%
Task Description

It would be nice to be able to specify colors in HLS as well as RGB.

Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.

263Parser/SDLFeature Request3.70 RC6Very LowLowFunctions and patterns for finish variationsTracked on GitHub
0%
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.

79Source codeFeature Request3.70 beta 35aVery LowLowFull-Featured Test-Scene to check the correctness of po...Tracked on GitHub
0%
Future release Task Description

Hi,

it would be nice if there exists a test scene (not a benchmark) which has a high coverage of povray source and can be used as correctness validation of povray. It schould be produce an image which can be compared to a golden reference image.

It may be also possible to create a regression test suite which does automatic comparision of the render results.

50Runtime errorPossible Bug3.70 beta 32Very LowMediumFrequent segfaults with photon scenesTracked on GitHub
0%
Task Description

I observe frequent segfaults with POV-Ray 3.7 betas when rendering scenes using photons:

  • Debian Linux 4.0r5 “etch” for AMD64
  • AMD Phenom X4 9650 2.3GHz, 6 GB RAM
  • POV-Ray compiled with Intel icpc 11.0

Segfaults are sporadic but frequent (occurring in roughly 50% of all photon renders).

Showing tasks 1 - 50 of 103 Page 1 of 31 - 2 - 3 -

Available keyboard shortcuts

Tasklist

Task Details

Task Editing