POV-Ray

Currently, many POV scenes/include files behave differently depending on the basic units used within the scene. Scaling them differently can affect things like ior and media. A master system variable that users can set to configure the scene’s units would be beneficial for sharing and collaboration purposes, so that person A’s glass interior works correctly in person B’s wine glass scene. Just like the #version system variable, it should have a default value but should be possible to explicitly override.

Input image files may have been created with gamma pre-correction for some specific target gamma, which may vary from image to image. Some file formats like PNG or HDR support embedding gamma pre-correction information in the image file, but this information may be missing or faulty, and some formats don’t support it at all. Additionally, it may be desirable to tamper with an input image’s gamma for artistic reasons.

Therefore, I suggest adding a means to explicitly specify input images’ originally intended target gamma on a per-image basis, like:

image_map { jpeg "MyImage.jpg" assumed_gamma 1.8 }

If you abort a render with ^C, Povray exits with a ‘success’ error code.

To test:

povray scene.ini
(^C to abort it)
echo $?

Right now 0 is returned (’success’). A non-zero value should be returned (’failure’).

This is particularly important for scripting, where command lines like:

povray scene.ini && halt

...can be used. I only want the halt to be executed if the scene renders successfully. If I change my mind and ^C it, I don’t want the machine to shut down!

I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.

In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.

I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)

Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).

Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.

To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.

Adding an AOI pattern is asked for fairly frequently.

The commands:

povray +i /home/ronis/Nm=500/povray.00001.pov

or

povray +i/home/ronis/Nm=500/povray.00001.pov

fail with: povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and 1 hour(s)
Failed to parse command-line option

Going to the directory and simply running: povray +i povray.00001.pov
works.

I came across this by accident trying to get emac’s povray mode to work; apparently it passes the full path name to povray.

I don’t think there is a problem in 3.6.1

Add a way to get and set font metrics.

Attached an image that shows what I’m talking about.

Thanks!!

Improve native support for 2D primitives. Ideally a 1:1 mapping of SVG primitives/shapes. They go a long way to making diagrams look a lot better. Having to create image maps based on externally created bitmaps slows the workflow down a lot!

Add metatags to output images identifying the file as having been created using POV-Ray.

In POV-Ray 3.6 (including 3.62), checker and cells patterns are off by 0.001 (1e-3) units, as can be demonstrated with this scene:

camera {
  location  <0.0, 0.0, -5.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}

box { <-1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate <-0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate < 0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate < 0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { <-1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate <-0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }

The same can be demonstrated for the cells pattern.

POV-Ray 3.7 beta 34 is “clean”.

woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1

There should be a table of contents on each page of the documentation, or at least on the very long pages. Scrolling through the entire page to figure out what topics are covered sucks.

Assuming there are no performance issues, it would be nice to tell Povray to select the pixels to render randomly, so that the image gets filled in gradually instead of from top to bottom and from left to right.

Also, maybe an option to tell it to render every Nth pixel.

Request an #ELSEIF statement in POV SDL.

Request #BREAK statement inside #WHILE and #FOR loops.

In POV SDL it can sometimes be ambiguous what exactly a macro returns. An explicit #RETURNS statement would make this unambiguous.

Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.

There are various scripts around the Net meant for approximating things like isosurfaces and parametric objects using meshes. It would probably run bit faster and be easier to use if this were supported natively within Povray. The feature would require an additional object parameter in order to toggle this behavior on/off.

It would be nice to configure an INI option to add render information like render time, date, and input file to output images.

When right-clicking on a tab in the editor window a list of options should appear, such as:

* Close
* Close all but this
* Save
* Save as
* Print

See Notepad++, EditPad Lite, and Firefox for examples.

There already exist atan, atan2 and atan2d functions, why not atand?

Would be nice to have a “Delete” option in the File menu to delete the current file from disk.

The ability to specify an exact name for output images during animations would be great. As it is, POV-Ray appends a numerical designation to each image (e.g. image001.png, image002.png, etc. Overriding this behavior would allow certain tasks to be accomplished without cluttering the hard drive. For instance, an image could be rendered over and over again. Certain things like cellular automata, ripple tank simulations and feedback fractals could be performed without the resulting long list of images in a given directory.

The command line option could be in the form of +oefile/+Output_File_Name_Exact=file or some such.

The documentation entries for shapes.inc, shapes_old.inc, shapes2.inc, shapesq.inc, etc. should have thumbnails next to the object descriptions.

In the tray icon, I’d like to see the render progress indicated somehow icon itself. Either a set of numbers (percents), or a change in color of the icon (e.g. from top to bottom). Something like the attached images.

Currently, cameras placed inside object or union statements will halt the render with an error. Take for instance the following case:

#local temp_camera_1 = camera
{
  orthographic
  location  z*-12
  direction  z
  up    y
  right    x*image_width/image_height
  scale    32
}

#local temp_light_1 = light_source
{
  0
  color rgb 1
  translate <-30, 30, -30>
}

#local temp_light_2 = light_source
{
  0
  color rgb 1
  translate <-30, 30, +30>
}

union
{
  object {temp_light_1}
  object {temp_light_2}
//  camera {temp_camera_1}  // doesn't work!!!
}

//object {temp_camera_1}  // doesn't work!!!
camera {temp_camera_1}  // works!!!

Changing this behavior would make it possible to more easily apply transformations to scene objects and the camera at the same time in situations where the scene’s frame of reference is in motion relative to the rest of the scene, for instance in animations.

I’d like to request the ability to create a date/time stamp on output images so that new renders don’t always overwrite old ones. Thanks.

In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.

I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.

Tested with beta 40. Also affect version 3.6.1 as reported in the discution group.

When using radiosity and emissive media. Any object, or part of, that is inside the media container is not affected by the illumination comming from the media.

When using scattering media, the light scattered by the media also don’t affect objects that are inside it’s container.

http://news.povray.org/povray.newusers/thread/%3C4cf8fe22%241%40news.povray.org%3E/

At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.

When POV-Ray 3.70 is run on a terminal, on an unix shell, and the user hits ctrl-Z to suspend (stop) POV-Ray, rather than stopping as expected, POV-Ray just reports that it did receive the signal, as if to laugh at the user “I’m not obeying your puny stop attempts”. It

The default action (as happens if the SIGTSTP signal is not trapped) would be much better, and is usually safe also in multithread programs.
It takes actual effort to _ignore_ the TSTP signal (namely, to trap that signal), so the current behavior is definitely a dysfeature, probably an oversight by whoever programmed the signal handler.

Also, when the terminal window is resized, POV-Ray needlessly reports that it received a signal number so-and-so (the number of SIGWINCH), adding irrelevant noise to its terminal output. Both signals (SIGTSTP and SIGWINCH) should simply be excluded from the signal trapping mask. I guess there are also other signals that are needlessly captured. It would be better to capture only those signals that an action is needed for.

couple of observations:

if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)

when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.

It would be nice when quitting a render if the remaining space were filled with empty pixels. That way the partial render will still be viewable in all image apps.

For the next beta version, could you please create a new desktop icon? I keep clicking on the wrong version.

There is a long animation to render.

computer 1 should render 0..799
computer 2 should render 800..1599

And after this, You have a bad surprise with the filenames.

animation799.png
animation0800.png

There should be a seting how many digits a file name in an animation should have.

This avoids, that there are series of pictures with 3 and other with 4 digit filenames.

BTW: All the experiences for this feature requests had been made during producing
http://roland.pege.org/2011-gusi-peace-prize/calculation-error.htm

Suggestion:

In file screen.inc, have macro Screen_Object() set no_radiosity on the object.

There are times when scaling an entire scene up or down is difficult or just not feasible.

One suggestion is a global_settings option.

Also, I’ve noticed that in some situations, such as interactions between certain transparent objects, the epsilon seems to kick in quite early. Perhaps there could be situational or contextual epsilons, such as the “tolerance” of sphere_sweep or the “accuracy” of isosurface.

Blobs are currently limited to 1,000,000 components (with each cylindrical component counting as three: one cylinder + two end hemispheres); this limit may have served a historic purpose, but is now entirely arbitrary: The remaining code is limited only by the available RAM and the numeric limits of the int data type. The arbitrary maximum components limit per blob should therefore be removed.

Aside from unnecessarily limiting the power of the blob component, another drawback of the current test is that it is only performed after parsing of all the blob’s components, potentially hours after the limit had actually been reached.

On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.

Here is an example of Chrome downloading something and showing the progress in the taskbar:

http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg

Here is an example with Paint.NET instead:

http://www.getpaint.net/images/pdn351_superbarProgress.png

I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.

For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.

Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.

The only remaining question would be the syntax.

IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:

#for(<identifier name>, <initial value>, <final value> [, <step>])
  <loop body>
#end

Example:

#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
  #debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
  #debug concat(str(Counter, 0, 0), "\n")
#end

I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).

Of course this raises a couple of questions:

1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:

• The ‘Counter’ in the for-loop replaces the previous identifier, as a regular #local command would.

• The ‘Counter’ in the for-loop hides the identifier for the duration of the loop, and unhides it afterwards.

• A syntax error is given (ie. the identifier name must be unused).

2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:

// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
  #debug concat(str(Counter, 0, 0), "\n")
  #if(Counter = 3) #local Counter = 8; #end
#end

Alternatively the counter variable could be read-only.

Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).

Many programming languages support an indeterminate number of parameters in functions/macros.

JavaScript for instance supports an “arguments” object.

Lua for instance supports the “args” object.

I would like to see that added to POV as well.

Here’s an JavaScript example:

function ArgTest(a, b){
   var i, s = "The ArgTest function expected ";
   var numargs = arguments.length;     //Get number of arguments passed.
   var expargs = ArgTest.length;       //Get number of arguments expected.
   if (expargs < 2)
      s += expargs + " argument. ";
   else
      s += expargs + " arguments. ";
   if (numargs < 2)
      s += numargs + " was passed.";
   else
      s += numargs + " were passed.";
   s += "\n\n"
   for (i =0 ; i < numargs; i++){      //Get argument contents.
   s += "  Arg " + i + " = " + arguments[i] + "\n";
   }
   return(s);                          //Return list of arguments.
}

Request a system variable to test whether a scene file has been included by another scene file.

For instance:

#if (is_included)
  camera {...}
#end

Using the concat function is tedious. Why not just have an operator with which to concatenate strings?

“Hello " + “world!”

“Hello " . “world!”

...for instance nVidia’s CUDA architecture, discussed here and other places.

General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.