When building POV-Ray 3.7-stable, at the step ./configure, I have the following error :

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/seipas/Téléchargements/povray-3.7-stable':
configure: error: cannot link with the boost thread library

config.log :

configure:7100: checking whether pthreads work with -pthread
configure:7183: gcc -o conftest  -pthread   conftest.c   >&5
conftest.c: In function 'main':
conftest.c:33:22: warning: null argument where non-null required (argument 1) [-Wnonnull]
                      pthread_attr_init(0); pthread_cleanup_push(0, 0);
                      ^
conftest.c:34:22: warning: null argument where non-null required (argument 1) [-Wnonnull]
                      pthread_create(0,0,0,0); pthread_cleanup_pop(0);
                      ^
conftest.c:34:22: warning: null argument where non-null required (argument 3) [-Wnonnull]
configure:7183: $? = 0
configure:7192: result: yes
configure:7211: checking for joinable pthread attribute
configure:7226: gcc -o conftest  -pthread   conftest.c   >&5
configure:7226: $? = 0
configure:7232: result: PTHREAD_CREATE_JOINABLE
configure:7242: checking if more special flags are required for pthreads
configure:7249: result: no
configure:7384: checking for boostlib >= 1.37
configure:7438: g++ -c  -pthread  -I/usr/include conftest.cpp >&5
configure:7438: $? = 0
configure:7440: result: yes
configure:7606: checking whether the Boost::Thread library is available
configure:7638: g++ -c -pthread  -pthread  -I/usr/include conftest.cpp >&5
configure:7638: $? = 0
configure:7653: result: yes
configure:7849: checking whether the boost thread library is usable
configure:7869: g++ -o conftest  -pthread  -pthread -I/usr/include  -L/usr/lib conftest.cpp   -pthread  >&5
/tmp/ccFv4p8p.o: In function `__static_initialization_and_destruction_0(int, int)':
conftest.cpp:(.text+0x4f): undefined reference to `boost::system::generic_category()'
conftest.cpp:(.text+0x5b): undefined reference to `boost::system::generic_category()'
conftest.cpp:(.text+0x67): undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status
configure:7869: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "POV-Ray"
| #define PACKAGE_TARNAME "povray"
| #define PACKAGE_VERSION "3.7.0"
| #define PACKAGE_STRING "POV-Ray 3.7.0"
| #define PACKAGE_BUGREPORT "[email protected]"
| #define PACKAGE_URL ""
| #define VERSION_BASE "3.7"
| #define DISTRIBUTION_MESSAGE_2 " Seipas Alawalichu <seipas@alawalichu>

I have Linux Mint 17.3. sudo apt-cache showpkg libboost-dev gives : 1.54.0.1ubuntu1

The build starts and it stops in some seconds:

In file included from ./core/coretypes.h:45:0,
from ./backend/frame.h:63,
from ./backend/vm/fnpovfpu.h:47,
from ./parser/fncode.h:44,
from parser/fncode.cpp:46:
./core/math/vector.h: In function ‘double (* pov::Create_Vector_4D())[4]’:
./core/math/vector.h:75:83: error: ‘POV_MALLOC’ was not declared in this scope
New = reinterpret_cast<VECTOR_4D *>(POV_MALLOC(sizeof (VECTOR_4D), "4d vector"));
^
./core/math/vector.h: In function ‘void pov::Destroy_Vector_4D(double ()[4])’:
./core/math/vector.h:96:19: error: ‘POV_FREE’ was not declared in this scope
POV_FREE(x);
^
make[2]: ** [parser/fncode.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

There appear to be installation instructions in at least three places, they don't agree, and each is missing at least one step.

I'm trying to install on a mac, building from source, and even though I've built many other open source packages (and also built earlier versions of povray) the current state of install docs for povray is a challenge to sort through.

unix/README
(1) Says to start with ./configure but there is no such file.
(1a) Fails to mention prebuild.sh and the dependency on autoconf and automake.
(2) Says "See the INSTALL file for more detailed information" but there is no such file.
(3) Says nothing whatsoever about dependencies.
(4) Makes no mention of the --prefix option on configure, which is crucial for anyone who doesn't have admin privs.

unix/install.txt
(1) Says to start with ./configure but there is no such file.
(1a) Fails to mention prebuild.sh and the dependency on autoconf and automake.
Otherwise, it is very thorough.

unix/README.md
(1) This is the only one that mentions prebuild.sh
(1a) but it fails to mention the dependency on autoconf and automake.
(2) mentions dependencies but why do they all have the unusual xxx-dev suffix, which isn't mentioned in install.txt
(3) Makes no mention of the --prefix option on configure, which is crucial for anyone who doesn't have admin privs.
(4) At least it points the user to install.txt instead of the non-existent INSTALL.

Further, while trying to find the non-existent configure, I discovered that the tarsal appears to contain versions of the dependent libraries (zlib, tiff, etc.). Thus I might naturally assume that the main configure for povray will try to build those (else why would they be there?). But I don't see any documentation telling me about this.

Zacko

Compilation will fail on Mac OS X with the compiler unable to find the uint type unless sys/types.h is included in vfe/unix/vfeplatform.h and vfe/vfesession.h. Macports patches this in: https://trac.macports.org/browser/trunk/dports/graphics/povray/files/patch-vfe-uint.diff

There is a file named "pavement_s3_t6_p12.txt".
But the file "pavement_s3_t6_p12..jpeg" doesn't exist.

I am a manager of the MacPorts package management system, trying to update our povray package to version 3.7.0.0. There appear to be numerous warnings, culminating in the configure script failing because Makefile.in did not get created. Here is a log of what happens on OS X 10.9.

https://gist.github.com/ryandesign/7622361

http://news.povray.org/povray.binaries.images/message/%3Cweb.5727406d27a8e5387a3e03fe0%40news.povray.org%3E/#%3Cweb.5727406d27a8e5387a3e03fe0%40news.povray.org%3E

File '/tmp/Empty.pov' line 17: Parse Error: Incorrect point in lathe.
Fatal error in parser: Cannot parse input.
Render failed

version 3.7;

include "functions.inc"

global_settings {
assumed_gamma 1.000000
max_trace_level 3
charset utf8
}
sky_sphere {
pigment {rgb<0.050, 0.050, 0.050>}
}

declare Default_texture = texture{pigment {rgb 0.8}}

declare data_Lathe_shape_ob =

lathe { bezier_spline 8,
<0,1><0.25,0.75><-0.07594,0.5><0.1875,0.1875>
<0.1875,0.1875><0.3929,-0.05616><0,-0.5><0,-1>
}
object {data_Lathe_shape_ob
texture {Default_texture}
matrix <1.000000, 0.000000, 0.000000, 0.000000, -0.000000, -1.000000, 0.000000, 1.000000, -0.000000, 0.000000, 0.000000, 0.000000>
}

light_source {
<5.07,5.58,4.28>
color rgb<1, 1, 1>
fade_distance 25.0000000000
fade_power 1
}
camera {
perspective
location <0,0,0>
look_at <0,0,-1>
right <-1.7777777777777777, 0, 0>
up <0, 1, 0>
angle 49.134343
rotate <-27.098163, 46.688390, -0.903519>
translate <7.481132, 5.343666, 6.507640>
}

Povray is failing to build "Error: povray 3.7.0.0 did not build" when using the "brew install -v povray" command.
Errors were all within the 'makeinstall' section.

I have searched the forums but haven't seen anything I can implement myself to fix this issue.

(Can't attach log files since I don't have write permission?)

Hi,

I can't visit www.povray.org for weeks. Is there anything wrong with the organization?

Is http://news.povray.org/povray.bugreports/ the replacement?

I realize the irony of making this in the new GitHub issue section.

After reading Bug #48, I tried to build the 64 bit version from git (commit #4983507) on Windows 10 so I could compare it with the official 3.7.0.0 release. Unfortunately, it refuses to build with Visual Studio 2015 Community Edition.

There were MANY warnings, but the errors that stopped the build were as follows:

Severity Code Description Project File Line

Error C2440 'initializing': cannot convert from 'overloaded-function' to 'const pov::Sys1' povbackend C:\src\povray\source\backend\vm\fnpovfpu.cpp 491
Error C2668 'acosh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_expressions.cpp 754
Error C2668 'asinh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_expressions.cpp 757
Error C2668 'atanh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_expressions.cpp 760
Error C2668 'asinh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_functions.cpp 1203
Error C2668 'acosh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_functions.cpp 1206
Error C2668 'atanh': ambiguous call to overloaded function povparser C:\src\povray\source\parser\parser_functions.cpp 1209
Error LNK1181 cannot open input file 'C:\src\povray\windows\vs10\bin64\lib\povbackend64.lib' GUI C:\src\povray\windows\vs10\LINK 1

The full list of errors & warnings is attached.
error.txt

Hi,

I encountered a strange bug when trying to build povray 3.7 stable on Debian 7.0 wheezy:

git clone https://github.com/POV-Ray/povray.git povray.git
cd povray.git
git checkout 3.7-stable
cd unix
./prebuild.sh
#(...)
Run ../bootstrap
./bootstrap: 7: ./bootstrap: Bad substitution
sed: can't read ./Makefile.in: No such file or directory
# change bootstrap to use /bin/bash rather than /bin/sh (dash on my system):

$ git diff prebuild.sh
diff --git a/unix/prebuild.sh b/unix/prebuild.sh
index dc50640..e4cce04 100755
--- a/unix/prebuild.sh
+++ b/unix/prebuild.sh
@@ -709,7 +709,7 @@ case "$1" in
   *)
   echo "Create $bootstrap"
   cat << pbEOF > $bootstrap
-#!/bin/sh -x
+#!/bin/bash -x

 # bootstrap for the source distribution of POV-Ray $pov_version_base for UNIX
 # Written by $pov_config_bugreport


./prebuild.sh
#(Now runs without errors, and I can ./configure COMPILED_BY="your name <email@address>"
# and make as usual (confirmed with running unix/povray --benchmark

The closest similar thing I could find is this old Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022

I don't think this is the exact same thing, but I'd guess it is either a bug in Debian's autotools, or some strange interaction with the version Debian uses, and whatever povray upstram uses.

Not sure if I advocate making this change in povray, but thought I'd file a bug here so the (mis)behaviour (and possible fix) is documented.

Hi there ! I have seen a doc on the internet where it is said that if you provide option "+I-" on the command line you can pipe the pov code to povray without needing to write it to a file. However it doesn't seem to work: I get this error whatever I try:

Possible Parse Error: Cannot find file '-', even after trying to append file
 type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.

I am using POV-Ray 3.7 which I compiled from this repo a few days ago.

Is this option deprecated ? Thanks in advance !

In "10 - Ready made scenes" directory, for example :

10 - Basic Scene 01 - Checkered plane.txt
10 - Basic scene 01 - Checkered plane.jpg

With text files, there is "Scene".
With jpg files, there is "scene".

It is harmless under Windows (non case sensitive file-system)
But, it can be under unix-like (case sensitive file-system)

For example, with the file name "colors.inc.txt", there is a file "colors.inc.jpg".

But, with the file name 'chars.inc.txt", there isn't a "chars.inc.jpg', but 'chars.jpg'

The master branch now uses POSIX_V6_LP64_OFF64 and friends in vfe/unix/syspovconfig*.h to define the 64bit POV_LONG as either long and long long.

Checking only for
defined(_POSIX_V6_LP64_OFF64)
is not correct - platforms like armhf define this to -1 (see /usr/include/arm-linux-gnueabihf/bits/environments.h [Debian armhf]). On the other hand these macros are not defined if it is possible to have different environments on a platform and sysconf can be used to query the actual value (see /usr/include/x86_64-linux-gnu/bits/environments.h [Debian amd64]). So using
(defined(_POSIX_V6_LP64_OFF64) && _POSIX_V6_LP64_OFF64 > 0)
(probably needed for all POSIX* variables) might be a start to solve this issue.

Anyway, there should be a test at compile time that triggers an error if POV_LONG is not a 64bit type ... otherwise you run into spurious segfaults later on.

Building POV-Ray on Ubuntu 13.10 64Bit returns the following error:

../source/libpovray.a(tokenize.o): In function `pov::Parser::Get_Token()':
tokenize.cpp:(.text+0x24b1): undefined reference to `boost::this_thread::yield()'
collect2: error: ld returned 1 exit status

libboost-dev version is 1.53.0.0ubuntu2

The issue is that the normal for the prism bezier spline is reversed from all other spline uses in both lathes and prisms. See the attached tarball for the README, test cases, some pre-rendered.

PrismBezierNormalFlipped.tar.gz

The file README in the unix directory refers to a file called INSTALL for detailed installation instructions; that file does not exist in the Git repository. It may have been lost due to a naming conflict with the script file install in the same directory.

We should examine whether we can rename install to install.sh.

Performance has declined since the official 3.7.0 release.

On Ubuntu 14.04.04, the inbuilt benchmark is reported to be running about 19% slower for 3.7.1-alpha.8344733; on Windows 7, a difference of about 17% has been measured.

The reason for this difference needs to be examined.

In an image_map or similar statement, when the image file type keyword (such as jpeg, png) is omitted to have POV-Ray infer the type from the extension, POV-Ray will not accept plain string variables; e.g. the following will fail:

#declare Name="test.png"
#declare P = pigment { image_map { Name } }

The master branch of povray (from github), since commit 1b5aab6 (27
June 2015) has a problem that stop compiling the code:

boost::scoped_ptr needs #include <boost/scoped_ptr.hpp>, but so far
parser.cpp (source/parser/parser.cpp) is lacking that include.

Maybe it was implicitly included in version of boost before 1.55, but
on 1.55 (the only one available with Ubuntu Vivid 15.04), it is
missing and compilers do not like it.

same problem in archlinux
add "#include <boost/scoped_ptr.hpp>" in parser.cpp to avoid error

Although the current PGM and PPM file format specifications do acknowledge that the formats are in practice sometimes used with linear encoding (PGM) or the sRGB colour space (PPM), both specs clearly mandate data to be gamma-encoded using the ITU-R BT.709 transfer function, with a whitepoint of D65, and (in case of PPM) the use of the ITU-R BT.709 primaries, for "true" PGM/PPM files. (An exception is explicitly mandated for PGM images used as transparency masks, which are to use linear encoding of opacity.)

POV-Ray currently presumes PGM and PPM input files to match the assumed_gamma setting, and will also use that setting for PGM and PPM output, unless explicitly overridden by the user. This should possibly be considered an error (though a fix should maintain backward compatibility for legacy scenes).

It must be noted that for the PPM file format, the sRGB colour space is acknowledged as "a common variation on PPM"; it is not 100% clear at this point how widespread this variation of PPM is de-facto, and whether it may be a wiser choice for a default gamma in import and/or export; however, POV-Ray's current practice of performing no gamma correction at all, and not even warning about it is probably not the wisest.

In any case, with PGM and PPM officially defaulting to the ITU-R BT.709 transfer function, the user must be provided with a means to select this exact transfer function for both in- and output file gamma, as they currently can with the sRGB transfer function. As it is now, users can only resort to an approximate power-law transfer function.

(Just for the records, both the whitepoint and the primaries mandated by the PGM/PPM specs are consistent with sRGB, so in this regard there is no inconsistency between PPM output and standard-compliant PNG and JPEG output.)

(Other sphere_sweep issues: #147 #285 #287)

For further background see attached file and the thread at:

http://news.povray.org/povray.bugreports/thread/%3Cweb.5692847b8bcbbc2219f71b680%40news.povray.org%3E/

My view as also posted to the above thread:

I was reminded of this issue the other day and have been doing some more investigation.

I spent a lot of time comparing 3.6 to 3.7 code given 3.6 works only to find nothing. I finally stumbled across the fact the bounding mechanism is always on in 3.7. In other words (-MB / +MB) doesn't function 3.7.

In 3.6 we need 3 shapes (I think) or more for the bounding mechanism to trigger and we have 1 so internal bounding is off.

Is this the -MB / +MB mechanism supposed to work in 3.7 ? We changed the default threshold in the docs to 25 so guessing yes. I could find no 3.6 -> 3.7 change notes related to it.

The issue behind is just another issue with the bounding computation as you thought Christoph, and it is sitting there in 3.6 too - if we turn bounding on with +MB1.

Basically the current mechanism multiplies the radius of each sphere by 2 and in this case here where the radius is small, but the range is a couple orders of magnitude larger, that 2x just isn't enough. This even though the curve is a pretty gentle cubic as curves go.

The multiplier should probably fudge upward from 2 by default if the range for the curve is large compared to the radius. Another more general option would be to add a new keyword to the sphere_sweep which lets the user optionally control the bounding radius multiplier?

the.pov.txt

source/base/image/image.cpp uses the lseek64() function in three places; this function is non-POSIX and isn't present on all platforms, like Mac OS X.

Macports just patches the function to point to seek(): https://trac.macports.org/browser/trunk/dports/graphics/povray/files/patch-lseek64.diff

I have mosaic preview set up in my INI file, but sometimes I'd like to skip it and proceed with the regular render. A hotkey to do this would be nice, Thanks!

Running the configure script on OS X produces these messages:

Makefiles
---------
stat: illegal option -- c
usage: stat [-FlLnqrsx] [-f format] [-t timefmt] [file ...]
stat: illegal option -- c
usage: stat [-FlLnqrsx] [-f format] [-t timefmt] [file ...]

The -c option of stat is a GNUism; on the BSD version of stat included in OS X, the equivalent option is -f.

In MacPorts we are patching this but of course that won't work for GNU stat. So you'll need to come up with a way to determine whether GNU stat or BSD stat is present and use the corresponding flag.

When compiling the head of branch hotfix/github_issue_29 with gcc, it works but the benchmark is done in very fast time (render time is less than 5 seconds wall-time, whereas it should be in 130+ seconds on that system).

icpc-compiled-povray and clang-compiled-povray render the image (of benchmark) fine, but the gcc-one is bogus too.

----------------------------------------------------------------------------
Finite Objects:          175
Infinite Objects:          3
Light Sources:             2
Total:                   180
----------------------------------------------------------------------------
Parser Time
  Parse Time:       0 hours  0 minutes  0 seconds (0.543 seconds)
              using 1 thread(s) with 0.542 CPU-seconds total
  Bounding Time:    0 hours  0 minutes  0 seconds (0.000 seconds)
              using 1 thread(s) with 0.000 CPU-seconds total
----------------------------------------------------------------------------
Render Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 3
  Antialiasing.........On  (Method 1, Threshold 0.300, Depth 3, Jitter 0.30,
 Gamma 2.50)
==== [Rendering...] ========================================================
Rendered 262144 of 262144 pixels (100%)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 512 x 512
----------------------------------------------------------------------------
Pixels:           294912   Samples:          261864   Smpls/Pxl: 0.89
Rays:            1143262   Saved:              5862   Max Level: 12/12
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Box                            2735945         1337058     48.87
Cone/Cylinder                  2924261          690554     23.61
CSG Intersection               3935246         2206371     56.07
CSG Merge                        72547            7354     10.14
Fractal                          39921            4960     12.42
Height Field                    155365           59095     38.04
Height Field Box                155365          117984     75.94
Height Field Triangle           157226           59155     37.62
Height Field Block             1211187           92285      7.62
Height Field Cell              1321546          100406      7.60
Isosurface                      725777          385841     53.16
Isosurface Container            725852          725847    100.00
Isosurface Cache                 66808            4780      7.15
Mesh                             63789           39325     61.65
Plane                          1137384          683433     60.09
Sphere                         3596642         3003622     83.51
Superellipsoid                   11395            3061     26.86
Torus                            89670           32226     35.94
Torus Bound                      89670           37905     42.27
True Type Font                   37845           26873     71.01
Clipping Object                1391577          882792     63.44
Bounding Box                  29451494        13131156     44.59
----------------------------------------------------------------------------
Isosurface roots:            725777
Function VM calls:         33914511
----------------------------------------------------------------------------
Crackle Cache Queries:          339156
Crackle Cache Hits:             333959 ( 98 percent)
----------------------------------------------------------------------------
Roots tested:                 37905   eliminated:                    0
Media Intervals:             158822   Media Samples:           1429398 (9.00)
Reflected Rays:              104110   Total Internal:                1
Refracted Rays:               72777
Transmitted Rays:            300621
----------------------------------------------------------------------------
Number of photons shot:           36326
Surface photons stored:           13877
Gather function called:          551024
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes  2 seconds (2.380 seconds)
              using 15 thread(s) with 2.752 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  0 minutes  4 seconds (4.206 seconds)
              using 12 thread(s) with 49.656 CPU-seconds total
povray: removing /tmp/pov7320.ini
povray: removing /tmp/pov7320.pov
POV-Ray finished

I have updates in hand locally will shortly be generating a pull request to add 32bit, unsigned, big endian format write capability to the SDL. The 8 bit and 16 bit methods exist already via the ARRAYS_WriteDF3() macro in arrays.inc.

Details:

It appears as a side effect of investigation of FS#294: the code in isosurf.cpp, inside bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)

    if(gradient < temp)
            gradient = temp;

is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)

It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)

Reference: http://bugs.povray.org/task/296

Something in the changes for the commit c891131

|| Date: Sat Mar 5 15:31:55 2016 +0100
||
|| Fixed two mesh camera bugs and other camera flaws.
||
|| - Fixed FS#254 (mesh_camera type 0 repeats first pixel line).
|| - Fixed FS#261 (mesh_camera type 3 output image is offset by 0.5 pixels).
|| - Fixed mesh_camera-related flaws in the parser.
|| - Fixed a family of bugs that could cause problems when using focal blur wit
|| - A bit of refactoring (changed TracePixel::operator() semantics).

appears to have broken AA. See attached png files for this commit and the last code commit just prior.

Ubuntu 14.04

Comand used: povray +w1200 +h800 +a0.3 +am2 +r3 master371.pov
master371.pov.txt

When I run ./prebuild.sh in the unix directory of the povray 3.7.0.0 source code downloaded from github, on OS X 10.9, I get some errors:

Detected autoconf 2.69
Detected automake 1.14
Create ../AUTHORS
Create ../ChangeLog
Create ../configure.ac
Create ../COPYING
Create ../NEWS
Create ../README
Create ../VERSION
Create ../povray.1
Create ../povray.conf
Create ../scripts/
chmod: ../scripts: No such file or directory
Create ../ini/
chmod: ../ini: No such file or directory
Create ../include/
chmod: ../include: No such file or directory
Create ../scenes/
chmod: ../scenes: No such file or directory
Create ../INSTALL

The problem is in these lines of the prebuild.sh script:

  for file in \
    AUTHORS ChangeLog configure.ac COPYING NEWS README VERSION \
    povray.1 povray.conf \
    scripts/ \
    ../distribution/ini/ ../distribution/include/ ../distribution/scenes/
  do
    out=`basename $file`
    echo "Create ../$out`test -d $file && echo /`"
    $cp_u -f -R $file ../  ||  echo "$file not copied !"
    chmod -f -R u+rw ../$out
  done

Specifically, the line invoking $cp_u. It appears your intention was to copy the directories, but you're copying the contents of the directories. To fix this, use this patch:

--- unix/prebuild.sh.orig   2013-11-06 14:28:15.000000000 -0600
+++ unix/prebuild.sh    2013-11-23 19:25:18.000000000 -0600
@@ -358,7 +358,7 @@
   do
     out=`basename $file`
     echo "Create ../$out`test -d $file && echo /`"
-    $cp_u -f -R $file ../  ||  echo "$file not copied !"
+    $cp_u -f -R $file ../$out  ||  echo "$file not copied !"
     chmod -f -R u+rw ../$out
   done

On FreeBSD vfe/unix/vfeplatform.cpp needs to include <sys/wait.h>:

unix/vfeplatform.cpp:380:26: error: use of undeclared identifier 'WEXITSTATUS'
            m_ExitCode = WEXITSTATUS(result);
                         ^

I think it can be checked for in configure.ac and included conditionally just like <sys/time.h>.

I have issues compiling for OSX mainly due to the shared_ptr problem being ambiguous. I found that since you are always using the shared_ptr in reference to boost, that it is prefixed in every location to allow easy compilation on OSX. I could create a pull request if that is required but it's just a simple search across files and replace. Thank you.

bicubic_patch does not perform clipped_by operation, but it works fine with intersection.

Here the variant with clipped_by

and there the one with intersection:

Attached scenes to reproduce
bicub.tar.gz

It would be great to have clipped_by working also with bicubic_patch

I'm using Ubuntu 14.04 and I'm trying to install Povray, according to the instructions in https://github.com/POV-Ray/povray/tree/3.7-stable/unix

I checked that all dependencies are up to date (libboost-dev, zlib1g-dev libpng12-dev, libjpeg8-dev, libtiff5-dev, libopenexr-dev), and then I do the following as suggested in the git website:

cd unix/
./prebuild.sh
cd ../
./configure COMPILED_BY="your name email@address"
make

The ./prebuild.sh and ./configure are performed successfully but the make step gives the following error:

make all-recursive
make[1]: Entering directory /home/mark/Desktop/povray/povray' Making all in source make[2]: Entering directory/home/mark/Desktop/povray/povray/source'
depbase=echo core/scene/object.o | sed 's|[^/]*$|.deps/&|;s|\.o$||';
g++ -DHAVE_CONFIG_H -I. -I.. -I../unix/povconfig -I.. -I../unix -I../vfe -I../vfe/unix -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -I/usr/include -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math -march=native -pthread -MT core/scene/object.o -MD -MP -MF $depbase.Tpo -c -o core/scene/object.o core/scene/object.cpp &&
mv -f $depbase.Tpo $depbase.Po
In file included from ./core/configcore.h:41:0,
from core/scene/object.cpp:39:
./base/mathutil.h: In function ‘T pov_base::wrap(T, T)’:
./base/configbase.h:646:39: error: ‘NO_OP’ was not declared in this scope
#define POV_MATHUTIL_ASSERT(expr) NO_OP
^
./base/mathutil.h:111:5: note: in expansion of macro ‘POV_MATHUTIL_ASSERT’
POV_MATHUTIL_ASSERT((tempVal >= 0.0) && (tempVal < upperLimit));
^
make[2]: *** [core/scene/object.o] Error 1
make[2]: Leaving directory /home/mark/Desktop/povray/povray/source' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/mark/Desktop/povray/povray'
make: *** [all] Error 2

The head of master fails to compile on linux Ubuntu 14.04 with g++ 4.8 (and it's probably not the only system to fails).

1. In colour.h, missing include of to get access to std::numeric_limits

   http://www.cplusplus.com/reference/limits/numeric_limits/

2. In colour.h, circa line 1059, there is no mFilter for
   inline GenericRGBColour TransmittedColour() const

3. in express.cpp, many error about template:
   error: dependent-name ‘MAP_T:: Entry’ is parsed as a non-type, but instantiation yields a type
   MAP_T::Entry Temp_Ent;
   ^
   backend/parser/express.cpp:3200:5: note: say ‘typename MAP_T:: Entry’ if a type is meant
   backend/parser/express.cpp:3201:5: error: dependent-name ‘MAP_T:: Vector’ is parsed as a non-type, but instantiation yields a type
   MAP_T::Vector tempList;
   ^
   backend/parser/express.cpp:3201:5: note: say ‘typename MAP_T:: Vector’ if a type is meant

there is probably more issues, but so far it is already broken enough.

I guess that the warning in colour.h is wanted:
./base/colour.h:1225:73: warning: friend declaration ‘pov_base::GenericColour pov_base::ToMathColour(const pov_base::GenericRGBColour&)’ declares a non-template function [-Wnon-template-friend]
friend GenericColour ToMathColour(const GenericRGBColour& col);

POV-Ray 3.7 introduced various breaking changes, making it more important than ever to properly identify the language version for which a scene. Therefore, while traditionally a scene file without a #version statement was presumed to be designed for whatever version of POV-Ray it happened to be rendered with, the intention for POV-Ray 3.7 was to presume such scenes to be designed for the latest pre-3.7 version of POV-Ray, which is 3.6.2.

However, while this means that all portions of a scene before the first #version statement are invariably parsed in 3.6.2 compatibility mode, the version pseudo-variable does return 3.70 in such portions (or 3.71 in case of the current 3.7.1 development versions).

As a result, include files trying to restore the effective language version after temporarily switching to a different version will break the intended behaviour, by accidently switching from an implied 3.62 to an explicit 3.70. This affects virtually all standard include files, but also various 3rd party include files out in the wild.

Under unix, all text messages are truncated after 80 column.

After somes tests, it seems that it is the same limit in console messages, and in text log files (debug, fatal, render, stats, warning).

Is-it possible to change this limit ?

This is a long term whishlist item, but I had asked in the unofficial IRC channel on Freenode as to the existence of a Povray for 3D soundscapes (which might not be of this earth!)

The IRC chat:-

ShakespeareFan00    Hi
ShakespeareFan00    Anyone here know of a povray for sound?
Vq  SuperCollider?
Vq  http://supercollider.github.io/
ShakespeareFan00    I'll take a look
ShakespeareFan00    but what I was wanting to do was take mono sound sources and place them in 3D to make soundscapes
ShakespeareFan00    Setting up "sound" texture on objects in the environment
ShakespeareFan00    Which may be a slightly higher level abstraction
ShakespeareFan00    Suppercolider looks like to could do the initial generation of mono sound sources... but not necessarily the higher level "place" it in space stuff
ShakespeareFan00    Povray takes a geometric and texture definiton to produce a visual object...
ShakespeareFan00    I was wanting to create a "geometry" and "texture" for audio
ShakespeareFan00    And then position a listner in the scene
ShakespeareFan00    
ShakespeareFan00    A sound "texture" would charcteristics like "resonance", "dampening" etc...
ShakespeareFan00    So in a "Rosaual" tool  you'd define a gemoetry like in povray, but you'd be defining the texture/mmaterial as a sound texture, given that foam transmits sound differently to metal
ShakespeareFan00    I've not seen many software tools that do this, let alone any open source ones
ShakespeareFan00    SuperCollider on first glancce looks to be very low level
ShakespeareFan00    *"Rosaural"
Vq  Ah, I agree.
Vq  I know I read something about such a software.  It behaved more like a physics simulation than a synthesiser.
Vq  It could have been this:  http://gamma.cs.unc.edu/Sound/RESound/
Vq  No software though
ShakespeareFan00    Vq:thanks
ShakespeareFan00    Vq: Does Povray have a bugzilla?
ShakespeareFan00    Because I am consdering putting the above comments into it
ShakespeareFan00    RosAural =" Resonance  of Sound AUdio  EnivRonmentAL Charectristics BTW)
Vq  I don't think sound output will ever be a target for povray unfortunately.
Vq  I think the closest to a bugzilla is the povray usenet group.
ShakespeareFan00    Okay, but some of the techniques my Rosaural would use already exist as math in Povray
ShakespeareFan00    idea
Vq  I don't think the internals of povray is suited for it.  But it's thinkable that a "sound renderer" could reuse povrays scene description language.
Vq  Seems like povray is on github these days: https://github.com/POV-Ray/povray
Vq  didn't know that
ShakespeareFan00    Well if it's on Github , I can ask questions there
Vq  The issue tracker seems active.
ShakespeareFan00    Do you mind If I quote your comments there?
Vq  Not at all, but what do you hope to achieve?
ShakespeareFan00    Hopefully some feedback

Supercoilider seemed to be a low level library.

ReSound is an academic project. (http://gamma.cs.unc.edu/Sound/RESound/)

In terms of my "not of this world comment" there was some research done by Professor Paul White of Southampton University in 2012 on the propagation of sound on extra-terrestrial worlds with different atmospheres..

I was able to get 3.7 compiled on debian jessie. Instructions here - all it needed was a fix to prebuild.sh.

As a long time user of POV-Ray I started a KDE forum thread in 2010, asking for interested developers to please continue Andreas Zehender's excellent Kpovmodeler, suggesting some needed feature enhancements:

http://forum.kde.org/viewtopic.php?f=19&t=90952

You can see some screenshots and the code following these links

http://www.kde.org/applications/graphics/kpovmodeler/
http://www.kde.org/applications/graphics/kpovmodeler/development
http://websvn.kde.org/trunk/extragear/graphics/kpovmodeler/

Several POV-Ray users like myself missed Kpovmodeler inclusion in regular GNU/Linux distros after KDE 3, but one developer - the most excellent eticre - has improved Kpovmodeler and added POV-Ray 3.7 functionality

http://forum.kde.org/viewtopic.php?f=19&t=90952&start=15

Developer eticre wrote a while back
"added tiling (povray 3.7) in pattern selections"

"added pigment_pattern in pattern"

and 2013-07-18 eticre wrote

"reworked for qt5, qt3 support removed from qt code, kpart use almost them

added new declare as "Function" to declare function and import them from pov code
now you can create function using pigment and select them directly from a list in isosurface "

If you can help eticre and improve Kpovmodeler to become an included POV-Ray modeller with regular GNU/Linux distros or as part of windows.kde.org or other platforms, you will do the POV-Ray user community a great service - thank you.

In our current master branch, configure always attempts to link boost_system library, even with boost 1.49 or earlier where it isn't needed; as a consequence, in such a setting configure will fail with a cryptic error message (reporting problems with zlib) if the boost_system library is not installed.

A parametric get truncated to its first intersection when used with clipped_by or inside an intersection.
Other intersections seems to be dismissed.

Illustration with clipped_by

Illustration with intersection

Scenes to reproduce (beware, parametric is slow, even for that small sphere)
param.tar.gz

This behaviour has been verified also on the head of master branch ✅

Building master on FreeBSD 10.0 (with Clang and libc++):

depbase=`echo backend/colour/colutils.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
c++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I../vfe/unix -I/usr/local/include -pthread -I/usr/local/include  -pipe -Wno-multichar -Wno-write-strings -O2 -pipe -fno-strict-aliasing -D_THREAD_SAFE -MT backend/colour/colutils.o -MD -MP -MF $depbase.Tpo -c -o backend/colour/colutils.o backend/colour/colutils.cpp &&\
mv -f $depbase.Tpo $depbase.Po
In file included from pov_mem.cpp:39:
In file included from ./backend/parser/parse.h:49:
In file included from ./backend/scene/scene.h:52:
In file included from ./backend/lighting/radiosity.h:46:
In file included from ./backend/interior/media.h:39:
In file included from ./backend/render/trace.h:47:
./backend/support/randomsequences.h:121:11: error: unknown type name 'shared_ptr'
                virtual shared_ptr<vector<Type> > GetSequence(size_t count)
                        ^
./backend/support/randomsequences.h:121:21: error: expected member name or ';' after declaration specifiers
                virtual shared_ptr<vector<Type> > GetSequence(size_t count)
                ~~~~~~~~~~~~~~~~~~^

This is similar to #8, but this time the ambiguity is between using std::tr1::shared_ptr; in syspovconfig.h and std::shared_ptr (provided by libc++ even outside C++11 mode).

std::shared_ptr is brought into scope by namespace pov_base { using namespace std; } in syspovprotobase.h and using namespace pov_base;.

I think Clang is incorrect to call it "unknown type name", since it's an ambiguity that can be resolved by removing using namespace std;. This does introduce unresolved names all over the place, but I think they aren't difficult to fix (e.g. using std::set;).

Replacing all occurrences of shared_ptr with boost::shared_ptr or std::tr1::shared_ptr also works.

weak_ptr is analogous.

Building povray 3.7.0.0 on OS X 10.9 has the following trouble:

In file included from backend/bounding/bbox.cpp:43:
In file included from ./backend/frame.h:58:
In file included from ./backend/control/messagefactory.h:39:
./backend/control/renderbackend.h:112:16: error: reference to 'shared_ptr' is ambiguous
  map<SceneId, shared_ptr<Scene> > scenes;
               ^
../vfe/unix/syspovconfig.h:85:14: note: candidate found by name lookup is 'shared_ptr'
using boost::shared_ptr;
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:3756:56: note: candidate found by name lookup is 'std::__1::shared_ptr'
class __attribute__ ((__type_visibility__("default"))) shared_ptr
                                                       ^

In MacPorts we are replacing all occurrences of shared_ptr with boost::shared_ptr to work around this.

Cloned the source and discovered that although the readme files mention running the configure script to specify the name and e-mail of the builder, no such script is present. Only the configure script for the libraries are present.

I'm trying to compile the latest version of povray on a linux computer (CentOS) which I don't have admin rights on.

I've downloaded the source but can't find the configure script. Running autoconf in unix/ says it can't find a bunch of files under unix/, running autoconf on unix/configure.ac says it can't find VERSION.

povray$ find | grep configure
./unix/configure.ac
./libraries/jpeg/configure
./libraries/jpeg/configure.ac
./libraries/zlib/configure
./libraries/zlib/contrib/minizip/configure.ac
./libraries/openexr/configure
./libraries/openexr/configure.ac
./libraries/png/configure
./libraries/tiff/configure
./libraries/tiff/configure.ac
./libraries/ilmbase/configure
./libraries/ilmbase/configure.ac

Given recent work on #110 thought I'd port this flyspray ppm bug here to github. Tested and we still have an issue reading such ppm (likely pgm too) files.

(Copied text from FS follows from Sept 2013)

I've recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read - very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.

Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : "Possible Parse Error: Unexpected EOF in PPM file" though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.

The code which is set up to interpret the netpbm headers is reading a lines with "file->getline (line, 1024);" and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.

The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.

I'd make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.

The attached tarball when unpacked has both a passing and failing case. To run "povray fails.pov" or "povray works.pov". The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.

bugReadPPM.zip

I've tried to compile & build povray on Mac OS X El Capitan and found the following issues.

1. For downloading. I downloaded the source from the official website, and it's stable branch. However when I tried to compile, the shared_ptr issue still exists. After a bit of working I found that the issue was fixed in the master branch. So It would be better to address it when the user downloads the package.
2. For configure. When I executed ./configure, it always said: "couldn't link to boost thread library". I found lboost-thread-mt in my computer and added that option and the configure process went further. However, it then stuck at linking to boost system library. That was found when I checked out the config.log file. If the options have been added into the configure file or these comments are included in the documentation, the user will be happier.