|
 |
POV-Ray 3.7.beta.4 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.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
|
|
|
|
Warp wrote:
>> Chris Cason <nos### [at] deletethis povrayorg> wrote:
>
>>>> unfortunately to fix it I had to restore the old (buggy) clipping behaviour
>>>> of quadrics, however as this has been present for many years it should
not be
>>>> a major problem.
>
>>
>> I'm not aware of such bug. Could you explain in more detail?
The issue is that a quadric (not all types, just some) that is clipped_by
another object will potentially return a smaller bounding box than either
that of the object or its original clipping region. This is particularly
evident if you render a scene with and without bounding slabs. Here's an example:
---------------------------------------------------------------------------
#include "colors.inc"
#include "textures.inc"
global_settings { assumed_gamma 2.2 }
camera {
location <0, 50, -20>
direction <0, 0, 10>
look_at <0, 0, 0>
}
light_source { <0, 10, -20> color White*2 shadowless }
plane { z, 10 pigment {checker color White color rgb <1,.8,.8>}hollow on }
#declare UnitBox = box { <-1, -1, -1>, <1, 1, 1> }
quadric {
<-1, 0, 1>, <0, 0, 0>, <0, 1, 0>, 0
pigment { Blue }
finish { ambient 0.1 }
clipped_by{object{UnitBox scale <2,2,2>}}
}
#if (1)
box
{
<-1.4142135, -2.0000000, -1.4142135>
<1.4142135, 2.0000000, 1.4142135>
pigment { rgbft <1,0,0,0,0.75> }
}
object
{
UnitBox
scale 2
pigment { rgbft <0,1,0,0,0.75> }
}
#end
---------------------------------------------------------------------------
If you render this in v3.6 you will get a quadric that is smaller than the
clipping box in some dimensions. If you remove the clipped_by you will see
that in fact it should extend to the edges. 3.7 beta 4 handles the above
scene OK (however beta 5 will revert to the old behaviour unless it's fixed).
The green box represents the defined clipping object and the red box is
what the internal bbox calculations returned for the bounding volume once
the clipped_by had been applied.
If you turn off the two bottom objects via the #if (0) or just add -mb to the
command-line you'll see the quadric properly contained within the clipping
region.
The issue is caused by an optimization in the bounding box calculations that
attempts - for a number of different types of quadric - to determine, given a
defined clipping region in one direction (e.g. two planes), the maximum
extent of the quadric in another direction. It also does this even if the
clipping region is finite (e.g. the box given above).
The problem is that it generates this estimate (at least in this example)
with an assumed z of 0.0, ignoring the fact that it extends beyond the
calculated x value of 1.4142135 at z = -1.0 or +1.0 (and/or elsewhere, I
didn't analyze this thoroughly).
You can see this more clearly by moving the camera to <0, 50, 0> and
rendering with the boxes turned on, and with and without -mb.
While I could just return the clipping region rather than allowing the code
to optimize it this way (and in fact I made a small improvement in that area;
previously if the mixed terms were non-zero it just returned without setting
the bbox at all, now at least it will set it to the clip), the issue is that
often (e.g. in the ionic example scene you gave), the clip is performed with
planes and as such the object will still be infinite in some direction(s)
unless the calculations are done. It would appear a number of scenes depend
on the old behaviour and do not use finite clip regions (which is what my
changes had assumed).
The proper fix would be to make a more thorough estimation of extent for each
of the covered quadric types (cone, hyperboloid and paraboloid, in each of x,
y, and z axes) and return a more correct bbox.
-- Chris
Post a reply to this message
|
|
