Ian Witham 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.

Wow! This is neat!

For us non-switch-typing mortals, we would add

Preview_Start_Size=4

to POVRAY.INI,

Post a reply to this message

that's why it's a good idea to have a printed version of the docs and to
read them once a month.  there's always something new to learn.

"Greg M. Johnson" wrote:
> 
> Ian Witham 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.
> 
> Wow! This is neat!
> 
> For us non-switch-typing mortals, we would add
> 
> Preview_Start_Size=4
> 
> to POVRAY.INI,

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B7AFF0.B38E4942@my-dejanews.com...

> Wow! This is neat!
>
> For us non-switch-typing mortals, we would add
>
> Preview_Start_Size=4
>
> to POVRAY.INI,
>

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

sorry just a random rant.....

--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm

Post a reply to this message

I would really like that POV-4 had associative arrays of heterogeneous
elements. For example:

arr["location"] = <1,1,1>;
arr["texture"] = texture { ... }
arr["show"] = true;

etc.

Why?

Well, with this kind of containers it would be possible to fake object
oriented programming. For example

#macro MySmartBox_Create(this)
    this = assoc_array();
    this["location"] = 0;
    this["side"] = 1;
#end

#macro MySmartBox_Display(this)
    object {
        this["location"] - <Side/2, Side/2, Side2>,
        this["location"] + <Side/2, Side/2, Side2>
        texture {
            this["texture"]
        }
    }
#end

etc.

Having associative heterogeneous arrays + macros is all that is needed for
OOP in POVRay.

Post a reply to this message

On Thu, 7 Sep 2000 22:17:53 +0200, Alessandro Coppo wrote:
>
>Well, with this kind of containers it would be possible to fake object
>oriented programming. For example

[...]

>Having associative heterogeneous arrays + macros is all that is needed for
>OOP in POVRay.

Careful there, you'll get Warp all revved up again.  What you're talking
about is structured programming, not OOP.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <39B79FDF.16E6555D@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> I can imagine how to do this with a few zillion trace calls and counting
> cubes, but not immediately how to do with object pattern.

Use eval_pattern() with the object pattern, using the object you are 
calculating the volume of as the control object for the pattern. Check 
eval_pattern() multiple times in a 3D grid and use the results to 
calculate the volume.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

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