POV-Ray

Beta 32, compiled from source on Linux/Ubuntu, amd64.

The random “window display lock” is back.
(as the previous “solution” was to get no window display usable, that’s not so bad).

What is it: sometime, when the rendering window is activated, povray just draw the frame
of the window, paint it black, does not display anything else but seems to perform the
rendering in separate threads. Whenever the mouse move over the frame of the window, it
unlock the updating process and big parts of the rendered image pop up.

What it is not fine: if you do not move the mouse over the window, povray will just stall.
This is more a problem for animation rendering, as getting the display might be a wanted
bonus to monitor the rendering images, and you just fall into that lock: your expected
night rendering could very well be suspended on the first frame.
Moreover, the “move the mouse over” works only for local display. In previous beta (not
yet checked with 32), with a remote display, there was no way to unlock povray.

Windows allows you to associate programs with file extensions using the “Open with” file manager right-click menu extension.

I’m running Windows 7 64bit, and installed the 64 bit versions of 3.6.2 and the beta appropriately.

A couple of problems that I haven’t tested very thoroughly:

1. If you have both POV 3.6.2 and the beta installed at the same time, you can no longer using this dialog change the association to the beta once it has been created for 3.6.2. There’s no error or anything; it just opens the file inside 3.6.2 instead. Maybe because both versions appear as “POV-Ray for Windows” to this dialog? Would adding the version number to the name fix things? Anything I can do on my end of things to resolve this?

2. In POV-Ray 3.6.2, I can use this dialog to open *.inc, *.txt and other files in POV-Ray, but only if POV-Ray isn’t already running. If POV-Ray is already running I get an “Only /EDIT and /RENDER may be passed to previous instance” error. Files with the *.pov extension open properly regardless, without any error. I am unable to test this in the beta at the moment due to the first problem unfortunately. Could someone please test this with the beta and confirm whether the behavior also exists?

3. With the POV-Ray 3.7 beta, entering the following command in the command prompt results in the same error:

   "C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"

If I change it to the following it works however:

   "C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" /EDIT "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"

Is this error/behavior really necessary? Would it be OK to instead change the behavior when the /EDIT flag is omitted in the
command-line such that the file is opened in the editor by default, without throwing an error?

Array.inc and subsurface.pov are in read only mode, they probably should have normal permissions.

While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:

1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe)
2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable.
3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix).
4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3.
5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is
#ifdef HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
but this also needs a check in the configure script.

Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html.
Backtrace is
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004ac479 in boost::gregorian::date::date ()
(gdb) bt
#0 0x00000000004ac479 in boost::gregorian::date::date ()
#1 0x00000000004d29f7 in boost::gregorian::date::date ()
#2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName ()
#6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName ()
#7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName ()
#8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= ()
#9 0x00007f7ffd80d9cf in thread_proxy ()

from /usr/pkg/lib/libboost_thread.so.1.45.0

#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>)
at /archive/cvs/src/lib/libpthread/pthread.c:473
#11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12

Please advise on how to proceed.

source/png_pov.cpp included in povray-3.6.1 contains calls to an internal function of libpng (png_write_finish_row) which was removed from the public interface quite a while ago, so linking fails.

Also, in the 1.4 releases of libpng, the info_struct “trans” member was renamed to trans_alpha. This causes a compilation error in the same file.

A suggestion for the solution:
a) remove the png_write_finish_row prototype and function call
b) add something like:
#if PNG_LIBPNG_VER < 10400
#define trans_alpha trans
#endif
and change
cmap[index].Transmit = 255 - r_info_ptr→trans[index];
to
cmap[index].Transmit = 255 - r_info_ptr→trans_alpha[index];
(two occurrences).

There are a number of problems with the Windows version of POV-Ray under Windows Vista. To resolve these, the setup program needs to be re-written and the location of internal files changed.

Originally resolved in https://bugs.gentoo.org/show_bug.cgi?id=425450.
Attached is a patch with Gentoo-specific code removed.

There are two parts in this issue:

• The newer boost library requires downstream users to explicitly link to the boost system library (-lboost_system).
• The newer boost library replaced TIME_UTC with TIME_UTC_, because glibc added TIME_UTC.

The Rect data type needs to be renamed to avoid a clash with a Mac OSX declaration. It was originally called Rectangle, but this clashed with a Windows declaration. Something more POV-specific should be used, e.g. PovRect.

20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.

Keyword Completion does not work for several names.
I miss it for animation related names like frame_number or final_frame.

Typing “fram{TAB}” just inserts a TAB character after “fram” instead of completing it to frame_number.

Independently of that bug, typing {TAB} repeatedly does not cycle through possible names:
“fr{TAB}” gives “frequency” and “fresnel” and that’s all.

In version 3.6 it worked well.

My system is Windows 7 64bit and PovRay is 3.7.0.RC3.msvc9.win64

REcently I installed POV-Ray tracing software in my mac OS X version 10.6.8. When I run the software its displaying a fatal error occured and the error number is -43. I’m new to POV-Ray...pls help me guys...

The documentation assumes that INI files (as well as the command line!) are parsed and processed instantly. This no longer holds true for POV-Ray 3.7, where parsing INI files (and the command line) and processing it are separate operations that occur at different times. As such, one consequence is that INI file options only take effect after reading the whole INI file, and possibly later.

As such, documentation statements such as <http://www.povray.org/documentation/view/3.6.1/222/>
“Note: that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read will not be affected.”

Are no longer correct. It needs to be explained that options only take effect after the INI file has been read. An error in the INi file causes other options _not_ to take effect because reading of the INi file is aborted prematurely.

The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a.
In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.

In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.

This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.

Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.

Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.

Reported for freebsd 7.2 (current production version, true for previous version, unknown for 8.0 in beta now)

freebsd does not provide CLOCK_PROCESS_CPUTIME_ID
(even if CLOCK... is posix).

As a consequence, compilation of the unix-source is currently not possible for freebsd target.

Might be a simple selection for Change 4356 ?
(assuming a relevant test in ./configure)
(getrusage() seems available on freebsd, but does it provide the pieces of information needed, I do not know that code good enough to assert that)

Scenes starting with the incorrect syntax

version 3.7;

do not raise an error, instead they render a black screen with an empty scene warning.
#version should fail with an error when the # is missing.

In vfe/unix/unixoptions.cpp, -V is defined as a synonym for -​-version, overriding its general meaning of Verbose=off.

‘povray -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays

Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)

instead of

Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)

or

Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10) 

I cannot edit any pages on wiki.povray.org, even after confirming my e-mail address.

This means that I cannot add any documentation, help improve the documentation, fix errors or help in any other way.

If you want contributions to the documentation, you should let users edit pages.

in change #3319, csg got a new computation for its weighted textures.

But I’m confused by the computation of the weight: (circa end of csg.cpp file)

COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);

I would have used a max() rather than a min().

It is transparent when there is only one texture, but:

• should there be no texture (an error...): it would be a division by 0
• should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n

Or did I get a confusion about min() ?

min(0,1) == 0
min(4,1) == 1

Using max would protect against the division by 0 and the right value when multiple textures are used.

Any thought ?

Include file golds.inc still provides warnings when parsed, a shame for a standard include file.
(colors.inc is ok, I did not test the other includes)

File '/usr/local/share/povray-3.7/include/golds.inc' line 118: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 119: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 129: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 130: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 140: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 141: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 151: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 152: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 162: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 163: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.

UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.

In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.

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

light_source { <-30, 30, -30> color rgb 1 }

#declare Param = parametric {
  function { u*v*sin (15*v) },
  function { v },
  function { u*v*cos (15*v) }
  0, 1
  contained_by { box { -1,1 } }
  accuracy 0.002
  precompute 15 x,y,z
  rotate 180*x
  translate  <0.3,0.5,0>
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 3
      color_map {
        [0 color red .5 ]
        [1 color red 1 ]
      }
    }
  }
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 7
      color_map {
        [0 color green .5 ]
        [1 color green 1 ]
      }
    }
  }
  rotate y*180
}

POV-Ray 3.62 renders the scene properly.

As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.

POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.

According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.

Using interpolated image_maps in functions results in pixel-sized dot-artifacts when using the functions back into pigments.

This problem doesn’t shows using the same code on POV-Ray 3.6.

I qualified it as “low severity” because is not going to happen to most users: it will show only when using some advances techniques, for example when you want to decompose an image_map into the RGB components, perform operations, and mixing them back with an averaged pigment (example attached).

#macro A()
  #local foo = function { x }
  foo
#end

#local bar = A();

This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.

After some debugging I think this is what happens.

In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.

So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:

    Temp_Data  = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);

if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.

A similar problem occurs when foo is a spline.

A tentative patch for the function case is attached.

unixoptions.cpp has a getenv(”HOME”) that does an assignment without checking to see if getenv returns NULL.

This causes an immediate and unceremonious segfault in those situations where $HOME is not set such as in the case where povray is launched by a daemon.

Best solution might be to set the home to /tmp and print a warning message about $HOME not being set.

In unix distribution these scripts

• allscene.sh
• allanim.sh
• porfolio.sh

have the variable VERSION set to 3.6

I’ve tried to model this setup:
http://kschwebke.webng.com/povray/ior-interfaces/drawing.png with the following SDL:
http://kschwebke.webng.com/povray/ior-interfaces/rs2.pov.txt

A small overlap between the two transparent solids is needed, because a gap
would lead to total reflection. The camera in the test scene looks in the
direction of the ray in the setup drawing. The setup is surrounded with angular
markers, so one can easily read the final resulting looking angle.

POV-Ray 3.6.1 renders the expected result (~53° in the center of the screen):
http://kschwebke.webng.com/povray/ior-interfaces/rs2-35.jpeg

POV-Ray 3.7.0b35a (compiled Unix source) renders a different
(and in my opinion wrong) angle (~67°), however – for the very same scene file:
http://kschwebke.webng.com/povray/ior-interfaces/rs2-37b35a.jpeg

I’ve started a discussion about this issue in povray.beta-test: http://news.povray.org/povray.beta-test/thread/%3Cweb.4bba4677730ab9f3e8c084b40%40news.povray.org%3E/

All linked documents are also attached.

The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:

light_source {
    <0, 0, 0>
    color rgb 0.5*<1,0.905882,0.211765>
    fade_distance 500
    fade_power 1.6
    looks_like {_3024_dot_dat texture {
        pigment { rgbf <1,0.905882,0.211765,0.90> }
        finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
            reflection 0.9
            refraction 1 ior 1.25
            }
        }
}    } 

can not run POV-Ray on ubuntu 14.04, boost 1.54,

./configure COMPILED_BY=”Dmitry <my>”

...

Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for boostlib >= 1.37... yes
checking whether the Boost::Thread library is available... yes
checking whether the boost thread library is usable... no
configure: error: in `/home/di/workspace2/povray-3.7-stable':
configure: error: cannot link with the boost thread library

log in attach file

.../scenes/objects/fractal2.pov

in global_settings  "max_trace" should be "max_trace_level"

.../scenes/advanced/diffuse_back.pov

in global_settings  assumed_gamma statement should not be followed by a semicolon

.../scenes/advanced/blocks/stackernight.pov

in global_settings  "assummed_gamma" should be spelled "assumed_gamma"

.../scenes/portfolio/*.pov

in all files other than _empty.pov the parse stops at the lines containing "[frame_number-1]" I'm guessing it should be "[frame_number]-1"  

Height=36084

[640×360, AA 0.3]
Width=640
Height=36084
Antialias=On
Antialias_Threshold=0.3

should be:

[640×360, AA 0.3]
Width=640
Height=360
Antialias=On
Antialias_Threshold=0.3

When using the ‘background’ directive with a transparent color, for example:

  background { color rgbt <0, 0, 0, 1> }

the final image is still opaque (both the one displayed in the render window and the PNG actually saved to disk).

Expected behaviour is for it to be transparent.

The following scene reders differently with POV-Ray 3.7.0.RC3 than with POV-Ray 3.6.2:

camera
{
    right x*image_width/image_height
    location  <0, 0, -5>
    look_at   <0, 0, 0>
}

light_source
{
    <0,0,0>
    color rgb 1
    looks_like
    {
        box {
            <-1,-1,-0.1>, <1,1,0.1>
            pigment { wood }
            finish { ambient 5.0 diffuse 0 specular 0 phong 0 reflection 0 }
            scale 0.5
        }
    }
    translate <1,0,0>
}

plane
{
    <0, 1, 0>, -1
    texture
    {
        pigment { color rgb <0.5, 0.5, 0.55> }
        finish { specular 1.0 }
    }
}

See attachments for the output. As can be seen, POV-Ray 3.7 does translate the shape of the looks_like object along with the light source, but fails to translate the textures.

If pretrace_start is set below pretrace_end, POV-Ray will run a high number of pretrace steps (without changing pretrace resolution).

The parser is failing to read the .tiff file extension from the input string...

bump_map { tiff "earth03_hf2.tiff" }

Results in file not found, but

bump_map { tiff "earth03_hf2" }

will find the file. It might be that it’s not a three character extension?

Thread safety issue in functions using splines. 3.7.0.RC7.

First vetting in p.bugreports where several users were able to reproduce the fail on the following systems:

1) Ubuntu 12.1 i7 920 using 3.7.0.RC7
2) Ubuntu 12.04, AMD 2431 CPU, Linux 3.2.0-45 kernel using 3.7.0.RC7 (g++ 4.6 @x86_64-unknown-linux-gnu)
3) POV-Ray 3.7.0.RC7 (icpc 13.1.0 @x86_64-unknown-linux-gnu)

 Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz

 uname -or
 2.6.32-279.14.1.el6.x86_64 GNU/Linux

 lsb_release -irc
 Distributor ID: CentOS
 Release:        6.3
 Codename:       Final

4) Confirmed with openSUSE 12.2.
5) Just to add to the system list: with Windows and a core i7 one yields the same result.
6) “Le_Forgeron” ran under Intel Inspector (XE 2013) and provided this feedback :

 ...
  that might be less than 60 seconds, but with Intel Inspector (XE 2013),
 it becomes 42:50 (just 14 data races, oh well, that's just so friendly).

 ID  Type Sources Modules State
 P1  Data race isosurf.cpp; mutex.hpp povray New
 P2  Data race mutex.hpp; povms.cpp povray New
 P3  Data race povray.cpp povray New
 P4  Data race povray.cpp povray New
 P5  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P6  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P7  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P8  Data race recursive_mutex.hpp; scene.cpp; task.cpp; taskqueue.cpp;
 view.cpp povray New
 P9  Data race condition_variable.hpp; vfe.cpp; vfesession.cpp povray New
 P10  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P11  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P12  Data race unixconsole.cpp; vfesession.cpp; vfesession.h povray New
 P13  Data race unixconsole.cpp; vfesession.cpp povray New
 P14  Data race [Unknown]; unixconsole.cpp; vfesession.cpp
 libboost_thread.so.1.49.0; povray New

 Numbers 2, 3, 4, 8, 9, 10, 11, 12, 13 & 14 are related to the handling
 of session (and occur once or twice only, excepted #8, four times).

 Number 1 is about isosurface (adjusting gradient at isosurf.cpp:1099 vs
 1098 (testing its value), and copying the isosurface) (IMHO, rendering
 threads updating the object... not the best move without some
 atomic/protection (and not sure a DBL is/can be atomic)) (occurs 2505
 times).

 Number 5, 6 and 7 are about splines
 * sp->Cache_Type & Cache_Point, splines.cpp :803 vs :814/815 (2024 times)
 * sp->Cache_Valid, :805 vs :813 vs :904 (1770 times)
 * sp->Cache_Data, :807 vs :903 (5025 times)

 Only my 0.02¢ (yes, very cheap), but it seems to confirm

For test code see attached files or SplineThreadSafety.pov attachment to
p.bugreports and images were posted to p.b.images.

Issue shows up any time more than one thread is used. Use of AA tends to hide
the problem so do not use it if using the output image for testing.

Thanks.
Bill P.

From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)

William F Pokorny anonymous@anonymous.org wrote:
> It seems to be the case the gradient warnings are only generated if the
> isosurface is naked. If it is wrapped in an object as was the case with
> my thread safety example, we get no warnings.

Confirmed. If only I still had the concentration required to investigate
computer code.

#version 3.7;

#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end

global_settings
{ assumed_gamma 1
  radiosity {} //force isosurface calculations from all directions
}

light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }

camera
{ location <0.0000, 1.0000, -5.6713>
  look_at <-0.7969, 1.2000, -0.0598>
  angle 10.7447
}

#include "functions.inc"

#if (Naked)
  isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
#else
  #declare Test = isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
  object { Test }
#end

On the command line, try:

declare=MG=1 declare=Naked=1

and

declare=MG=1 declare=Naked=0

To lose the warning, I had to declare the isosurface. Just wrapping the naked
isosurface in an object{} generated a warning.

Further analysis

if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))

The +GD flag gives me an “Invalid parameter” error, whether on the command line or in a .ini file.

Debug_File= still works.

I reported this in povray.beta-test, but did not receive a response.

The problem occurs in both Windows 7 and in Linux.

As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.

With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.

I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.

Best regards,
Michael

This item may need to be merged with item FS#81. This is another sphere sweep bug, though they are of different spline types.

The code is

#include "colors.inc"

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

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}


#declare i_start = 0;
#declare i_stop = 3;
#declare i_step = 0.05;
#declare i_inc = i_start;
sphere_sweep {
  linear_spline                 // linear curve

  (i_stop - i_start)/i_step + 1,    // number of specified sphere positions
#while(i_inc<=i_stop)
  
  #declare y_coor = 0.23*sin(7.1*i_inc);
  <i_inc, y_coor, 0>, 0.05
        #declare i_inc = i_inc + i_step;
 
        
#end

pigment{color Orange}

}

When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe 
-I../../vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp

g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test 
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp

This is especially annoying on platforms that are rather slow at compiling.

Hopefully platform specific, other ports are welcome to check their scaling code.

Reported originally in p.beta-test (28 january 2012) by Cousin Ricky (email dropped)

Symptom: crash on start of second frame rendering
Environment: Unix, with display of rendered picture, rendered picture does not fit at 1:1 on the display

Demo (adjust the H/W to your setting to get them larger, both or any of them):

global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }

povray +H2000 +W2000 +KI0 +KF1 +KFI0 +KFF10 code.pov

The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.

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

Although it works in version 3.6, only in 3.7 does a render time error ocurr.

Scene source should be adjusted to the following

  <3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,

When aborting a render when there are unfinished blocks among finished ones, under certain conditions some of those blocks are skipped when continuing the render later.

Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.

Reflective texture maps can cause a stack overflow crash.

sphere{0,1
  texture{
   bozo
   texture_map{
    [0 pigment{rgb 0}]
    [1 pigment{rgb 0} finish{reflection 1}]
   }
  }
}