POV-Ray 3.7.beta.6 is available from http://www.povray.org/beta/.

This beta is currently for the Windows platform only and includes standard,
SSE2, and 64-bit binaries.

---------------------------------------------------------------------------
Note: to view an original bug report, prefix the message ID with the URL
http://news.povray.org/. For example, to read <42765ef3$1@news.povray.org>,
visit http://news.povray.org/<42765ef3$1@news.povray.org>. The '<' and '>'
are optional (if using a shell you may want to omit them).
---------------------------------------------------------------------------

The following features are not supported but will be added prior to release
---------------------------------------------------------------------------

  o Animation.
  o Radiosity.
  o Dispersion.
  o Mosaic preview.
  o Light and vista buffers. These may replaced with a more efficient system.
  o Ability to choose block size allocated to threads.
  o Resume render (a.k.a. 'continue').
  o Windows rerun dialog and statistics.
  o Redirecting text message output to files.

Known issues which will be fixed
--------------------------------

  o There is an issue with media and transparency. See
    <42769324$1@news.povray.org>.
  o The windows editor does not always detect new files as type 'povray'.
  o Text layout of windows message page not yet finished (e.g. no wrapping,
    early wrapping).
  o There are memory leaks, and memory tracking is not yet complete.
  o In many cases speed is not as good as 3.6.
  o Photon support is not yet completed.
  o There are some differences in the way gamma correction works.
  o Anti-aliasing method 2 currently takes more samples than in version 3.6
    and earlier.

Changes between 3.7.beta.5a and 3.7.beta.6
------------------------------------------

Fixed quadric bounding problem.
Fixed CSG merge problem.
Made numerous other changes to speed up code, should be closer to v3.6.1 now.

Changes between 3.7.beta.5 and 3.7.beta.5a
------------------------------------------

Fixed bug reported in <428de855@news.povray.org> re:sunsethf.pov.
Worked around SMP bug in trace related to lighting code altering lightsources
  during render.

Changes between 3.7.beta.4 and 3.7.beta.5
-----------------------------------------

Fixed a photon building issue that caused progressive slowdown.
Fixed scattering media problem reported in <427ca163@news.povray.org>.
  (This also fixes <427c0121@news.povray.org>).
Parser now honors Split_Unions and Remove_Bounds options.
Fixed lathe artifacts bug reported in <427c0f95@news.povray.org>.
Fixed no_image and no_reflection issues reported in
  <427c1900@news.povray.org>.
Fixed area light orient issue reported in <427c14ef@news.povray.org>.
Fixed issue where a new clip statement would overwrite a previous one rather
  than appending to it.
Fixed speed issue with quadrics by reverting to old bbox calculation method.
Fixed a swathe of memory leaks.

Changes between 3.7.beta.3 and 3.7.beta.4
-----------------------------------------

Fixed indexed PNG alpha problem reported in <42765ef3$1@news.povray.org>.
Fix area light problem reported in <427a3fa5$1@news.povray.org>.
Fixed crash during trace of lathe reported in <42796797@news.povray.org>.
Improved handling of cancel/pause render.
Fixed max_trace_level calculation and display (see
  <42769105@news.povray.org>).
Fixed image memory leak.
Fixed speed issues reported in <42769f6d@news.povray.org>.
Fixed shadow problem mentioned in <42769f6d@news.povray.org>.
Fixed sphere_sweep bug reported in <42773e51@news.povray.org>.
Fixed 'inverting pre-declared union' crash reported in
  <42769b59@news.povray.org>.
Fixed focal blur issue.
Fixed omnimax camera bug reported in <42775c1b$1@news.povray.org>, plus
  several other related camera issues.
Fixed facets pattern crash reported in <42773fab$1@news.povray.org>.

Changes between 3.7.beta.2 and 3.7.beta.3
-----------------------------------------

Partial render (start col/row etc) now works
Fixed CSG merge issue reported in <42645c3b@news.povray.org>.
Added warning and better progress reporting to photons.
Some hollow media fixes.
Re-enabled alpha display in render window for windows port.
Fixed alpha bug reported in <web.426402d627a031d914107e060@news.povray.org>
Fixed no_image bug from <web.426402d627a031d914107e060@news.povray.org>
Changed default bounding threshold back to 3 as per v3.6.
Fixed alpha inversion bug in BMP, Targa, and PNG file reading/writing.
Fixed crash mentioned in <42689685@news.povray.org>.
Fixed noise generator default issue reported in <426898db@news.povray.org>.
Fixed irid problem reported in <42680b39@news.povray.org>.
Fix for area light problem from Massimo Valentini.
Made quick_colour work as it should.

Changes between 3.7.beta.1 and 3.7.beta.2
-----------------------------------------

CSG should now work properly
Problem with too many recursions when rendering shadows fixed
I/O restrictions should now work
Fixed recursion bug in renderer
Initialise photon variables
Restore ability to open error file in editor (note: column number not always
  correct).
Fixes no-display crash
Fixes image closing bug
Tweak to some radiosity local vars
Fixes rendering area bug
Fixes AA method 2 brightness issue
Add output file type '+FB' (bmp).
Add 'bmp' token to parser.
Fix for BMP reading.
File output defaults to on.
Fix render quality options output.
Change references to 'CPU(s)' to 'thread(s)'.
Update render time output to include fractional seconds.
Fix crash reported in <4263125b@news.povray.org> and one related bug.

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

The version directive and command-line setting no longer provide compati-
bility  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. 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). There have been reports of benefits for
users of hyperthreading systems, particularly with higher thread counts (e.g.
16 threads).

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 no matter how many are specified. However photon scenes will benefit
from multiple threads once photon building has completed.

Post a reply to this message

Congratulations, Chris, on getting this beta 6 out-- earlier than *I* 
expected.

After only a quick look I see that the command-line switch +O for file name 
output doesn't work, as I noted sometime before. It ignores the backslashes 
and so places the image file into the root of whichever drive is chosen, 
with a folder-turned-file name being the result.

I happened to be checking the doc about command-line switches and found a 
link not working on the page of section 1.4.2 Toolbar. Specifically, 1.4.2.2 
Toolbar Command Line, the Options Reference link. The source says:

See the <a href="#l4">Options Reference</a> for a full list.

Clicking on it goes nowhere. I don't know where it should be going to. Maybe 
the section 3.1.2 Command-line Options, unless there's a place with just a 
list of those switches.

Bob

Post a reply to this message

Thanks for the feedback.

I didn't fix a lot of bugs this time around since I spend a long time hunting
down slowdowns in the code and finding ways to fix or at least improve them.
Once the speed comes more up to scratch I'll get back more into bug fixing.

-- Chris

Post a reply to this message

"Chris Cason" <nos### [at] deletethispovrayorg> wrote in message 
news:42aecf55$1@news.povray.org...
> Thanks for the feedback.

Welcome to it.

> Once the speed comes more up to scratch I'll get back more into bug 
> fixing.

With bugs being introduced along with the new changes that seemed a likely 
reason to bypass the simpler things. At least, I sure hope it'll be simple.

I believe the program shows its complexity each time changes are made, 
something that users like me get complacent about when so-called 
difficulties are merely about adjusting a scene file to look right.

Bob

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
> I didn't fix a lot of bugs this time around [...]

Oh, ok, thanks for making this point clear. It will perhaps prevent
everybody posting here about "this bug is still not fixed" and the like.
Well, 1st impression here: 3.7.0.beta6 seems halfway between 3.6.0a and
3.7.0.beta5a as far as speed is concerned. I'll try to run a few tests on
my scenes now.
Thanks for releasing this new beta!

JYR

Post a reply to this message

JYR wrote:

>> Oh, ok, thanks for making this point clear. It will perhaps prevent
>> everybody posting here about "this bug is still not fixed" and the like.
>> Well, 1st impression here: 3.7.0.beta6 seems halfway between 3.6.0a and
>> 3.7.0.beta5a as far as speed is concerned. I'll try to run a few tests on
>> my scenes now.


BTW some hints for running speed comparison tests: the most 'pure' comparison
is to run the new code with '/threads 1', since that most closely
approximates the way the old code worked. that is what I do if I want to work
out where the new code is slower than the old.

from a practical standpoint, however, if you have hyperthreading available
you ought to run at least four and perhaps more threads. if you have a
dual-core CPU then you ought to run four or perhaps eight if you have a
dual-core HT box (though the CPU time reports will be misleading in the
latter case).

if you have an SMP box with discrete CPU's you will suffer a performance
penalty on some scenes as against a dual-core due to the need for write-
combines on the CPU caches. this will show itself as increased CPU time
needed for a render when you switch from one thread to more than one.

by way of example, I have a dual Xeon and a dual-core AMD machine here. the
render times on (for example) mediasky.pov are very similar on both when run
with one thread, but when I start using both CPU's the AMD thrashes the Xeon
because it has both CPU's on-chip and they share a cache. (this would
actually be a disadvantage if you were running multiple applications, but in
the case of a single app it can be very useful).

I haven't tested on an Intel dual-core yet so can't comment on that one.

users of discrete SMP machines will however probably notice a more
significant improvement in this current beta than users of other systems
since some of the changes I made affect that class of system more strongly.

the other thing to take into account is that if you render with AA the new
code will be at a disadvantage since the current default AA code actually
renders more pixels; to do a side-by-side comparison of speed it's best to
leave AA off.

-- Chris

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
> the most 'pure' comparison is to run the new code with '/threads 1'
I'll take care of that! I have a plain AMD Athlon XP 2800+... no multi-cores
or multi-CPU here :(

> to do a side-by-side comparison of speed it's best to leave AA off.
[switches tasks, kills current render and restarts it with -a] oops, i
should've thought about that by myself!

JYR

Post a reply to this message

JYR wrote:
> Chris Cason <nos### [at] deletethispovrayorg> wrote:
>> the most 'pure' comparison is to run the new code with '/threads 1'
> I'll take care of that! I have a plain AMD Athlon XP 2800+... no multi-cores
> or multi-CPU here :(

Note that even in this case, the code will default to running with two threads.

-- Chris

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
> JYR wrote:
> > I'll take care of that! I have a plain AMD Athlon XP 2800+... no multi-cores
> > or multi-CPU here :(

> Note that even in this case, the code will default to running with two threads.

  I'm wondering if it makes any difference in practice.

  One could think, of course, that continually switching between two
threads causes overhead. However, one has to remember that the OS will
be "switching between threads" all the time regardless. If there's only
one cpu-intensive task then it will be "switching" to that continually
(process management will be done regardless of how many cpu-intensive
processes there are running). Thread-switching is a quite light operation
and doesn't take almost any cpu time at all.
  If there are two cpu-intensive threads the OS will naturally continually
switch between the two (at regular intervals), but it will not do any
considerable amount of extra work for this.

  One thing where there might be a difference between "switching" one
single thread and truely switching between two different threads is that
if one of the threads is running a tight loop which takes very long to
execute, the loop code will be flushed from the pipelines each time
the other thread gets cpu time.
  However, from the point of view of povray task switching happens very
rarely. I don't know how often Windows performs task switching, but even
if it does so eg. 200 times per second, that's an eternity from the point
of view of the program (especially in current multi-gigahertz processors)
and probably no loop will last that long anyways.

  One place where running in two threads might actually be beneficial
even with one processor is when rendering to a file: While one thread
is writing to the file the other can keep rendering, thus 100% of the
cpu time is used.
  However, since povray writes to the file very rarely, this probably
would speed up the whole rendering process only fractions of a percent.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> execute, the loop code will be flushed from the pipelines each time
> the other thread gets cpu time.

  I meant cache. The code gets naturally flushed out of the pipeline
each time an interrupt happens (which causes a task switch, even if
it is a "switch" to the same task).

-- 
                                                          - Warp

Post a reply to this message