All of what I explore in the following came to me is sort of 
a flash one day and then I got around to running the numbers to 
see where we stand. I finally found 1124 lines resolution instead 
of the present TV standard of 525 lines and that was not as easy 
as you might think. 

     The aspect ratio and movie frames per second are correct. I 
could not find if HDTV was going to stick with 60 half frames as 
at present or going to change so I used the movie frames per 
second of 24. So if anyone wants to do their own calculations, 
those numbers are correct. 

     All the verbiage about the calculations rounded to 
convenient results. Of course, demons can still have snuck in. 

                         * * * * *

     Lets run some numbers to compare HDTV to POV-Ray. HDTV is 
1124 lines with a 16:9 aspect ratio (1998x1124 = 2,246,000) 2.25 
million pixels. This is also touted as the quality of 35mm 
movies. I question that but at least on the new TV screens I'll 
take their word for it. 

     For convenience the IRTC/medium screen resolution of 800x600 
which equals 480,000, roughly a half million pixels. 

     And the ratio of the two roughly 4.5:1. Up front, what we 
can do at home we can do in the new format 4.5 times slower. 

     Movie quality is 24 frames per second vice TV's 30 fps. Now 
we need to render 2.25x24 for one second worth of movie or 54 
million pixels. 

     However parallel processors are "hobby" projects all over 
the world. It would be nice to have 2.25 million processors in 
parallel so each could render its own pixel. On a PII 333MHz 
(128M, Win98, POV 3.1) machine only the most complex internal 
reflection scenes (a "city of glass" for example) fall below 24 
pixels per second. If we had 2.25 million processors, each could 
render its assigned pixel 24 times a second resulting in the 
required 24 frames per second. 

     If we assume that is the worse case average for a broad 
range of scenes such as we might find in a movie (noting rendered 
movies have so far stayed very far away from such complex scenes) 
we have a baseline for estimating the productivity of parallel 
processing. 

     For example, 64k processors in parallel would result in 
(2.25M/64k) 830 processor seconds per second of movie, roughly 14 
minutes per second. A two hour movie would require 1660 hours or 
about 70 days using the 24 pixels per second baseline of an Intel 
machine under Win98. This we can consider a worst case. 

     Without designing the 64k parallel machine we cannot say 
what its speed would be like but at least it should be faster 
than under Win98. As a modest estimate of the improvement we note 
that POV-Ray under Linux is approximately twice as fast. So we 
are talking 35 days per two hour movie worst case, any kind of 
scene. Or rather we can talk about 415 seconds per second of 
screen time. 

     There are other applications than movies. The 30 second 
commercial renders in three and a half hours. Ten minutes of 
fresh animation for "Babylon 5 1/2: The Revenge of Vir" in 70 
hours. And all of this under the worst case "City of Glass" 
assumption. 

     The kind of rendered scenes in B5 and the common rendered 
movies and from my POV-Ray experience (that is, my gut feel only) 
render 100 to 200 times faster. Going back to 415 seconds per 
second we have say three seconds per second. 

     Clearly, even at the research level now we are at a 
rendering speed where creation time is far greater than rendering 
time. 

     If we talk a more modest 1024 processors we go from three 
seconds per second only up to three minutes per second.

Post a reply to this message

>      However parallel processors are "hobby" projects all over
> the world. It would be nice to have 2.25 million processors in
> parallel so each could render its own pixel. On a PII 333MHz
> (128M, Win98, POV 3.1) machine only the most complex internal
> reflection scenes (a "city of glass" for example) fall below 24
> pixels per second. If we had 2.25 million processors, each could
> render its assigned pixel 24 times a second resulting in the
> required 24 frames per second.

The problem with multiple processors is that n number of x-MHz
processors aren't as fast as 1 x*n-MHz processor. I.E. they don't run at
full capacity. Two processors is a huge performance gain, four is too,
eight is ok, sixteen gets a little, thirty-two or more would be a huge
waste of money. The thing is, the graph of performance vs. processors
starts to level off after so many, because multi-processor machines
waste a lot of time with processor communication. With 1024 processors,
each processor has to "talk" to 1023 others, and there is minimal gain
over 512 or 256. You may could instead use 1024 seperate motherboards
each running a copy of POV. That would be plausible, because you would
only need the video card, monitor, CD, etc on the main system, which is
half the cost of a computer. And with the POV ability to render a
selected section of the picture, you could indeed have real-time
rendering. However, 2000000 PII's with motherboards would cost a good
billion and a half dollars, which is probably less than multiple Cray
XMPs though I really have no idea what those cost.

Post a reply to this message

Larry Fontaine wrote:

> The problem with multiple processors is that n number of x-MHz
> processors aren't as fast as 1 x*n-MHz processor. I.E. they don't run at
> full capacity. Two processors is a huge performance gain, four is too,
> eight is ok, sixteen gets a little, thirty-two or more would be a huge
> waste of money. The thing is, the graph of performance vs. processors
> starts to level off after so many, because multi-processor machines
> waste a lot of time with processor communication. With 1024 processors,
> each processor has to "talk" to 1023 others, and there is minimal gain
> over 512 or 256. You may could instead use 1024 seperate motherboards
> each running a copy of POV. That would be plausible, because you would
> only need the video card, monitor, CD, etc on the main system, which is
> half the cost of a computer. And with the POV ability to render a
> selected section of the picture, you could indeed have real-time
> rendering. However, 2000000 PII's with motherboards would cost a good
> billion and a half dollars, which is probably less than multiple Cray
> XMPs though I really have no idea what those cost.

	Agreed on all points. But I am not talking parallel in the sense
of distributed. Parallel in the sense of working on the same
project at the same time. These do not have to talk to each other
as they each would work on their own pixel. X at a time instead
of one at a time. 

	Clearly POV would be in ROM and enough RAM to hold the parsing
results  and not much more needed. Parsed input can take a few
seconds and the output is 3 bytes per pixel = cheapest ethernet
card you can find. This should be well under $300/board in
quantity even with off the shelf boards. $300,000 in hardware,
rented out at $100 to $1000 per hour? And the small boards for
embedding have been around for years. 

	Of course the "millions" of processors were just to set the
stage for small numbers of processors against creation time.
Perhaps how close we are to the holy grail of not having to pay
actors for movies.

Post a reply to this message

On Sun, 05 Sep 1999 00:28:14 -0400, Matt Giwer
<mgi### [at] giwersworldorg> wrote:
[snip]
>Perhaps how close we are to the holy grail of not having to pay
>actors for movies.

We're quite a way IMO - at least if Jar Jar is anything to go by.

Oh - and I've ot scenes (parts of an animation) with little to no
reflectivity in them which take several minutes to parse on a 64MB or
96MB PC and have been known to fall to single-digit PPS speeds (true,
sadly).


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Matt Giwer <mgi### [at] giwersworldorg> wrote in message
news:37D1DA67.232CF59B@giwersworld.org...
> (128M, Win98, POV 3.1) machine only the most complex internal
> reflection scenes (a "city of glass" for example) fall below 24
> pixels per second.

Not quite:  the pixels/second number displayed in the status bar of POV-Win
doesn't take into account supersampling.  A simple scene (the close-up of
the jar of pencils at http://www.dlugosz.com/POV/dryad_dreams.html about
half way down the page) was showing 78PPS while working, but was taking 8
times longer than I would have supposed to finish one row.  Result was
actually closer to 11 pixels/second of =result= pixels in the final image.

--John

Post a reply to this message

Cliff Bowman <c.b### [at] cwcomnet> wrote in message
news:37d4b351.42823775@news.povray.org...
> reflectivity in them which take several minutes to parse on a 64MB or
> 96MB PC and have been known to fall to single-digit PPS speeds (true,
> sadly).

Well, I hit <1 a few days ago.  That was with adaptive turned off and large
area lights, to see if that was the problem, though.  In general, a long
slow unoptomized trace lets me compare how faster ones look next to it and
choose acceptable settings.  So figure =real= slow for studies of individual
elements, and for the first frame in a scene.  Then much faster for
subsequent frames, as it can reference back to the first to make sure the
quality is consistant and no artifacts appear.

Post a reply to this message

John M. Dlugosz wrote in message <37d702fb@news.povray.org>...
>Not quite:  the pixels/second number displayed in the status bar of POV-Win
>doesn't take into account supersampling.  A simple scene (the close-up of
>the jar of pencils at http://www.dlugosz.com/POV/dryad_dreams.html about
>half way down the page) was showing 78PPS while working, but was taking 8
>times longer than I would have supposed to finish one row.  Result was
>actually closer to 11 pixels/second of =result= pixels in the final image.


The pixels/second display is a running average for the entire trace, not the
current speed.  As a result, if the first part of the trace went very fast,
then a slow part will be reported as going faster than it really is, and
vice versa.

Mark

Post a reply to this message