Being able to have functions operate on vectors would be pretty nice to have.

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.

Background

Possible solution

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

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

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

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.

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.

Currently, arrays are of a fixed size. You can’t add or remove items to/from an array. I think it would like arrays to be expandable with no fixed and pre-determined size.

See Notepad++ or EditPad Lite for examples.

It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.

Would be great if there were a “Rename” option in the editor File menu to rename the current file name. Otherwise, you have to close the file, rename it in file manager, then open the file again, thus loosing the current tab position and undo history for the file.

Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.

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.