 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] trf de> 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
|
|
| |
| |
|
|
|
|
| |
