I do not see the point in using the program without the preview for i use
it as well as partial rendering to finish most all of my projects even the
most simple ones... Once again i will stick to Mega Pov... =]

WhiteGandalf wrote:

> Hello..
>
> it seems that it is always myself complaining about the same thing?
>
> anyway I made my first scene in pov 3.5 I just got today: checker,
> sphere, area light.
> render. dog slow. 4 minutes andsome seconds
>
> I take the scene and render it in megapov latest version (I can't
> compare to pov3.1 since that aerealight wasn't supppoerted) and i get 6
> seconds
>
> i then render a trivial sample scene and i get 16 minutes... my G3 slow
> as a quadra??? the same scene on pov 3 took less on my quadra!
>
> now it is sooo lae and it's better to go to bed... but I read that
> povray should be faster and more stable than megapov while using the
> patches and I hoped the rest would remain unchanged!
>
> -r-

Post a reply to this message

In <3d33b973@news.povray.org> Thorsten Froehlich wrote:
>> megapov: 1 min 46 sec
>> pov 3.5: 6 min 54
> 
> You had the preview on again, right?

no it was off in both programs, I saved the file directy to disk. Ypou 
advised me to test it such way.

-r-

Post a reply to this message

In <3d33b973@news.povray.org> Thorsten Froehlich wrote:
>> megapov: 1 min 46 sec
>> pov 3.5: 6 min 54
> 
> You had the preview on again, right?

no it was off in both programs, I saved the file directy to disk. Ypou 
advised me to test it such way.

-r-

Post a reply to this message

In <chr### [at] netplexaussieorg> Christopher 
James Huff  wrote:
> You forgot to take the compiler into account...the version of gcc in 
> the  development tools is nowhere near as good at optimization as 
> Metrowerks  CodeWarrior (which is used for the official version). The 
> next update of  the development tools will use a more up to date 
> version of gcc which is  apparently much better at optimization of PPC 
> code, I don't know how it  compares to CodeWarrior. If you want to 
> compare 3.1 and MegaPOV, compile  MegaPOV with gcc as well.

This exaclty was the point. I used gcc and complained about it!

> And anyway, being a GUI program won't really affect the render 
> speed...you probably ran the command line version from Terminal.app, 
> which (obviously) is a GUI program itself. The only way there could be 
> a  significant difference is if you booted up without any GUI at all, 
> which  I don't consider worth the few % of CPU time gained. Just being 
> a CLI  program doesn't give any special advantages.
Well, that's not completely true, after all without preview povray isn't 
doing much.
Specifcally I run my CLI compile both in terminal.app and then i booted 
console only. Appple did a fine work, no noticeable difference (under 1%). 
This of course if you leave the GUI in peace, if you move windows around 
it isn't fair.
Being a CLI program shouldn't give any significant advantages during 
render, but it was one way to test gcc from orignal sources.

And I must add, CodeWarrior, at least the older versions, isn't such a 
speedy compiler. Under os classic where MPW was available it was 
consistently outperformed as T. Fr?hlich will remind. He sent me an 
unofficial MPW compile and it was quite faster.


> There may be something specific to how POV-Ray Mac works though...
> maybe  the way it handles events uses up CPU time or prevents it from 
> using  100% of available cycles.
strictly speaking "cycles" doesn't make much sense in a unix environment. 
It is not a single program that decides to acquire or release the CPU 
but the kernel.

-ric-

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> There may be something specific to how POV-Ray Mac works though...maybe
> the way it handles events uses up CPU time or prevents it from using
> 100% of available cycles.

No, but under Mac OS X one has to give control to the system as frequently
as possible to prevent the spinning beachball cursor which effectively locks
the user out of the program.  So under mac OS X POV-ray 3.5 for Mac OS is
forced to be more friendly than under Mac OS 9.

    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

In article <3D347959.649CC718@earthlink.net> , Ryan Mooney 
<rdm### [at] earthlinknet>  wrote:

> I do not see the point in using the program without the preview for i use
> it as well as partial rendering to finish most all of my projects even the
> most simple ones... Once again i will stick to Mega Pov... =]

Nobody forces you to use POV-Ray 3.5.

    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

In article <20020716223638440+0200@news.povray.org> , WhiteGandalf 
<zus### [at] liberoit>  wrote:

>>> megapov: 1 min 46 sec
>>> pov 3.5: 6 min 54
>>
>> You had the preview on again, right?
>
> no it was off in both programs, I saved the file directy to disk. Ypou
> advised me to test it such way.

Well, then you obviously tested with completely different settings.

    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

In article <3d348cd6@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> No, but under Mac OS X one has to give control to the system as frequently
> as possible to prevent the spinning beachball cursor which effectively locks
> the user out of the program.  So under mac OS X POV-ray 3.5 for Mac OS is
> forced to be more friendly than under Mac OS 9.

And I guess you probably can't fix this without making it Mac OS X 
only...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <20020716230156187+0200@news.povray.org>,
 WhiteGandalf <zus### [at] liberoit> wrote:

> In <chr### [at] netplexaussieorg> Christopher 
> James Huff  wrote:
> > You forgot to take the compiler into account...the version of gcc in 
> > the  development tools is nowhere near as good at optimization as 
> > Metrowerks  CodeWarrior (which is used for the official version). The 
> > next update of  the development tools will use a more up to date 
> > version of gcc which is  apparently much better at optimization of PPC 
> > code, I don't know how it  compares to CodeWarrior. If you want to 
> > compare 3.1 and MegaPOV, compile  MegaPOV with gcc as well.
> 
> This exaclty was the point. I used gcc and complained about it!

You said "pov from command line should be advantaged.", which seemed to 
say you were comparing gcc-compiled POV 3.1 against the GUI MegaPOV, 
which is compiled with CodeWarrior. What exactly were you doing?


> Well, that's not completely true, after all without preview povray isn't 
> doing much.

Uh, what? You aren't supposed to have the preview on for benchmarks 
anyway. Of course a preview will eat up CPU cycles...but without preview 
it is still a GUI program.


> And I must add, CodeWarrior, at least the older versions, isn't such a 
> speedy compiler. Under os classic where MPW was available it was 
> consistently outperformed as T. Fr?hlich will remind. He sent me an 
> unofficial MPW compile and it was quite faster.

True, but it has gotten much better over time...I'm not sure which is 
faster now, but they are close, and both are much better than gcc 2.95.2.


> strictly speaking "cycles" doesn't make much sense in a unix environment. 
> It is not a single program that decides to acquire or release the CPU 
> but the kernel.

I am aware of that, but POV-Ray Mac works in the Carbon environment, and 
is written to be compatible with pre-OS X versions of Mac OS. This 
probably makes it less efficient (having to constantly stop rendering 
and check for events to stay responsive) and might prevent it from 
getting all the available time. The command-line version shouldn't have 
this problem...at least my command line programs have no trouble pinning 
the processor use at 100%.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

>> No, but under Mac OS X one has to give control to the system as frequently
>> as possible to prevent the spinning beachball cursor which effectively locks
>> the user out of the program.  So under mac OS X POV-ray 3.5 for Mac OS is
>> forced to be more friendly than under Mac OS 9.
>
> And I guess you probably can't fix this without making it Mac OS X
> only...

Yes and no.  With Mac OS 9.1 and later it is possible to create MP-services
threads (which are preemptive) that do file-io.  So it is not impossible to
make the render engine run in a preemptive thread on those Mac OS  versions.
Then, under Mac OS X while all the function calling restrictions still
apply, it would also run preemptively just like a Cocoa preemptive thread.
That way it should get absolutely all available CPU resources (of one CPU,
of course).

In fact, I have such an experimental version and it will run just fine on
one processor of the dual G4 and leave the GUI on the other processor.  So
the GUI is as responsive as without rendering, and the Mac (under Mac OS
that is) is fully usable.  Even better, this way one can run two instances
of POV-Ray to use both processors just like one can currently in the Windows
version.

However, this version is not ready for prime-time yet, and won't for another
few month.  It may (note that I say may *not* will) be ready when there will
be a POV-Ray 3.5.1 or whatever the maintenance releases will be called.

    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