 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
It sounds perfectly ok to me how you describe it, what's the reason you
think that's wrong?
Of course it would be nice to have decimals for slower renders, but that's
just a limitation.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jonathan Rafael Ghiglia wrote in message
<3a411423.9516438@news.povray.org>...
>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.
Under POV-Ray for Windows 3.1g, the PPS counter is the PPS rate for the
whole image up to this point. This means, for example, that if the first
part of your image renders quickly, while the rest renders slowly, the PPS
value will be too high.
With MegaPOV, I've found that the PPS counter does not update very
frequently.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that it would be nice to have two PPS values, one for the whole
image and another for the last pixel calculated.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a41f67b@news.povray.org...
> I think that it would be nice to have two PPS values, one for the whole
> image and another for the last pixel calculated.
>
Right now, I couldn't agree more. I'm rendering for the IRTC. and am very
unsure as to whether it will finish on time. 17h so far and 12% rendered,
but with different types of objects and media in the image, I can't be
confident that the speed is constant.
BTW I don't know what I've done that is making such demands - multiple
patches and scattering media are slow, but not normally that slow. And this
is on my brand new P3 733 at work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
> Jonathan Rafael Ghiglia wrote in message
> <3a411423.9516438@news.povray.org>...
>>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.
> Under POV-Ray for Windows 3.1g, the PPS counter is the PPS rate for the
> whole image up to this point. This means, for example, that if the first
> part of your image renders quickly, while the rest renders slowly, the PPS
> value will be too high.
> With MegaPOV, I've found that the PPS counter does not update very
> frequently.
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.
I don't know that a last pixel pps is useful, becasue it would have to be
updating (wasting a lot of resources) an awful lot. A last line could be,
though.
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.
I know it'd slow things down a fair amount, but I'd really like the option
to reinstate it.
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] liberoit (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
|
|
| |
| |
|
|
|
|
| |
