For those interested, please visit http://www.povray.org/beta/rtr/

It's not very well tested (only on the systems I had available to me), so
YMMV. Expect it to have some rough edges. Please report issues here.

-- Chris

Post a reply to this message

Hi Chris,

Chris Cason wrote :
> For those interested, please visit http://www.povray.org/beta/rtr/
> 
> It's not very well tested (only on the systems I had available to me), 
so
> YMMV. Expect it to have some rough edges. Please report issues here.

It's such a pity I can't test this nice feature on my dua### [at] 125GHz
using the Altivec Multimedia Instruction Set, either under MacOSX or
Yellow Dog Linux, taking advantage of my iSight FireWire camera :(

I'm sure that Persistence Of Vision is not intended to Win users !
Furthermore for little-endian (x86 - x86_64) architectures.

Do you really mind the huge amount of work that will need to be done ?

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

Wow... OK, that's pretty far-out.

Now I see what you wanted a webcam for. ;-)

Presumably you need either a trivially simple scene or a 64-core server 
to get truely "real time" performance from this...?

Post a reply to this message

Invisible wrote:
> Presumably you need either a trivially simple scene or a 64-core server 
> to get truely "real time" performance from this...?

The main sample scene (a variation of Rune's menger animation using spheres)
runs at about 12fps at 320x240 on a quad core-2 system. There's still a few
bottlenecks in the RTR pipeline, so I expect that this figure will improve
over time. Of course that is still a quite simple scene by POV-Ray standards,
but nevertheless it's interesting enough (I find it a little hypnotic actually).

Using the superellipsoids (basically the original menger sponge scene
modified to support reflection of the mapped image), a quad-core will get
roughly 3fps. not quite real-time but heading in the right direction; as
CPU's scale to more cores and our code is optimized more, even moderately
complex scenes will be able to render at lowish resolutions in real time.

-- Chris

Post a reply to this message

Invisible wrote:
> Presumably you need either a trivially simple scene or a 64-core server 
> to get truely "real time" performance from this...?

NB rendering with a single thread I still get 6fps on a core 2 system using
the menger spheres animation at 240x180 pixels. Don't be discouraged from
trying it out by the fact that it does best with a SMP system; even a single
core can do OK if you're willing to use lower resolutions.

If sufficient interest is shown in this feature over the next few betas (and
I will gauge this in part by looking at the things people are doing with it
and what scenes they come up with), I will spend more time on optimizing it.
There are a number of techniques that can be applied to speed up interactive
rendering but they involve more time than I am willing to apply to it right
at this instant.

-- Chris

NB one other possibility for the future is interactive control of the camera
position via some means - I've no idea how we could make this portable, which
is the main issue as far as I'm concerned, and if it can't be portable we may
not do it. However the code is mostly already present to allow this to happen
(in terms of being able to send a new camera position to an already-rendering
view).

Post a reply to this message

>... Please report issues here.
I don't have a webcam, but I can record from a TV signal, is this also 
supposed to work?
I get a
Failed to retrieve first pin interface for source 'Hauppauge WinTV PVR PCI
II capture'  : 0x80004002

WinXP sp2 media edition
Athlon 2x 4200+

Stephen

Post a reply to this message

StephenS wrote:
>>... Please report issues here.
> I don't have a webcam, but I can record from a TV signal, is this also 
> supposed to work?

Eventually, yes;)

> I get a 'Failed to retrieve first pin interface for source 'Hauppauge WinTV PVR PCI
> II capture'  : 0x80004002

I also have issues with a TV device (I have a digital TV card), so probably I
am not doing something in the video capture code correctly. (Unfortunately
it's all COM-based, which makes it hard to tell what's going on some of the
time). I expect I will sort this out in due course.

-- Chris

Post a reply to this message

> NB one other possibility for the future is interactive control of the camera
> position via some means - I've no idea how we could make this portable, which
> is the main issue as far as I'm concerned, and if it can't be portable we may
> not do it. However the code is mostly already present to allow this to happen
> (in terms of being able to send a new camera position to an already-rendering
> view).

I'm no C expert, but I would think that using different keypresses to 
rotate and translate the camera would be the simplest thing in terms of 
portability.

If you also add a keypress to add a "headlight" to the camera, this 
might actually be quite useful for "exploring" a scene to figure out why 
it doesn't look the way you were expecting. You sometimes find that the 
camera location you're using gives you a misleading impression of where 
you've placed stuff, or that you have things to reflect which are 
themselves out of shot, and you haven't placed them where you thought 
you did. And so on.

Still, I presume nobody is going to get realtime performance with media 
or radiosity turned on. ;-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Presumably you need either a trivially simple scene or a 64-core server 
> to get truely "real time" performance from this...?

  I haven't tested this yet, but what is your definition of "trivially
simple"? The RTR easter egg in pov3.6 is not trivially simple and runs
at a rather good framerate. Also making a simple scene in 3.6 and
animating it (by disabling console and file output for speed) still
achieves an acceptable framerate even for a bit more complex scenes,
even though the scene is parsed each time. I can only imagine that
avoiding the parsing can only speed this up even further.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> If you also add a keypress to add a "headlight" to the camera

  I wonder if this can be possible without the need to recalculate
light buffers and such. (Did 3.7 have light buffers?)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I wonder if this can be possible without the need to recalculate
> light buffers and such. (Did 3.7 have light buffers?)

No, light buffers are gone for good. they only added problems, and very,
very little benefit (less than 1%). Effectively, in most scenes using
bounding method 2 (BSP tree), you gain more than you could with light
buffers. Of course, as always, there are a few exceptions, but too few to
make light buffers worthwhile.

	Thorsten

Post a reply to this message

Invisible wrote:
> Still, I presume nobody is going to get realtime performance with media 
> or radiosity turned on. ;-)

radiosity - when completed and SMP-enabled - will not be as much of a problem
as you may think, provided that all of the samples are done in advance. after
all, one of the advantages of radiosity is that, provided you don't move any
object, the cache remains valid - even with a moved camera.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, light buffers are gone for good. they only added problems, and very,
> very little benefit (less than 1%). Effectively, in most scenes using
> bounding method 2 (BSP tree), you gain more than you could with light
> buffers. Of course, as always, there are a few exceptions, but too few to
> make light buffers worthwhile.

  Then, in theory, it could be possible to attach a light source to
each of the cameras in the clockless animation mode?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Then, in theory, it could be possible to attach a light source to
> each of the cameras in the clockless animation mode?

technically yes, but we lose the benefits of bounding then (i.e. the light
would have to be placed into the list of infinite objects). either that, or
some sort of manipulation of bounding information would need to occur each
time the camera moved outside of its previous bounding volume.

that said, though, if we say that the light is always at the eye point, we
could take advantage of the fact that we are already tracing a ray from that
point out into the scene, and thus anything that the primary ray intersects
then is by definition visible to the light source - meaning we don't need to
test it separately.

-- Chris

Post a reply to this message

I note I forgot to recommend using BSP trees for bounding in the initial
version of the test scenes in the zip. this has been fixed now, but if you
got the early version, I suggest you add +bm2 or Bounding_Method=2 to your
parameters.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> For those interested, please visit http://www.povray.org/beta/rtr/
>
> It's not very well tested (only on the systems I had available to me), so
> YMMV. Expect it to have some rough edges. Please report issues here.
>
> -- Chris

This is *great*!

I'm often in a situation where I have a reasonably simple scene that I
intend to animate, and want to preview it at some speed while maintaining
surface texture quality. Parsing tends to make up a large fraction of the
render time in some of these cases; it can even dominate. Being able to use
RTR as a sort of rapid flyby/flyaround mode is brilliant! I got about 1fps
at 160x128 on a complex scene involving complex meshes, refraction,
transparency, image maps and so on, which is many times faster than what
I'd get if I wanted to do the equivalent in 3.6 (due to the repeated
parsing). The machine is a lowly 2.4GHz P4.

The only outright issue I noticed was the first run on the RTR menger
example scene, when in my eagerness I forgot to set use_vidcap to 0 (I
don't have a webcam or other video source). This caused an "Access
violation exception" dialog to be shown, followed by an orderly shutdown of
POVWin. Setting use_vidcap to 0 removed the problem. I can reproduce this
problem on demand, should you want a dumpfile at this stage.

Tom

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> I got about 1fps
> at 160x128 on a complex scene involving complex meshes, refraction,
> transparency, image maps and so on

  It'd be interesting to know how much it speeds up if you use the
quality parameter (+q) to turn off the slowest features.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Tom York <alp### [at] zubenelgenubi34spcom> wrote:
>> I got about 1fps
>> at 160x128 on a complex scene involving complex meshes, refraction,
>> transparency, image maps and so on
> 
>   It'd be interesting to know how much it speeds up if you use the
> quality parameter (+q) to turn off the slowest features.

also worth trying is BSP (if not already in use) and also definitely
max_trace_level.

-- Chris

Post a reply to this message

>>Presumably you need either a trivially simple scene or a 64-core server 
>>to get truely "real time" performance from this...?
> 
> 
>   I haven't tested this yet, but what is your definition of "trivially
> simple"?

Well, that's the key really, isn't it?

I was thinking along the lines of something that doesn't involve any 
surfaces more complicated than quadratic, no surface texturing of any 
kind, no reflection or refraction, no media, radiosity, photons or focal 
blur, and a fairly small number of objects ( < 500 or so). That, 
presumably, should be simple enough to run in realtime.

In fact, I've built scenes like this, and as you say, if you turn off 
enough stuff you can get "almost realtime" rendering if your PC is a big 
enough brute. And yes, I would imagine disabling the parser makes it 
faster still. (Although on the other hand, how long does it take to 
parse half a page of text?)

Now if you could get a *cluster* of PCs to chew on the problem in 
parallel, you might be able to render "non-trivial" scenes in almost 
realtime. (I would think for faster speeds the network overhead would 
loose more than the extra CPU power gains.) As I understand it, there is 
absolutely no plan whatsoever to add this kind of thing to POV-Ray - at 
least, not in this release anyway.

Post a reply to this message

>>Still, I presume nobody is going to get realtime performance with media 
>>or radiosity turned on. ;-)
> 
> 
> radiosity - when completed and SMP-enabled - will not be as much of a problem
> as you may think, provided that all of the samples are done in advance. after
> all, one of the advantages of radiosity is that, provided you don't move any
> object, the cache remains valid - even with a moved camera.

Actually, that's an interesting point... Would presumably mean the very 
first frame still takes 20 minutes, and all the subsequent ones are 
reasonably fast unless/until you expose new geometry.

Hmm... would be an interesting idea to let POV-Ray finish drawing the 
frame without taking all the radiosity samples it would normally like, 
and incrimentally add those as subsequent frames are drawn... OTOH, that 
would probably be fairly complicated to code.

Post a reply to this message

>>  Then, in theory, it could be possible to attach a light source to
>>each of the cameras in the clockless animation mode?
> 
> 
> technically yes, but we lose the benefits of bounding then (i.e. the light
> would have to be placed into the list of infinite objects). either that, or
> some sort of manipulation of bounding information would need to occur each
> time the camera moved outside of its previous bounding volume.
> 
> that said, though, if we say that the light is always at the eye point, we
> could take advantage of the fact that we are already tracing a ray from that
> point out into the scene, and thus anything that the primary ray intersects
> then is by definition visible to the light source - meaning we don't need to
> test it separately.

Ah, the joys of programming... features that sound easy sometimes 
aren't. And features that sound hard are sometimes easy... ;-)

Post a reply to this message

Invisible wrote:
> Actually, that's an interesting point... Would presumably mean the very 
> first frame still takes 20 minutes, and all the subsequent ones are 
> reasonably fast unless/until you expose new geometry.

well, it might be interesting to work this out at some point ... if you were
comparing a scene lit completely with radiosity (and presuming that the
radiosity cache had already been built) against one with several traditional
point light sources, at what point does the savings of not having to trace a
shadow ray overcome the cache lookup time?

I would suspect that the answer is 'very early', except perhaps in very
simple scenes with little geometry. The more geometry is there, the more time
spent doing lookups of the bounding structure (BVH or BSP) against each
shadow ray - the more light sources, the more time, with the relationship
being fairly linear.

the rad cache lookup, however, would not suffer from this problem.

therefore it is entirely possible that, as counterintuitive as it may seem,
there is potential for a scene with global illumination to be *faster* in
interactive rendering than one without.

-- Chris

Post a reply to this message

Invisible wrote:
> Now if you could get a *cluster* of PCs to chew on the problem in 
> parallel, you might be able to render "non-trivial" scenes in almost 

You may find the paper "An Application of Scalable Massive Model Interaction
using Shared-Memory Systems" from http://www.cs.utah.edu/~boulos/research.htm
an interesting read. (They used 64 or 128-CPU machines with 64gb of RAM for
interactive rendering of a 350 million polygon aircraft model). There's also
some other papers on distributed rendering on that page.

-- Chris

Post a reply to this message

>>Actually, that's an interesting point... Would presumably mean the very 
>>first frame still takes 20 minutes, and all the subsequent ones are 
>>reasonably fast unless/until you expose new geometry.
> 
> 
> therefore it is entirely possible that, as counterintuitive as it may seem,
> there is potential for a scene with global illumination to be *faster* in
> interactive rendering than one without.

That's the pretty interesting point... global illumination might 
actually be faster. At least, *after* the cache has been built. (For a 
single frame, the time taken to build the cache usually makes the 
overall rendertime [drastically] slower than "normal mode". But if 
you're reusing that data for an animation... sure.)


OOC, how does POV-Ray efficiently retrive radiosity samples during 
rendering? (I thought about writing a renderer myself, but I couldn't 
think of a fast lookup algorithm.) Presumably the same problem applies 
to photon maps also...?

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> therefore it is entirely possible that, as counterintuitive as it may seem,
> there is potential for a scene with global illumination to be *faster* in
> interactive rendering than one without.

  It's easier to understand when one knows how the global illumination
algorithm works in POV-Ray, and how radiosity works in scanline-rendering.
In the latter, global illumination is precalculated into lightmaps, and
these lightmaps are then just used as texture modifiers on the object
surfaces (this is very fast because of hardware support). Rendering using
lightmaps is much faster than using dozens of light sources.

  The data structure used by POV-Ray to store global illumination samples
is not very far from a lightmap. It's a kind-of "sparse 3D lightmap".
Retrieving values from that data structure is not slow, and thus once it
has been sufficiently calculated (ie. no more illumination samples are
necessary), rendering becomes quite fast, especially if there are no
light sources.

  (Of course the main problem with this technique has to do with the
"sparse" part. When samples are too far apart, illumination will be
quite inaccurate.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> > I got about 1fps
> > at 160x128 on a complex scene involving complex meshes, refraction,
> > transparency, image maps and so on
>
>   It'd be interesting to know how much it speeds up if you use the
> quality parameter (+q) to turn off the slowest features.
>
> --
>                                                           - Warp

I did some more precise testing today. The scene involves a 180 degree pan
that starts with the camera point at several complicated (self-shadowing)
mesh objects. The pan then crosses two largely empty regions (just a
procedural background texture) with a few meshes appearing here and there,
and then finally ends up pointing at a large object made of meshes, and
torii/cylinders/other finite solid primitives. There is a lot of refraction
going on at the end, although the refracting surface is just a simple cone.
As expected, the frame rate is quite variable.

I used 100 cameras and let the animation run over 600 frames at 160x128. I
also turned on hyperthreading in the PC's BIOS settings, since I was a bit
curious to see if anything would happen (I disabled it a long time ago
since some software didn't like it). It may have done absolutely nothing
(can't be sure as I wasn't careful with the timing yesterday).

The scene data is about 16 million tokens worth, plus some large (2048x2048,
24 bit) image maps, and takes about 30-40 seconds to parse. Initially,
max_trace_level was set to 20 (what was used in the original scene) and the
+Q quality setting was left at default (full quality). That's the "base"
figure:

1) Base: 1.7-1.8 fps
2) With +Q2: 2.8 fps
3) With max_trace_level 5: 1.7-1.8 fps
4) With max_trace_level 2: 1.8 fps
5) With max_trace_level 1: 1.8-1.9 fps

The fps values quoted above came from the average reported in the status bar
after 600 frames. The average was reasonably stable after 600 frames,
although it sometimes varied enough that I've stated a range of values
where necessary.

The aspects of +Q2 that had the most effect on speed were presumably the
elimination of shadows and refractive surfaces. max_trace_level 1
eliminates the refraction, I guess, so perhaps that leaves shadows as the
most time-consuming feature. On the other hand, the refraction is only
present at the end, but there are shadowed objects through most of the
animation. Visually, at 160x128 there is not much difference between +Q2
and full quality; the absence of refraction is the most noticable effect.

Tom

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> In fact, I've built scenes like this, and as you say, if you turn off
> enough stuff you can get "almost realtime" rendering if your PC is a big
> enough brute. And yes, I would imagine disabling the parser makes it
> faster still. (Although on the other hand, how long does it take to
> parse half a page of text?)

I know that my use case probably isn't the same as the one this feature was
intended for. But consider that with 3.6 if I want to render 100 frames of
the scene I've been using here, just to check that the textures/finishes
look good in some sort of motion, POV spends ~30 seconds per frame simply
parsing and loading stuff that doesn't change from frame to frame. That's
at least 50 minutes spent before I even add rendering. Meshes often take a
relatively long time to parse but render very quickly (at least in my
experience) compared to some other primitives, so it can be quite easy to
get in a situation where parsing makes up 50% of the total time to produce
an animation. When the parsing isn't necessary (as in a preview of
materials), it just seems like a waste of energy and HDD light.

Tom

Post a reply to this message

FYI, some tests:

  http://www.legitreviews.com/article/412/10/
  http://www.legitreviews.com/article/412/19/

-- Chris

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> I
> also turned on hyperthreading in the PC's BIOS settings, since I was a bit
> curious to see if anything would happen (I disabled it a long time ago
> since some software didn't like it). It may have done absolutely nothing
> (can't be sure as I wasn't careful with the timing yesterday).

  My experience is that hyperthreading in a Pentium4 gives about 10-20%
speedup with POV-Ray 3.7.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason wrote:
> For those interested, please visit http://www.povray.org/beta/rtr/
> 
> It's not very well tested (only on the systems I had available to me), so
> YMMV. Expect it to have some rough edges. Please report issues here.
> 
> -- Chris

 From that page: "If your computer does not have SSE2, the program will 
crash."

Although I'd love to test it out myself, I probably wouldn't be using 
for anything useful, and my machine would croak on it anyway.  Oh well, 
just another reason* for me to upgrade :)

...Chambers


*as if I didn't have enough reasons already...

Post a reply to this message

I have always been kind of fond of scenes/advanced/piece3/piece3.pov
It's not only a classic from the early past of POV-Ray, but a comment
in it is really telling:

// Rendering time using a 25Mhz 386 w/Cyrix fpu is approximately 60 hours.

  This is a really excellent testament on how much computers have advanced
since those times. Current top-line PCs can render this scene at a high
resolution in question of seconds.
  In fact, now it can be raytraced almost in real-time. I suppose Truman's
jaw would have dropped if he had seen that after he waited 60 hours for
the render to finish.

  For a nice animation of this scene, open scenes/advanced/piece3/piece3.pov
and substitute the camera block with this:

#declare Clock=0;
#while(Clock<1)
camera {
   location  <  7.0,     50.0+10*sin(4*pi*Clock), -30.0 >*(1+.5*sin(2*pi*Clock)) /* Up
high and in close.         */
   direction <  0.0,      0.0,   2.0 > /* Though this doesn't highlight */
   up        <  0.0,      1.0,   0.0 > /* the height of the piece, it   */
   right     <  4/3,      0.0,   0.0 > /* gives the effect i'm looking  */
   look_at   <  0.0,     15.0,   0.0 > /* for.  Feel free to change.    */
   rotate y*Clock*360
}
#declare Clock=Clock+.01;
#end

and then render with eg. +w320 +h240 +bm2 +rtr +kla

-- 
                                                          - Warp

Post a reply to this message

Gave that a try and it rendered at half frame per second with a Pentium 4-M 
2.0 GHz.

I had to see it going faster so I changed to a tiny resolution of 40x30 and 
saw it doing 30+ FPS. Not easy to see but great to watch it animate in "real 
time".

Makes a person dream of previewed scenes while broswing through files. What 
chance would there be of parsing files and saving a renderable state ready 
for preview?

Post a reply to this message

Bob H <omniverse@charter%net> wrote:
> Gave that a try and it rendered at half frame per second with a Pentium 4-M 
> 2.0 GHz.

  Rendered at about 1fps in my 3.4GHz P4. I suppose in the newest intel
quad-core it would render at least at 10fps or more.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bob H <omniverse@charter%net> wrote:
> > Gave that a try and it rendered at half frame per second with a Pentium 4-M
> > 2.0 GHz.
>
>   Rendered at about 1fps in my 3.4GHz P4. I suppose in the newest intel
> quad-core it would render at least at 10fps or more.
>
> --
>                                                           - Warp


I renderd 300 Frames of the Scene on a Core 2 Duo E6400 @2.13 Ghz.
Result: 2.25 Frames/Second.

Projected on a QX6700(? the Quad-Core with 2,66 Ghz) it would be ~5,6 fps,
accourding the first Benchmarks with Pov (somewhere in the latest news)

-- Thomas

Post a reply to this message

"Schwan379" <nomail@nomail> wrote in message 
news:web.454b88d3bf0a728b9d30be920@news.povray.org...
>
> I renderd 300 Frames of the Scene on a Core 2 Duo E6400 @2.13 Ghz.
> Result: 2.25 Frames/Second.

Good to know, my next notebook might have a C2D in it. I had looked at 
benchmarks for those and they seem to do great for most things except maybe 
floating point. Intel never wins those FP benchmarks, you know.

Post a reply to this message

"Bob H" <omniverse@charter%net> wrote:
> "Schwan379" <nomail@nomail> wrote in message
> news:web.454b88d3bf0a728b9d30be920@news.povray.org...
> >
> > I renderd 300 Frames of the Scene on a Core 2 Duo E6400 @2.13 Ghz.
> > Result: 2.25 Frames/Second.
>
> Good to know, my next notebook might have a C2D in it. I had looked at
> benchmarks for those and they seem to do great for most things except maybe
> floating point. Intel never wins those FP benchmarks, you know.

Its a "normal" CPU, no Notebook-CPU.
The "normal" C2D winns those FP Benchmarks afaik - until the next Athlon...

Post a reply to this message

"Schwan379" <nomail@nomail> wrote in message 
news:web.454bbae1bf0a728bb6c403170@news.povray.org...
>> >
>> > I renderd 300 Frames of the Scene on a Core 2 Duo E6400 @2.13 Ghz.
>> > Result: 2.25 Frames/Second.
>>
>> Good to know, my next notebook might have a C2D in it. I had looked at
>> benchmarks for those and they seem to do great for most things except 
>> maybe
>> floating point. Intel never wins those FP benchmarks, you know.
>
> Its a "normal" CPU, no Notebook-CPU.
> The "normal" C2D winns those FP Benchmarks afaik - until the next 
> Athlon...

Ok, that explains the "E6400".  :)  I had been looking at the T7200, T7400 
and T7600.

There was one chart showing a C2D scoring lower on (memory?) FP than a AMD 
processor, no idea where that is now. I've found out Intel might have an 
improved mobile C2D in the works, basically increasing the FSB speed yet 
still not equaling their desktop cousins.

This old notebook of mine is what determines when I must get a new one while 
it slowly falls apart.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> FYI, some tests:
>
>   http://www.legitreviews.com/article/412/10/
>   http://www.legitreviews.com/article/412/19/
>
> -- Chris

Chris, I love this idea and the fact that you made it real. I had an idea
for MegaPOV XRS to avoid reparsing the scene if only the camera changed,
but this takes that concept to a whole new level! I can't do this with
MegaPOV XRS just yet... touche ;-)

Rock on,
George
http://www.gammaburst.net

Post a reply to this message

> For those interested, please visit http://www.povray.org/beta/rtr/
>
> It's not very well tested (only on the systems I had available to
> me), so YMMV. Expect it to have some rough edges. Please report
> issues here.

The test scenes crashed POV because I had no video capture device installed 
(changing the pigment to something other than video capture works fine). 
Just installed my webcam and works ok now.  If I unplug the webcam it 
crashes again with access violation.

How difficult would it be to provide the output from the RTR as another 
"video" device within windows?  Could allow you to use POV as a sort of 
video processor and allow cool effects for using your webcam within MSN 
messenger and so on.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Invisible wrote:
> > Actually, that's an interesting point... Would presumably mean the very
> > first frame still takes 20 minutes, and all the subsequent ones are
> > reasonably fast unless/until you expose new geometry.
>
> well, it might be interesting to work this out at some point ... if you were
> comparing a scene lit completely with radiosity (and presuming that the
> radiosity cache had already been built) against one with several traditional
> point light sources, at what point does the savings of not having to trace a
> shadow ray overcome the cache lookup time?
>
> I would suspect that the answer is 'very early', except perhaps in very
> simple scenes with little geometry. The more geometry is there, the more time
> spent doing lookups of the bounding structure (BVH or BSP) against each
> shadow ray - the more light sources, the more time, with the relationship
> being fairly linear.
>
> the rad cache lookup, however, would not suffer from this problem.
>
> therefore it is entirely possible that, as counterintuitive as it may seem,
> there is potential for a scene with global illumination to be *faster* in
> interactive rendering than one without.
>
> -- Chris


I used the POV-Ray 3.6 Radiosity Demoscene with the "fast"- Radiositysetting
to test it...
To get a "real" Framerate for Radiosity I tried measure the time to render
the Frames 400 to 900. The Result was about 4,23 FPS at 160x120 Pixels.
I started after a few complete loops at Frame 400 to be sure, that all
necessary Radiositysamples are calculated.
Withour Radiosity, only with the "Light 2", I get about 11,5 FPS at 160x120
Pixels.

I know that the Radiosity is very alpha (it works in this scene) - how much
faster it may get until the next full release?

-- Thomas

Post a reply to this message