 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV-Ray 3.7.beta.12a is available from http://www.povray.org/beta/. This is a
small update to beta 12 which provides significant improvement for BSP trees
on large scenes, as well as fixing a problem with missing objects. For most
scenes, the BSP tree should now provide faster renders than the default BVH.
Additionally support for the new render window has been removed, at least for
now, due to the previously-mentioned performance issues. This also means that
the EXE should work on Windows 95 again.
Changes between 3.7.beta.12 and 3.7.beta.12a
--------------------------------------------
Fixed issue with BSP that caused long build times on large trees.
Changed default BSP child access cost to 5.0 (was 1.5).
Fixed issue with BSP trees that would cause some objects to vanish.
Added an optimization which speeds up BSP renders.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You can load the appropiate DLL at runtime to execute
SetLayeredWindowAttributes if a Windows 2000 or better OS is found.
Therefore, is users use POV under Win98/Win95 it wouldn't load the
function.
Chris Cason <del### [at] deletethistoo povrayorg> wrote:
> POV-Ray 3.7.beta.12a is available from http://www.povray.org/beta/. This is a
> small update to beta 12 which provides significant improvement for BSP trees
> on large scenes, as well as fixing a problem with missing objects. For most
> scenes, the BSP tree should now provide faster renders than the default BVH.
>
> Additionally support for the new render window has been removed, at least for
> now, due to the previously-mentioned performance issues. This also means that
> the EXE should work on Windows 95 again.
>
> Changes between 3.7.beta.12 and 3.7.beta.12a
> --------------------------------------------
>
> Fixed issue with BSP that caused long build times on large trees.
> Changed default BSP child access cost to 5.0 (was 1.5).
> Fixed issue with BSP trees that would cause some objects to vanish.
> Added an optimization which speeds up BSP renders.
>
> -- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MongeGapper wrote:
> You can load the appropiate DLL at runtime to execute
> SetLayeredWindowAttributes if a Windows 2000 or better OS is found.
> Therefore, is users use POV under Win98/Win95 it wouldn't load the
> function.
I'm aware of that; I use that technique in numerous places in POVWIN.
I simply didn't bother because the feature has other issues and it was
better to just pull it out entirely.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Something that changed between 11c and 12a (didn't get to 12 in time) broke
balcony.pov - the glass is now full of clear liquid instead of purple...
Don't know quite what could cause that, but didn't see anything listed in
the changes nor known issues that jumped out at me about it. I've tried
with a few different combinations of settings (like AA on / off, the new
B2, etc) and it's the same each time.
Warp had mentioned a problem with bwstripe.pov, which is wow very different,
but I don't have a copy of 11c around anymore to tell whether it's a
difference between 3.6 and 3.7 in general or just 7.11 and 7.12; the liquid
in the glass though is definitely different between 11c and 12a, though.
Just noticed that wineglass.pov renders differently too, though the color is
still present in the liquid. The checkerboard pattern is reversed (white
and black squares are switched). Weird.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ooooo, and +B2 breaks sombrero.pov (right half gets cut off completely!).
Wallstucco looks a little bit different, too (not related to +B2). All of
these are in scenes/advanced, btw, for those who don't know and are curious
to see.
I just redownloaded 11c, I'll put in on later tonight and see if I can find
out what's different in these renders *specifically* between 11 and 12
(most are probably 3.6->3.7 differences though, I'd guess.)
-d
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason nous apporta ses lumieres en ce 29/03/2006 06:10:
> POV-Ray 3.7.beta.12a is available from http://www.povray.org/beta/. This is a
> small update to beta 12 which provides significant improvement for BSP trees
> on large scenes, as well as fixing a problem with missing objects. For most
> scenes, the BSP tree should now provide faster renders than the default BVH.
>
> Additionally support for the new render window has been removed, at least for
> now, due to the previously-mentioned performance issues. This also means that
> the EXE should work on Windows 95 again.
>
> Changes between 3.7.beta.12 and 3.7.beta.12a
> --------------------------------------------
>
> Fixed issue with BSP that caused long build times on large trees.
> Changed default BSP child access cost to 5.0 (was 1.5).
> Fixed issue with BSP trees that would cause some objects to vanish.
> Added an optimization which speeds up BSP renders.
>
> -- Chris
I can't tell for all the cases, but running tango.pov on 3.7 and 3.6 show huge
performance
improvement. With +b2, it's more than twice as fast as 3.6!
3.6.1 54:22
3.7 -b2 36:12
3.7 +b2 25:28
Single core single CPU.
--
Alain
-------------------------------------------------
Church of SubGenius: BoB shits.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Before anybody else asks... is there a good article somewhere that
explains what BSP is, and why it's good?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Before anybody else asks... is there a good article somewhere that
> explains what BSP is, and why it's good?
http://en.wikipedia.org/wiki/Binary_space_partition_tree
Cheers,
Bonsai
--
<--------------------------->
___ __ __ _ ___ ___ _
| _ ) \ \( ) _) _ )( )
| _ \() |\ \ |\ \/ _ \| |
|___/__/_)\__)___)/ \_)_)
www.b0n541.net
<--------------------------->
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> POV-Ray 3.7.beta.12a is available from http://www.povray.org/beta/. This is a
> small update to beta 12 which provides significant improvement for BSP trees
> on large scenes, as well as fixing a problem with missing objects. For most
> scenes, the BSP tree should now provide faster renders than the default BVH.
>
> Additionally support for the new render window has been removed, at least for
> now, due to the previously-mentioned performance issues. This also means that
> the EXE should work on Windows 95 again.
>
> Changes between 3.7.beta.12 and 3.7.beta.12a
> --------------------------------------------
>
> Fixed issue with BSP that caused long build times on large trees.
> Changed default BSP child access cost to 5.0 (was 1.5).
> Fixed issue with BSP trees that would cause some objects to vanish.
> Added an optimization which speeds up BSP renders.
>
> -- Chris
Heyy Congratulation! This method is very fast (%50). I need povray's consol
version for the adaptation to my drawing program like yafray or megapov. is
this possible?
Best Regards.
Hasan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hasan3 <PRO### [at] yahoocom> wrote:
> I need povray's consol
> version for the adaptation to my drawing program like yafray or megapov. is
> this possible?
Wait for the final release.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
With respect to the report of sombrero.pov breaking with +b2:
"LoneStar" <nomail@nomail> wrote:
> Ooooo, and +B2 breaks sombrero.pov (right half gets cut off completely!).
>
It turns out that the behaviour changes significantly with changes to the
value for NumIterations: 1-10 show only the left half; 11-13,15 render OK;
14 gives a small distortion in the top-middle; 16 gives black distortions
all along the middle vertical. At higher values you get ever changing but
similar distortions.
I've tried a couple of changes to see where the error originates;
hand-calculating Increment, not using all the translations (for instance
everyting is on y=0 instead of rippled), using different ranges for Xc and
Zc, removing the union { } block, using "sphere { 0,1 }" instead of the
BasicShape definition inside the loops, removing the object { } block. In
all these cases the distortions remain the same.
All attempts using the same changes & values for NumIterations without +b2
seem to give no problem at all.
Jeroen.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
LoneStar wrote:
> Ooooo, and +B2 breaks sombrero.pov (right half gets cut off completely!).
Fixed, thanks.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
LoneStar wrote:
> Something that changed between 11c and 12a (didn't get to 12 in time) broke
> balcony.pov - the glass is now full of clear liquid instead of purple...
fixed, thanks for the report.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
LoneStar wrote:
> Just noticed that wineglass.pov renders differently too, though the color is
> still present in the liquid. The checkerboard pattern is reversed (white
> and black squares are switched). Weird.
at a guess this may be related to the old half-pixel offset stuff. if you
tweak the scaling in line 225 from <30.0, 4.001, 30.0> to <30.0, 4.000, 30.0>
the issue goes away.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Before anybody else asks... is there a good article somewhere that
>> explains what BSP is, and why it's good?
>
>
> http://en.wikipedia.org/wiki/Binary_space_partition_tree
Just says that BSP involves recursively subdividing space and storing
the chunks in a binary tree. Doesn't really explain why this would be
useful for the purpose of raytracing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> Before anybody else asks... is there a good article somewhere that
>>> explains what BSP is, and why it's good?
>>
>>
>> http://en.wikipedia.org/wiki/Binary_space_partition_tree
>
> Just says that BSP involves recursively subdividing space and storing
> the chunks in a binary tree. Doesn't really explain why this would be
> useful for the purpose of raytracing.
put simply it's a fast way of finding what objects occupy a given region of
3d space irregardless of the origin and direction of the ray being shot. each
leaf node of a tree represents a particular (possibly overlapping) volume and
contains a list of all objects that potentially occupy that volume (in terms
of their bounding boxes).
so, if we have a start and end point of a ray, and then determine which nodes
the ray crosses through, we have available a list of all objects that it can
possibly intersect. as a general rule, the fewer objects per node the better,
though there would be a point where the time taken to iterate a deep tree may
exceed the time taken to test the bounds of each of the objects in a higher-
level node with multiple objects.
in the ray-tracing community there has for some time been some argument over
the various merits of the BVH (our standard bounding method) vs BSP, with
some folks being strongly pro-BSP, and others usually in the middle (there
don't seem to be a lot of anti-BSP'ers out there:). There's little doubt that
BSP is a very useful technique, but IMO BVH (bounding volume hierarchy) isn't
as bad as some folks seem to think - POV-Ray has done quite well with it for
a long time and it's quite memory-efficient.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> put simply it's a fast way of finding what objects occupy a given region of
> 3d space irregardless of the origin and direction of the ray being shot. each
> leaf node of a tree represents a particular (possibly overlapping) volume and
> contains a list of all objects that potentially occupy that volume (in terms
> of their bounding boxes).
>
> so, if we have a start and end point of a ray, and then determine which nodes
> the ray crosses through, we have available a list of all objects that it can
> possibly intersect. as a general rule, the fewer objects per node the better,
> though there would be a point where the time taken to iterate a deep tree may
> exceed the time taken to test the bounds of each of the objects in a higher-
> level node with multiple objects.
So is traversing a BSP tree faster than testing a ray against some
arbitrary bounding box then? Because at the moment, I'm having
difficulty seeing how dividing space into smaller and smaller "halves"
is drastically different from just having bounding boxes inside bounding
boxes...
If you have some insane isosurface object, it's going to take forever to
trace it no matter what bounding algorithm you use. As I see it, there
are two main cases where bounding makes things faster:
* You have some object that's slow to do intersection tests on, but
doesn't take up much of the scene (i.e., you ought to be able to skip
the intersection test for most rays)
* You have millions of tiny objects. (Most rays will only hit a few of
them, but testing them all would take forever. A good bounding algorithm
would skip most of these tests.)
As I understand it, the BVH intersection algorithm goes something like this:
+ Test the ray against the top-level BBs. (Hopefully there are few of
those.)
+ If any are intersected, test the ray against the BBs they contain.
Recurse until actual object surfaces are tested. Keep all intersections
found.
Presumably, the BSP algorithm would go
+ Test ray against the left and right halfs of the top-level box.
+ If either is hit, recurse into sub-boxes (as with BVH).
I'm clearly missing something, because those two don't look
significantly different. (Obviously, the performance of each is going to
depend on how well the algorithm that builds the bounding structure does
its job.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>
> If you have some insane isosurface object, it's going to take forever to
> trace it no matter what bounding algorithm you use.
Not necessarily but creating a tight fitting bounding (no matter if
using BVH or BSP) is difficult for arbitrary isosurfaces. See:
http://www.imagico.de/fast_iso/patch.html
Concerning which method is 'better' - that quite definitely depends on
the scene. And note in POV-Ray the BVH method is combined with Vista
and Light buffers which can speed up things quite a lot in some cases.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 14 Mar. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> If you have some insane isosurface object, it's going to take forever
>> to trace it no matter what bounding algorithm you use.
>
>
> Not necessarily but creating a tight fitting bounding (no matter if
> using BVH or BSP) is difficult for arbitrary isosurfaces.
I once wrote my own system for splitting an isosurface into a grid of
"chunks", so POV-Ray would only sample the function near its surface. I
had constant problems avoiding holes in the surface! :-\
> Concerning which method is 'better' - that quite definitely depends on
> the scene.
Really? I find that supprising. (And one immediately wanders which kinds
of scene each one is "best" at...)
> And note in POV-Ray the BVH method is combined with Vista
> and Light buffers which can speed up things quite a lot in some cases.
Indeed - but it only accelerates camera rays and shadow rays. As soon as
you have any reflection or refraction on your scene (or a weird camera
for that matter) these speedups can't help you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> http://www.imagico.de/fast_iso/patch.html
Tangentally related to the current beta, but... I once though about the
isosurface tracing algorithm. If I evaluate the function at a particular
point in space and the result is a large positive value, then given that
value and the max_gradiant, I know that there can be no surface within a
sphere of some radius centered at that point.
If POV-Ray would cache this information, we could potentially save a
hell of a lot of function evaluations. (For example, if the whole length
of the ray falls within these "empty" spheres, then the ray clearly
strikes no surface, and there's nothing to evaluate!)
OTOH, how much effort does it take to test a ray against a growing
multitude of spheres?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> http://www.imagico.de/fast_iso/patch.html
>
> Tangentally related to the current beta, but... I once though about the
> isosurface tracing algorithm. If I evaluate the function at a particular
> point in space and the result is a large positive value, then given that
> value and the max_gradiant, I know that there can be no surface within a
> sphere of some radius centered at that point.
POV-Ray already uses this information (slightly different, the exact use
of this idea is called sphere tracing (see the link list on my page).
But this is only done on a per-ray basis. Using it globally would
require a spatial data structure to store this information for efficient
access (it would be quite similar to the radiosity irradiance cache and
would have exactly the same troubles).
The main additional problem would be that the time required for storing
and querying this information in a lot of cases will exceed the time
required for an additional function evaluation (in radiosity we store
the result of tracing 'count' rays for every sample, here it would be
only the function value).
And note the number of function evaluations (and therefore the resulting
size of the cache) would be extremely large (easily several billions for
a large render).
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 14 Mar. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Presumably, the BSP algorithm would go
>
> + Test ray against the left and right halfs of the top-level box.
>
> + If either is hit, recurse into sub-boxes (as with BVH).
There are numerous optimizations available when traversing a BSP tree. Each
node is either a splitting node or a leaf node. Leaf nodes contain a list of
all objects that could potentially occupy the volume the node represents,
whilst splitting nodes contain an axis (X, Y or Z), the plane (float), and
references to two child nodes. It's important to note here that it does *not*
contain a bounding box - the only spatial information is the splitting plane
and axis.
Given a specific node, and its two children ('left' and 'right' in BSP
parlance), the traversal algorithm knows the following:
a) any object whose bounding box, on the active axis, ends on or before
the splitting plane, will be found by traversing the left node.
b) any object whose bounding box straddles the splitting plane will be
found by traversing either node.
c) any object whose bounding box, on the active axis, starts after the
splitting plane, will be found by traversing the right node.
Objects are listed as an index in a list, not by a pointer. The list index is
also used as an index into a bitmap (aka 'mailbox'); whenever, in the process
of traversing a BSP tree, it is necessary to perform an intersection test on
an object (recalling that an object can be listed in multiple nodes), its bit
is set. This bit is checked before attempting an intersection test and thus
repeating the test is avoided during the same traversal.
As you can see, one of the advantages of a BSP is that at each splitting node
you only have to determine if the origin of the ray is before or after the
splitting plane, and if the end point within the volume of the node is on the
left or right of the splitting plane. Thus iteration can be quite efficient.
To assist even further, two of the three values (distance from ray origin to
splitting plane, distance to bounding volume start, and distance to bounding
volume end) needed to make the iteration decision are available from the
previous level, thus (with the exception of comparisons) there is only one
floating-point calculation needed at each splitting node.
Another significant advantage worth mentioning is that it is possible to
trivially iterate the tree in a loop rather than using a recursive algorithm.
-- Chris
N.B. the volume occupied by each node is known despite the fact that no
bounding boxes are stored in the tree; it is derived from the top-level scene
bounding box - which is passed to the traversal algorithm - and the splitting
planes, which as the tree is traversed are used to iteratively reduce the volume.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
