POV-Ray

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

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

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.

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.

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.

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

“Hello " + “world!”

“Hello " . “world!”

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.

...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.

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.

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

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.

There can be square (32×32) blotches in partially transparent objects.

global_settings {
   max_trace_level 10
}

camera { 
   location <-30,10,5> 
   look_at <0,0,0> 
   angle 25 
}


light_source { 
   <-100,30,70> 
   rgb 1 
}

difference { // make a dome
  sphere { <0,0,0> 5 }  // ball
  sphere { <0,0,0> 4.9 } // hollow interior
  box { <-6,-6,-6> <6,1,6>  pigment { rgb <0,0,0> }}  // chop off bottom half
  pigment { rgbt <1,1,1,0.675> }
}

box { 
   <-6,-6,-6>, <6,0.99,6> 
   pigment { rgb <1,1,1> } 
   rotate <0,45,0>
} // sit it on a box

I’ve been trying to upgrade povray 3.6.1 to 3.7-beta-32. I’ve configured with no additional arguments, and the configure dies with:

checking whether to build the boost thread library from sources... no
checking for boostlib >= 1.35... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... no
checking for exit in -lboost_thread-boost_thread... no
configure: error: Could not link against boost_thread-boost_thread !

I figured that the problem was with my boost installation (1.35) and upgraded boost to 1.39; the problem remains. I tried to see if exit was defined in libboost_thread and/or libboost_thread-boost_thread and it isn’t. Just to be sure that my currrent setup works for the released version, I rebuilt/reninstalled 3.6.1, which went without problem.

I’m on a slackware-12.2 box, using gcc-4.4.0.

Some sample scenes are no longer up-to-date, causing warnings, and should be fixed. For instance, the advanced/benchmark scene still includes “Buffer_Output=Off” and “Buffer_Size=0” in its .ini file. This should be checked systematically, and fixed as appropriate.

When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.

For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:

1. scenes\textures\finishes\arches.pov
2. scenes\textures\normals\normavg.pov
3. scenes\textures\finishes\arches.pov (again!)

The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.

(see news://news.povray.org:119/4a983716@news.povray.org)

(This happens as of beta 34)

The following scene will cause POV-Ray to allocate memory until all available memory is used, resulting in an Out of Memory error message:

#declare n1 = normal
{
    crackle .5
    scale 0.001
    accuracy 0.0001
}

#declare n2 = normal
{
    bumps 0
}

camera
{
    location <0, 0.2, -1>
    look_at <0.4, 0.3, 1>

    focal_point <0.4, 0.3-.0, 1>
    blur_samples 25
    confidence .9
    variance 0
    aperture .05
}

light_source
{
    <-10, 10,-5>, rgb 1.5
    area_light x*2,y*2,7,7 orient adaptive 2
}

sphere{ <0, 0, 0>, 0.5 pigment {color rgbf <0.85,1,.95,1>}

    interior
    {
        ior 1.5
        fade_color rgb <0.0, 0.5, 0.0>
        fade_power 2
        fade_distance 10.5
        dispersion 1.1
        dispersion_samples 100
    }

    normal {

        checker normal{n2} normal{n1}
        scale 0.1
        warp { spherical }

    }

    translate z*1
} 

The configure script for unix uses a dumb string compare to test whether libpng version is 1.2.5 or higher, leading it to reject (for instance) libpng 1.2.27 and unnecessarily compile and statically link the older libpng version it comes with.

Windows 7, Home Premium 64bit
In Options/Editor Window/Editor Preferences/Language Tabs
saving a tab size of 4 does not work - on restart it reverts to the default of 8

In Options/Editor Window/Editor Preferences/Misc
saving a Line numbering style of Decimal and a Start number of 1, does not work, on restart the defaults are restored.

Hello,

when I use an image_map within a pigment_map (for example only a half of a box gets the image_map), the image_map is not rendered correctly.

For example when I have this box (scene and images are attached)

box {
	0, 1
	pigment {
		gradient z
		pigment_map {
			[0.4 image_map { png "test.png" } ]
			[0.4 color Cyan ]
		}
	}
}

So on the front you should see the image of test.png (in the attached scene it’s just red).
But on some pixels of the front you see the cyan color of the distant half of the cube.

Rendering the scene mutliple times produces the same result.

Rendering the scene at 200×150 is sufficiant.

povray +W200 +H150 scene.pov

I tested it with 3.6.1 and 3.7.0 beta 32 on Linux

Hi,

following scene will not be rendered correctly in 3.7.beta.35a:

http://lib.povray.org/collection/beamtest/cousin%20ricky%201.1/beamtest.html

maybe it is a configuration problem or it is a real bug.

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”.

When I try to re-render the insert menu bitmaps,on the Windows version 3.7b36 there is an error with the
Shapes.pov file.
line 474: Parse Error: Unexpected additional ‘.’ in floating-point number

line 474 is:

<2.6, 0>, <3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>

The second vector has two decimal points
Change to <3.6,.9>

In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:

3997    case KEYWORD_LOOKUP_MESSAGE :
3998         hh_aklink.pszKeywords = (LPCSTR) lParam ;

3999         if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000           hh_aklink.pszKeywords = ""  ;
4001         if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002           hh_aklink.pszKeywords = ""  ;

4003         if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004           hh_aklink.pszKeywords = ""  ;
4005         if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006           hh_aklink.pszKeywords = ""  ;

4007         HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008         return (true) ;

This duplication appears pretty much useless to me - or am I missing something?

The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.

Macros are finicky about how you type your code. What works outside macros sometimes fails inside them. For more information see the threads:

“Problems with macro (3.6)”, in p.a-u, 06-09-10
“Bad operands”, in p.g, 05-20-10

Still not sure *what* exactly the problem was, but one of my workarounds ended up working.

In POV 3.6 you could set the Statistic_File option to a custom file and folder path. In the beta I get an “Cannot open file” error. Has the feature been intentionally removed or did it become broken?

clipka anonymous@anonymous.org wrote:
> Am 29.06.2010 04:27, schrieb jberry02:
>
> > First, note that this is the Windows version.
> > Second the issue is not with opening the ini file, but with opening the scene
> > file from within the ini file.
> >
> > I have a scene.ini file, that has a line:
> >
> > Input_File_Name=scene
> >
> > under POV-Ray 3.5 *and* POV-Ray 3.6, the scene defined in the file scene.pov is
> > rendered properly using the parameters specified in the scene.ini file. The ini
> > file is opened from the POV-Ray GUI, and run using the “Run” button.
> >
> > under POV-Ray 3.7, I get an error - I originally thought that it was simply not
> > looking for scene.pov (i.e., it wasn’t adding the .pov extension when trying to
> > open the scene file), but looking closer the error is *actually*:
> >
> > Input file ‘C:\[...]\scene’ not found; cannot determine I/O permission for
> > write.
> > Failed to start render: Cannot open file.
> >
> > In other words, it appears that the problem is that it isn’t adding the default
> > ..pov extension when it is trying to do the I/O permission check. I do not have
> > any special I/O permisssions configured for any version of POV-Ray (I get the
> > pop-up dialogs), and this is a change in behavior from 3.6 to the current beta
> > of 3.7. The scene.pov file is not in any of the POV-Ray directories - it is in
> > a separate tree where I keep my scene files.
>
> Having looked at it in a debugger, I can confirm that there is a
> problem, and that you don’t seem to be far off the mark:
>
> The error occurs when POV-Ray tries to determine the I/O permissions for
> the /output/ file. If that isn’t explicitly specified with a path,
> POV-Ray will try to get the path from the input file; however, it will
> take the unprocessed parameter (in the sample case “scene”) rather than
> the file name POV-Ray makes of it (”scene.pov”), and then attempts to
> get the full /long/ path name of the file (remember the good old 8.3
> filenames for compatibility with 16-bit programs?), which only works
> when the file exists.
>
> Would you mind submitting a bug report to <http://bugs.povray.org>?

Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.

Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.

Please fix ?

Test bug for checking features of flyspray.