 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 1 25GHz
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,
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
|
|
| |
| |
|
|
|
|
| |
