POV-Ray for Windows version 3.7 beta 1 is now available from our beta page
(http://www.povray.org/beta/).

The EXE's available from the above page will expire on the 30th of April
2005. Note that the file contains two EXE's, one for Windows 32-bit and one
for Windows XP 64-bit edition or Windows Server 2003 64-bit edition (AMD64).

Use of this POV-Ray beta software is covered by the same license as that
which applies to version 3.6.1 (the current full release).

Note that to run the beta software you require the standard POV-Ray
installation files for your chosen platform. You can get these from the
download page if you do not already have them.

This version is a major change from version 3.6 in that the internal
structure of the renderer has been radically altered. You can expect there to
be many issues and incompatibilities that we will need to work out. We will
discuss the internal changes in more detail later if anyone is interested.

The primary advantage of version 3.7 over past versions is support for multi-
threaded rendering, which will be of most use to those users who currently
have SMP machines, or who intend either purchasing one or upgrading their
existing motherboard to a dual-core CPU such as the upcoming Athlons.
Depending on the scene, and excluding parsing/photon building time, a dual-
core system can increase rendering speed by almost 100%, and frequently in
the 70-90% range.

Here is a quick summary of some of the changes. Be sure to read this before
using the software.

Intentional changes for POV-Ray 3.7
-----------------------------------

- The version directive and command-line setting no longer provide
compatibility with most rendering bugs in versions prior to POV-Ray 3.5.
However, compatibility with the scene language is provided for scenes as old
as POV-Ray 1.0 just as in all previous versions of POV-Ray. Nevertheless, we
strongly recommend you update scenes at least to POV-Ray 3.5 syntax if you
plan to use them in future versions of POV-Ray.

- This version uses multi-threaded rendering by default. You can render in
only one thread by using the '/THREADS 1' switch in the Windows version.
Note that parsing and photon building will only use one thread. However
photon scenes will benefit from multiple threads once photon building has
completed.

The ability to render in more than one thread is primarily of use to those
users who have SMP machines (i.e. more than one CPU).

Known limitations of POV-Ray 3.7.beta.1
---------------------------------------

- Dispersion is currently not available as close investigation of the source
code showed some serious defects that can only be addressed by rewriting
this feature.  This will take time, so please be patient, we are currently
committed to continue this feature, but time is required to evaluate our new
design for this feature.  We will try to maintain SDL for this feature
exactly as it was in POV-Ray 3.6 and earlier.

- Anti-aliasing method 2 currently takes up to 20% more samples than it used
to take in POV-Ray 3.6 and earlier.  This will be corrected prior to final
release of POV-Ray 3.7.

- Light and vista buffers are not longer generated. There are currently
plans to replace the whole automatic bounding algorithm in POV-Ray 3.7 with
another algorithm that will yield generally better performance. Details
about this change will be made available once it makes its way into one of
the beta versions.

- Animation rendering is not yet supported. This feature is expected to be
back for one of the next few beta versions.

- Redirecting text message output to files is currently not available.  It
will be provided again, likely around the same time the mac and Unix version
make beta versions available.

- Mosaic preview is currently not available. We are currently investigating
how to best continue support for this feature. It will be back,possibly in
changed for in some later beta version.

- Some Windows features such as re-rendering the insert menu, running the
benchmark, and similar, do not work as expected. This will be fixed shortly.

- The Windows version is not compiled using the Intel compiler and will be
slower than 3.6.1 in many areas.

- Image output and input has been changed significantly and has not been
thoroughly tested.

- The SYS image input type (BMP files) does not currently work when specified
in height fields or image maps.

Known bugs of POV-Ray 3.7.beta.1
--------------------------------

- Photon rendering may occasionally not function as expected. This is a
known bug and we will address it as soon as possible.

- Radiosity rendering does not work. This is a known bug and we will
address it together with a modernization of some of the radiosity code.

- Some statistics and options are not displayed correctly.  Equally, some
error and warnings are current not issued, but they may very well cause
malfunctions.  These are known bugs and will address them as time and other
priorities permit.

- Preview image output is currently not gamma corrected. Your scenes may
appear darker or lighter compared to other versions of POV-Ray.  We will
address this problem soon.

Post a reply to this message

Hi Chris,

Chris Cason wrote :
> POV-Ray for Windows version 3.7 beta 1 is now available from our beta p
age
> (http://www.povray.org/beta/).

I would be glad to beta-test that on my dua### [at] 125Ghz ...
Is any OSX version coming soon ?

Best regards,

-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org

Post a reply to this message

Francois LE COAT wrote:
> I would be glad to beta-test that on my dua### [at] 125Ghz ...
> Is any OSX version coming soon ?

A Mac version is going to be made available within the next few weeks.

	Thorsten

Post a reply to this message

I copied the pvengine.exe file for the 3.7 beta 1 to the bin directory
of my current 3.6.1 installation and started it normally. However, for
some reason it fails to load the editor. It says:

Editor DLL initialisation failed [LoadLibrary failed, code is 0000007e]

  There's no mention of this in the beta page and Gilles has seemingly
run the program without problems, so it's strange.

  I'm running Windows XP (SP2) on a Pentium4 box.

  I then tried rendering a scene by writing in the command-line box:

-i ../scenes/advanced/woodbox.pov

and it rendered it ok. However, I noticed in the end stats that it
seemingly was using 4 threads ("on 4 CPU(S) with 32 CPU-seconds total").

  Does it try to detect the number of CPUs or is 4 some kind of default?

  Well, I then tried writing this:

-i ../scenes/advanced/woodbox.pov /THREADS 2

to see if it worked. Now it's hung. Even if I try to stop it by clicking
on the stop button, it won't. It's not taking any CPU time, ie it's not
doing anything, but it's just not stopping.

  Seemingly I can't specify the number of threads in this way (at least
not with the current beta).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> and it rendered it ok. However, I noticed in the end stats that it
> seemingly was using 4 threads ("on 4 CPU(S) with 32 CPU-seconds total").
> 
>   Does it try to detect the number of CPUs or is 4 some kind of default?

The Windows version detects the number of processors Windows reports and 
asks for twice as many threads.  Apparently two threads per (virtual) CPU 
gives better performance than just one at least on Windows.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> The Windows version detects the number of processors Windows reports and 
> asks for twice as many threads.  Apparently two threads per (virtual) CPU 
> gives better performance than just one at least on Windows.

  I tried rendering some scenes with 1, 2 and (the default) 4 threads
here (Pentium4). Rendering with 2 threads showed a speed increase of
approximately 20% (which is actually quite good, knowing how the
hyperthreading of P4 works). Rendering with 4 threads didn't speed
up considerably compared to 2 threads, but in some cases there was
perhaps a minor speedup (something like 1-2%), so I suppose 4 threads
is indeed slightly better than 2.
  I didn't test quite extensively, though (ie. with many varied scenes
with different rendering settings).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Editor DLL initialisation failed [LoadLibrary failed, code is 0000007e]

  It's difficult to test the program when the editor is not loading.
Why do I seem to be the only one having this problem?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Editor DLL initialisation failed [LoadLibrary failed, code is 0000007e]
> 
>   It's difficult to test the program when the editor is not loading.
> Why do I seem to be the only one having this problem?

0x7e is 'The specified module cannot be found'. Are you running POVWIN 3.6.1
or 3.6.1a ? Note that there is a major difference between the two WRT the
editor, and that will cause this error.

-- Chris

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
> 0x7e is 'The specified module cannot be found'. Are you running POVWIN 3.6.1
> or 3.6.1a ? Note that there is a major difference between the two WRT the
> editor, and that will cause this error.

  Seems like I has the non-a version. I installed the latest 3.6.1 and
now it works ok...

-- 
                                                          - Warp

Post a reply to this message

I neglected to mention the following in the list of things not yet done:

Currently file continue does not work, and moreover the output file is not
written at all until the render ends. (Contrast this with the old system
where it was written as render progresses). We will of course re-instate file
continue and provide output crash protection, it's just not in there yet.

Also, alpha is not shown or written to the output file. Will also of course
be fixed.

-- Chris

Post a reply to this message

Thorsten Froehlich wrote:
> A Mac version is going to be made available within the next few weeks.

To be more precise, the current goal is the first half of May.  However, 
please note that this is just a goal and not a promise yet.

	Thorsten

Post a reply to this message

Hi,

Thorsten Froehlich wrote:
>> A Mac version is going to be made available within the next few weeks.

> 
> To be more precise, the current goal is the first half of May.  However
, 
> please note that this is just a goal and not a promise yet.

Tiger (10.4 OS) will be out, and POV 3.7 will take benefit from it :)
At least with GCC 4.0 (Xcode 2.0) ...

Best regards,

-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org

Post a reply to this message

Francois LE COAT wrote:
> Hi,
> 
> Thorsten Froehlich wrote:
> 
>>> A Mac version is going to be made available within the next few weeks.
>>
>>
>> To be more precise, the current goal is the first half of May.  
>> However, please note that this is just a goal and not a promise yet.
> 
> 
> Tiger (10.4 OS) will be out, and POV 3.7 will take benefit from it :)

Well, but please don't hold your breath about 64-bit addressing ;-)  That is 
only available to non-GUI programs (that is, i.e. database servers and soon 
who really benefit from 64-bit addressing and don't need a GUI), so for 
POV-Ray to use it, the GUI frontend and backend will need to be split apart 
completely and run as two independent programs that communicate with each 
other.  As few users have systems with that much RAM (less than 2% according 
to the collected stats), I cannot possibly justify holding back a beta 
release to develop the means to do this.  On the other hand, there are more 
than ten times as many users with dual-processor Macs, who will benefit from 
the multithreading.  It is more realistic in about a year from now to see 
something like 64-bit support.  Sorry!

	Thorsten

Post a reply to this message

Ouch.  I am already running into situations where the 2GB memory addressing 
limit is hampering my designs.  In fact, I ran into it quite some time ago. 
Then again, where are the 64-bit floating-point compilers to take advantage of 
this possibility?

Thorsten Froehlich wrote:
> Francois LE COAT wrote:
> 
>> Hi,
>>
>> Thorsten Froehlich wrote:
>>
>>>> A Mac version is going to be made available within the next few weeks.
>>>
>>>
>>>
>>> To be more precise, the current goal is the first half of May.  
>>> However, please note that this is just a goal and not a promise yet.
>>
>>
>>
>> Tiger (10.4 OS) will be out, and POV 3.7 will take benefit from it :)
> 
> 
> Well, but please don't hold your breath about 64-bit addressing ;-)  
> That is only available to non-GUI programs (that is, i.e. database 
> servers and soon who really benefit from 64-bit addressing and don't 
> need a GUI), so for POV-Ray to use it, the GUI frontend and backend will 
> need to be split apart completely and run as two independent programs 
> that communicate with each other.  As few users have systems with that 
> much RAM (less than 2% according to the collected stats), I cannot 
> possibly justify holding back a beta release to develop the means to do 
> this.  On the other hand, there are more than ten times as many users 
> with dual-processor Macs, who will benefit from the multithreading.  It 
> is more realistic in about a year from now to see something like 64-bit 
> support.  Sorry!
> 
>     Thorsten


--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

Hi,

Thorsten Froehlich wrote:
> Francois LE COAT wrote:
>> Thorsten Froehlich wrote:
>>
>>>> A Mac version is going to be made available within the next few week
s.
>>>
>>> To be more precise, the current goal is the first half of May.  
>>> However, please note that this is just a goal and not a promise yet.
>>
>> Tiger (10.4 OS) will be out, and POV 3.7 will take benefit from it :)
> 
> Well, but please don't hold your breath about 64-bit addressing ;-)  

The 64-bits addressing is not the main feature of GCC 4.0 that I'm
looking forward ... I was speaking of refined optimizations such
as parallelization and vectorization of the PPC code ... It seems
that GCC 4.0 is a great step in the direction of more efficient
code generation.

Do you know more than I know myself ?

Best regards,

-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org

Post a reply to this message

Francois LE COAT wrote:
> The 64-bits addressing is not the main feature of GCC 4.0 that I'm
> looking forward ... I was speaking of refined optimizations such
> as parallelization and vectorization of the PPC code ... It seems
> that GCC 4.0 is a great step in the direction of more efficient
> code generation.
> 
> Do you know more than I know myself ?

On the gcc mailing list there have been several notes that code actually is 
slower when compiled with gcc 4.0 than with 3.4 due to some optimizations 
they had to leave behind when getting their new optimizer framework in. 
Supposedly only gcc 4.1 will bring most of those things back.

Besides, I am not exactly very confident with what Apple will ship with Mac 
OS X 10.4 - while they claim it will be gcc 4.0, it cannot actually be 
because that way only released *today* but Apple is already sending out CDs, 
which must have been pressed at least a week ago.  Besides, in the past 
serious bugs in Apple's custom version of gcc have broken popular C++ 
libraries such as boost - the current Apple supplied gcc 3.3.x (not the real 
gcc) has had an infinite loop allocating memory bug in the *compiler* (not 
the generated code) for several months and Apple has not taken any action.

As it stands, I would be more interested to get the 'real' gcc generate AIX 
for PowerPC code as that uses the sane and properly designed PEF/CFM 
execuatable format* rather than the flawed Mach-O format (see for example 
the summary on <http://www.unsanity.org/archives/000044.php> to learn why 
Mach-O applications are so slow)...

	Thorsten


* IBM developed it along with the first Power processor, the superset of the 
instruction set and processor architecture PowerPC processors are based on. 
When Apple moved to PowerPC, the first Mac OS was developed using IBM 
compilers running on Power-based AIX workstations.

Post a reply to this message

Hi,

Thorsten Froehlich wrote:
> As it stands, I would be more interested to get the 'real' gcc generate
 
> AIX for PowerPC code as that uses the sane and properly designed PEF/CF
M 
> execuatable format* rather than the flawed Mach-O format (see for 
> example the summary on <http://www.unsanity.org/archives/000044.php> to
 
> learn why Mach-O applications are so slow)...
> 
> * IBM developed it along with the first Power processor, the superset o
f 
> the instruction set and processor architecture PowerPC processors are 
> based on. When Apple moved to PowerPC, the first Mac OS was developed 
> using IBM compilers running on Power-based AIX workstations.

Well, as you are speaking about IBM, it seems that XLC (the IBM
compiler) can just be put in place of GCC using Xcode and produce
the best code for PPC. I can't find any information about that ...
Can you ?

Best regards,

-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org

Post a reply to this message

Francois LE COAT wrote:
> Well, as you are speaking about IBM, it seems that XLC (the IBM
> compiler) can just be put in place of GCC using Xcode and produce
> the best code for PPC. I can't find any information about that ...

It is not about the compiler, but the executable format.  IBM had to port 
their compiler to the flawed Mach-O, so it does not solve any of the problems.

	Thorsten

Post a reply to this message

Hi,

Thorsten Froehlich wrote:
> Francois LE COAT wrote:
> 
>> Well, as you are speaking about IBM, it seems that XLC (the IBM
>> compiler) can just be put in place of GCC using Xcode and produce
>> the best code for PPC. I can't find any information about that ...
> 
> It is not about the compiler, but the executable format.  IBM had to 
> port their compiler to the flawed Mach-O, so it does not solve any of 
> the problems.

Well, you're speaking of another platform (AIX eventually).
I personally used XLC for benchmarking, comparing dual-G4 and
dual-G5, with standalone IBM compiler and GCC (Xcode 1.5).

Time (in seconds) for computing 100 images :

dua### [at] 125GHz : GCC (3.3) 104 s. - XLC (6.0) 85 s.
dua### [at] 25GHz  : GCC (3.3) 60  s. - XLC (6.0) 48 s.

and parallel code for image processing (matching mainly integers).

I know that Apple let XLC replace the GCC compiler of Xcode
to produce a better code. Have you heard about that ?

Best regards,

-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org

Post a reply to this message

Francois LE COAT wrote:
> I know that Apple let XLC replace the GCC compiler of Xcode
> to produce a better code. Have you heard about that ?

The IBM compiler is just a command-line program like gcc, and it also takes 
most of the gcc flags for compatibility.  You can hook it into any 
makefile/shell based process easily.

	Thorsten

Post a reply to this message