 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andy Cocker wrote:
>
> Ever so slightly off-topic, but I really miss the way that each pixel was
> shown as it rendered in the DOS version 2.2. I used to enjoy watching it's
> progression along each line ( sad, aren't I? :-)). Now in windows, it just
> updates the screen as each line is rendered.
Actually I rather liked that too. It helped determine where exactly on
screen it took the longest time to render. When you saw this you could
tell exactly which feature you were using slowed down the render times
the mostest.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> Or even at all. Sometimes I get the PPS rating, and others I don't, and I
> haven't found out why it does it. And no, it's not the image speed, because
> the image can be going at a good clip and still show 0. However, whenever
> it actually displays a number, it's always pretty close to right.
Could be the anti-aliasing method you're using. Method 2 always leaves the pps
counter at zero. (At least for me)
Mike Wilson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Dec 2000 20:25:16 GMT, j.l### [at] libero it (Jonathan
Rafael Ghiglia) wrote:
>The "Pixel Per Second" (PPS) counter of the editor doesn't seem to
>work properly with MegaPov, especially with images that take for ever
>to render (it remains fixed at 0 PPS). I know that the editor is
>(obviously) not meant to work with MegaPov... I was just asking to
>myself what could be the reason.
If you're using AA method 2 the counter in MP0.6a stays at 0 pps. I
recall this was a problem in official POV but it was fixed. Maybe MP
is using a slightly older version of the Windows sources.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The "Pixel Per Second" (PPS) counter of the editor doesn't seem to
> work properly with MegaPov, especially with images that take for ever
> to render (it remains fixed at 0 PPS). I know that the editor is
> (obviously) not meant to work with MegaPov... I was just asking to
> myself what could be the reason.
I am not to fussed, if i cannot see my renders rendering, there going to
slow (and get stopped, as i am usually working on the image at the time), if
i set one going for the night then go to bed - i dont really care :)
--
Rick
POVray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Actually I rather liked that too. It helped determine where exactly on
> screen it took the longest time to render. When you saw this you could
> tell exactly which feature you were using slowed down the render times
> the mostest.
You can still do this. In the Windows version, resize the render window until
the bottom scroll bar appears. Then move the cursor from time to time and the
screen will be updated as many times as the cursor is moved.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Makes me think a graph displayed in place of, or in conjunction with, numbers
would be great. Capability to do decimal pixels (uh, maybe not?) or a change
to PPM (minute) would be of benefit but a speed bar might be nice too.
Question I guess is how to display graphically. 0 to 100% is no good, there
isn't a 100% when it comes to fastest rate, 0% is stopped. The "speed bar"
would have to change also for varying rates. Like shifting gears. Perhaps a
red bar in a length relating to pixels/min, yellow for pixels/sec and green for
pixels/100th sec.
Just a thought, and probably not an original one at that.
Bob H.
"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3A43584A.FF1B5622@inapg.inra.fr...
> Ken wrote:
>
> > Actually I rather liked that too. It helped determine where exactly on
> > screen it took the longest time to render. When you saw this you could
> > tell exactly which feature you were using slowed down the render times
> > the mostest.
>
> You can still do this. In the Windows version, resize the render window until
> the bottom scroll bar appears. Then move the cursor from time to time and the
> screen will be updated as many times as the cursor is moved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob H. wrote in message <3a470c36@news.povray.org>...
>The "speed bar"
>would have to change also for varying rates. Like shifting gears. Perhaps
a
>red bar in a length relating to pixels/min, yellow for pixels/sec and green
for
>pixels/100th sec.
Just plot it on an exponential curve. Automatic continuously-variable
gearshifting.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:3A425F7A.2D828B22@pacbell.net...
>
>
> Andy Cocker wrote:
> >
> > Ever so slightly off-topic, but I really miss the way that each pixel
was
> > shown as it rendered in the DOS version 2.2. I used to enjoy watching
it's
> > progression along each line ( sad, aren't I? :-)). Now in windows, it
just
> > updates the screen as each line is rendered.
>
> Actually I rather liked that too. It helped determine where exactly on
> screen it took the longest time to render. When you saw this you could
> tell exactly which feature you were using slowed down the render times
> the mostest.
>
I never thought I'd have to say this to you, Ken, but... RTFM, dude,
RTFM!
Don't the CPU utilization histogram options (+HN & +HS) give you this
info ?
--
Scott Hill.
Software Engineer.
E-Mail : sco### [at] innocentcom
PGP Key : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com
*Everything in this message/post is purely IMHO and no-one-else's*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > Ever so slightly off-topic, but I really miss the way that each pixel
> was
> > > shown as it rendered in the DOS version 2.2. I used to enjoy watching
> it's
> > > progression along each line ( sad, aren't I? :-)). Now in windows, it
> just
> > > updates the screen as each line is rendered.
> >
> > Actually I rather liked that too. It helped determine where exactly on
> > screen it took the longest time to render. When you saw this you could
> > tell exactly which feature you were using slowed down the render times
> > the mostest.
> >
>
> I never thought I'd have to say this to you, Ken, but... RTFM, dude,
> RTFM!
>
> Don't the CPU utilization histogram options (+HN & +HS) give you this
> info ?
nah, it not that same as watching an image build pixel by pixel. i also
loved watching it take shape
--
Rick
POV-Ray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
> nah, it not that same...
True.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
