Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> Careful there, you'll get Warp all revved up again.  What you're talking
> about is structured programming, not OOP.

OOP requires encapsulation (only XXX_ macros work with a particular setup of
the associative array), inheritance (if the generic object has "location"
and "texture" attributes, macros working only with them with work with any
associative array) and polymophism, which in our context looks to me almost
useless. OO languages make things automatic but, given that thing called
SELF-DISCIPLINE, you can  develop OO code even with assembler... it is
"just" the way you look at it.

Obviously, if POVTeam throws in a GNU/Panorama-like OO scene description
language, I am not going to cry!!!!

Bye!!!!

P.S.: I proposed the associative array escamotage because it: 1) does not
require much code , 2) has the least impact upon POV description language
(if you don't like it, you just don't use it).

Post a reply to this message

"Greg M. Johnson" wrote:

> Fabien Mosen wrote:
>
> > "Greg M. Johnson" wrote:
> > > 1) PROGRESSIVE RENDER.
> >
> > You will be happy : it's already there !! Command-line options
> > +SP +EP ..
>
> Could you please tell me the menu for the Windows version and the phrase
> I could add to POVRAY.INI?

Sure, +SP +EP
INIs can take command-line options

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:

> Sure, +SP +EP
> INIs can take command-line options

BTW, u can go to Render->Edit settings/render and specify cmnd-line ops if u
don't wanna mess with INIs.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

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).
  As we can see, they usually don't even know _where_ the command line
options field is in WinPov.

-- 
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

Ian Witham <ian### [at] hotmailcom> 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