 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ian Witham <ian### [at] hotmail com> wrote:
: What's wrong with mosaic preview?? from memory its +sp in the .ini file
: followed by a multiple of 4. +sp 32 for example.
Although the answer is perfectly correct, it should be said that this is
not the only way of doing it.
For example I don't want the mosaic preview every time, but only when
doing test renders. I don't want mosaic preview in the final render because
it will increase considerably the rendering time.
If the +sp option is in the .ini file, you'll get mosaic preview in each
render, thus increasing the total rendering time.
I always use +sp in the command line field. It's easy to add and remove
and povray remembers it from session to session.
The command line field is also handy to quickly add other options, such
as antialiasing (other than +a0.3), radiosity and so on.
--
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 wrote:
> For example I don't want the mosaic preview every time, but only when
> doing test renders. I don't want mosaic preview in the final render because
> it will increase considerably the rendering time.
How much does it increase it?
If it's just a little bit more bookkeeping for the software, no problem.
If it actually throws away the first few scans, then it's much less useful**1
and not like Bryce's progressive render as I understand it.
**1 If you're doing command line rendering, yeah, it's no biggie either type
+SP or not type it. If you have to edit your INI each time, it's more of a
biggie.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B8DAE9.B3A8B5D2@my-dejanews.com...
>
> How much does it increase it?
> If it's just a little bit more bookkeeping for the software, no problem.
>
> If it actually throws away the first few scans, then it's much less
useful**1
> and not like Bryce's progressive render as I understand it.
>
Hmm, I've always assumed that POV throws away any mosaic info without using
it for any subsequent action (except for radiosity), and that any other
renderer must do the same.
After all, calculating that an area x pixels by x pixels is dark green on
average does nothing helpful when it comes to calculating the colour of an
individual pixel. The only exception I can think of is if the average is rgb
0 or rgb 1 (or whatever the appropriate equivalent is).
If this isn't the case with either POV or Bryce, can someone give me an
idiot's explanation of how the info is used?
(and BTW that's an explanation FOR and idiot, not BY one)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hmm, I've always assumed that POV throws away any mosaic info without using
> it for any subsequent action (except for radiosity), and that any other
> renderer must do the same.
I would have assumed that the intelligent way to do it would be like below. I
assume it's how Bryce does it.
Say you're doing a 400 x 300. That's 1200 pixels.
First you shoot pixels AS IF it were a 40 x 30, where you choose by some
algorithm 1 pixel out of every block of 100.
Report the color of these pixels to the viewer as if it were ONLY a 40 x 30.
Now assume it's a 160 x 120, shoot 3 pixels out of every block of ....... and
so on......
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In megaPov, Mosaic preview doesn't work with radiosity enabled.... and even
> if you turn radiosity off, the preview won't work until you restart MegaPov.
> I'd call that a bug ;-)
eh? For me in MPov it's always there with radiosity enabled, in fact, I'd like
it *not* to be there; the best I can do is +SP2
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B8E565.987346EF@my-dejanews.com...
>
> Say you're doing a 400 x 300. That's 1200 pixels.
> First you shoot pixels AS IF it were a 40 x 30, where you choose by some
> algorithm 1 pixel out of every block of 100.
> Report the color of these pixels to the viewer as if it were ONLY a 40 x
30.
> Now assume it's a 160 x 120, shoot 3 pixels out of every block of
....... and
> so on......
Doh! Of course. That makes sense. My notion wasn't even sensible - it would
take just as long (longer actually) to work out the average for a mosaic as
it would for a full render (since you have to calc. the rgb for each pixel
before you can average them).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: How much does it increase it?
Too much.
It's probably a quite small percent of the rendering time in the final pass,
but even small slowdown is too much.
: If it actually throws away the first few scans, then it's much less useful**1
: and not like Bryce's progressive render as I understand it.
Firstly: Why would you want a progressive render in the final image?
Secondly: With progressive render you can't use antialiasing.
: **1 If you're doing command line rendering, yeah, it's no biggie either type
: +SP or not type it. If you have to edit your INI each time, it's more of a
: biggie.
When I use winpov I use the command line field. You can get it with ALT-C
if I remember correctly.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: Say you're doing a 400 x 300. That's 1200 pixels.
: First you shoot pixels AS IF it were a 40 x 30, where you choose by some
: algorithm 1 pixel out of every block of 100.
: Report the color of these pixels to the viewer as if it were ONLY a 40 x 30.
: Now assume it's a 160 x 120, shoot 3 pixels out of every block of ....... and
: so on......
How do you calculate antialiasing here?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39b903fb@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> How do you calculate antialiasing here?
You just continue doing it for imaginary sub-pixels, and then average them.
It is no great anti-aliasing, but it still works. Of course there is some
cost of memory attached to it, and other restrictions apply ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:39b8bd2c@news.povray.org...
| Fabien Mosen <fab### [at] skynetbe> wrote:
| :> 1) PROGRESSIVE RENDER.
|
| : You will be happy : it's already there !! Command-line options
| : +SP +EP ..
|
| I think this is the main problem in WinPov. People don't care about
command
| line options because they have everything (that is, they think they have
| everything) in menus and buttons. So they don't even read the
documentation
| about command line options and thus miss this kind of basic options (which
| most command line users, like me, have used from the very beginning).
Well, not so for us long time POV-Ray users. Since there wasn't a Windows
version in the beginning I never actually left the command line behind and
still use it every day. It's about the quickest way to make a custom change
in the rendered output I know of.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
