All Projects

IDProjectCategoryTask TypeReported InPrioritySeveritySummaryStatusProgressDue Date
256POV-RayTexture/Material/FinishFeature Request3.70 RC6Very LowLowCSG texturing modesTracked on GitHub
Task Description

At times, the current method of specifying texture for
CSG components and compounds is restricting. The issue
pops up now and then, see e.g.

There should be a new CSG option “texture_mode” or similar, which could take
one of the following values:

preserve (the current behavior)
cutaway (the current behavior when specifying cutaway_textures)
override (replace all individual textures with compound texture)
layer (layer the compound texture over the existing textures)

and possibly, more involved

modify/merge: if both element and compund textures are simple, i.e.
not layered or mapped, override all default values of the element
textures with the values from the compound texture. The idea would
be to, e.g., have the elements already pigmented but then apply
common normal or finish properties.

 168 POV-RayTexture/Material/FinishDefinite Bug3.70 beta 38Very LowMedium noise_generator default broken Closed
Task Description

[Original Title: “texture_map interpolation does not work correctly for some patterns”]

The below test scene should yield identical textures
T_STRAND1 and T_STRAND2 but this is not the case. Reported
and verified in

The problem seems to affect bozo, bumps, dents, granite, spotted,
and maybe wrinkles. The problem was reported earlier in

with a comment that 3.6 gives the expected results

#declare C_STRAND = color rgb 1;

#declare C_CLEAR  = color rgb 0;

#declare T_STRAND = texture
  pigment {color C_STRAND}

#declare T_CLEAR = texture
  pigment {color C_CLEAR}

#declare T_STRANDS1 = texture
    granite scale 2 color_map
      [0.0 color C_STRAND]
      [0.5 color C_CLEAR]
      [1.0 color C_CLEAR]

#declare T_STRANDS2 = texture
  granite scale 2 texture_map
    [0.0 T_STRAND]
    [0.5 T_CLEAR]
    [1.0 T_CLEAR]

  z, 10
  texture {T_STRANDS1}
  //texture {T_STRANDS2}
118POV-RayLight sourceFeature Request3.70 beta 37aVery LowLowMore efficient handling of fading lightsTracked on GitHub
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.

 80 POV-RayParser/SDLPossible Bug3.70 beta 35aVery LowMedium Bad behavior for missing image file Closed
Task Description

The following SDL code

sphere {0, 1 pigment {image_map {png "missing.png"}}

yields “render failed” in 3.7b25 and the position of the error
is not highlighted in source code, giving no clue what went wrong.
In 3.6 this yields “Parse Error: Cannot open PNG file”.

Showing tasks 1 - 4 of 4 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing