I probably don’t have to explain why the camera_view pigment in MegaPOV was important, but I will list some reasons anyway:

1) post-processing could be performed in-scene
2) new types of focal blur effects could be created
3) feedback fractals were possible

I’m sure there are many others, as this is one of those features that has undetermined potential!

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.

The following scene gives a comparison of current conserve_energy handling in standard shadow computations vs. photons.

Note how the rather highly reflective slabs fail to cast shadows, except where the photons target sphere enforces computation of shadow brightness to be done by the photons algorithm.

For more realistic shadowing without the need to enable photons, I suggest do add proper conserve_energy handling to the shadow computation code (which shouldn’t be too much effort).

global_settings {
  max_trace_level 10
  photons { spacing 0.003 media 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
  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 0.7 } }
}

#declare M_Glass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0
      specular 0.2 // just to give a hint where the sphere is
    }
  }
  interior { ior 1.0 }
}

#declare M_PseudoGlass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0.5
      specular 0.6
      roughness 0.005
      reflection { 0.3, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior { ior 1.5 }
}


sphere {
  <1.1,1,-1.3>, 1
  material { M_Glass }
  photons {
    target 1.0
    refraction on
    reflection on
  }
}

// behind target object
box {
  <-0.2,0,-2.3>, <0.0,4,0.3>
  material { M_PseudoGlass }
  rotate z*1 // just to better see the reflection of the horizon
}

// before target object
box {
  <2.4,0,-2.3>, <2.6,4,-0.3>
  material { M_PseudoGlass }
  photons { pass_through }
  rotate z*1 // just to better see the reflection of the horizon
}

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
}

The best time for a picture....

I set the day time and so the position of the sun by “clock=”

Normal I document my source very good, but this time,
I forgot the clock seting for the picture of my book cover.

So I would find it very practicall to put the clock value
and other setings for rendering
into EXIF data of the picture.

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

Here a part of the video.ini file

#

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.

With very fast renders and very large output files, the message queue can fill up because the producers are not limited by IO, while the consumer performance is limited by disk IO. Consequently, the message queue can fill up to exhaust all available memory. The solution is to build in some better control of pending output data in the message queue on the producer side. This will also pave the way for message communication over slow links (i.e. a network).

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.

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.

http://news.povray.org/povray.pov4.discussion.general/thread/%3Cweb.4799def8e1857b77c150d4c10%40news.povray.org%3E/

http://news.povray.org/povray.general/thread/%3Cweb.4fc892634f065c00e32b83540@news.povray.org%3E/

http://news.povray.org/povray.general/thread/%3Cweb.5073e9f7dae1fbb2d97ee2b90%40news.povray.org%3E/

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.

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.

In version 3.7.0.RC7.msvc10.win64, there is a bug in rendering Bézier patches in which four points (along one edge) are all the same point.

The rendering can be seen here:
http://i.imgur.com/eq2UIXR.png [Edit: See attachment for the rendering]

As you can see, there is a visible unwanted artifact in the corner of each patch. The two patches shown are essentially the same, except with the 4×4 matrix of vertices transposed (just to demonstrate that simply transposing it didn’t fix it).

Expected rendering is a smooth surface without the artifact.

Below is the code used to render the above example.

#version 3.7;

global_settings { assumed_gamma 1.0 }

camera {

  location <45, 31, -10>
  look_at <40, 21, 200>
  right x*image_width/image_height

}

light_source {

  <660, 300, -525>
  color rgb 1

}

Example 1: First point in each row is the same point
bicubic_patch {
type 1 flatness 0.001
u_steps 4 v_steps 4
<32.2168, -23.78125, 0>, <34.4968, -23.78125, 0>, <35.2168, -23.78125, -0.72>, <35.2168, -23.78125, -3>,
<32.2168, -23.78125, 0>, <34.4968, -22.10256, 0>, <35.2168, -21.57244, -0.72>, <35.2168, -21.57244, -3>,
<32.2168, -23.78125, 0>, <33.9709, -21.55577, 0>, <34.52483, -20.85299, -0.72>, <34.52483, -20.85299, -3>,
<32.2168, -23.78125, 0>, <32.30556, -21.50298, 0>, <32.33359, -20.78352, -0.72>, <32.33359, -20.78352, -3>
rotate 180*x scale 1.4
translate ←5, 0, 0>
pigment { color <1, 0, 0> }
} Example 2: First row is all the same point
bicubic_patch {

  type 1 flatness 0.001
  u_steps 4 v_steps 4
  <32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>, <32.2168, -23.78125, 0>,
  <34.4968, -23.78125, 0>, <34.4968, -22.10256, 0>, <33.9709, -21.55577, 0>, <32.30556, -21.50298, 0>,
  <35.2168, -23.78125, -0.72>, <35.2168, -21.57244, -0.72>, <34.52483, -20.85299, -0.72>, <32.33359, -20.78352, -0.72>,
  <35.2168, -23.78125, -3>, <35.2168, -21.57244, -3>, <34.52483, -20.85299, -3>, <32.33359, -20.78352, -3>
  rotate 180*x

  scale 1.4
  pigment { color <1, 1, 0> }

}

When rendering only a region of a file, using the command-line options +sc/+sr/+ec/+er, the area of the image that is excluded comes out as black in the final PNG.

Expected behaviour is for it to be transparent.

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.

Now the editor remembers only the cursor positions of the loaded files when starting a new PR session. It would be more friendly to remember whether the window was split or not, as well as the bookmarks.

When working with predefined materials, it would be useful to have something like:

#if (!Use_photons)
  #default { interior { caustics 1 } }
#end

#include "my_predefined_materials.inc"

Default medias or IORs could also be useful.

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

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.

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.

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.

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

When you instantiate an object several times, eg:

object { MyObj translate -x*10 }
object { MyObj translate x*10 }

POV-Ray will copy that object in memory, at least for most types of objects. Not for all of them, though. Most famously if MyObj is a mesh, it won’t be copied, but only a reference to the original will be used, thus saving memory. (There are a few other primitives which also don’t cause a copy, such as bicubic_patch and blob, but those are naturally not so popular as mesh, so it’s a less known fact.)

AFAIK the reason why referencing (rather than copying) is not used for all types of objects is rather complicated, and mostly related to how transformations are applied to these objects. For example if the object being instantiated is a union, the translates above will be (AFAIK) applied to the individual members of the union rather than to the union object itself.

Copying, however, can be quite detrimental in some situations. For example if you have a huge union, and you want to instantiate it many times, the memory usage will be that many times larger (compared to just one instance). This is sometimes something which the user would not want, even if it made the rendering slightly slower as a consequence. (In other words, better to be able to render the scene in the first place, rather than running out of memory.)

Redesigning POV-Ray so that all objects would be referenced rather than copied would probably be a huge job, and in some cases a questionable one. There probably are situations where the current method really produces faster rendering times, so redesigning POV-Ray so that it would always reference instead of copy, could make some scenes render slower.

So this got me thinking about an alternative approach: How hard would it be to create a special object which sole purpose is to act as a reference to another object, without copying it? This special reference object would act as any regular object, would have its own transformation matrix and all that data related to objects, but its sole purpose is to simply be a “wrapper” which references an existing object. It could be, for example, like this:

object_ref { MyObj translate -x*10 }
object_ref { MyObj translate x*10 }

The end result would be exactly identical as earlier, but the difference is that now MyObj behaves in the same way as a mesh (in the sense that it’s not instantiated twice, but only once, even though it appears twice in the scene), regardless of what MyObj is.

In some cases this might render slightly slower than the first version (because POV-Ray has to apply the transformations of the object_ref first, after which it applies whatever transformations are inside MyObj), but that’s not the point here. The point is to save memory if MyObj is large.

An object_ref would behave like any other object, so you could do things like:

#declare MyObjRef = object_ref { MyObj };

object { MyObjRef translate -x*10 }
object { MyObjRef translate x*10 }

(The only thing being instantiated (and copied) here is the “MyObjRef” object, not the object it’s referring to, so that actual object is still stored in memory only once.)

In some situations it might even be so that referenced objects actually render faster than if the objects were copied because references increase data locality, lessening cache misses.

I believe this could be a rather useful feature and should be seriously considered, unless there are some major obstacles in implementing it.

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.

Someone built a version of Povray with internal support for automatic subdivision of meshes. See:

http://www.cise.ufl.edu/~xwu/Pov-Sub/

Would like to see this feature added natively to Povray.

The so-called shadow line artifact (http://wiki.povray.org/content/Knowledgebase:The_Shadow_Line_Artifact) which affects objects with a ‘normal’ statement as well as smooth meshes and heightfields can be really annoying sometimes. Currently the only way to remove it is to make the object shadowless, which isn’t a good solution except in very special cases.

This algorithm could remove the artifact: If the actual normal vector of the object points away from the light source (its dot-product with the light vector is negative) but the perturbed normal points towards it (dot-product positive), then ignore the first shadow-test intersection with the object itself.

There are alternative ways of implementing an equivalent functionality:

- Don’t check the condition (if it’s too difficult to check due to how the code is designed) but always ignore the first intersection with the objects itself. This will work properly with closed surfaces but not with open ones, so it might need to be a feature for the user to turn on with a keyword (similar to eg. ‘double_illuminate’).

- Alternatively, don’t ignore the first intersection, but instead ignore the “opposite side” of the object’s surface (again, possibly only if a keyword has been specified). In other words, if we are rendering the outer side of the object, ignore its inner side when shadow-testing, and vice-versa.

- Perhaps simply add a feature to make surfaces one-sided (similarly to how they can be made so in OpenGL and similar scanline rendering systems). In other words, the inner side of a surface is completely ignored everywhere, making the object virtually invisible from the inside. The advantage of this feature would be that it can have uses other than simply removing the shadow line artifact.

While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.

In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).

solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.

I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).

These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].

This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.

The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).

As emerged as an idea during the discussion of FS#299, an SDL / POV-Ray editor feature would be useful that allows API documentation via formal comments, e.g. in include files:

/**
 * Creates a car object.
 * @param a
 *        description of param a
 * ...
 */
#macro car(a,b,c)
  ...
#end

In addition to the ability of (auto-)generating a documentation file from such comments, an editor window feature would be convenient that allows popup display of a macro’s (object’s / parameter’s / ...) documentation section.