|
 |
Chris Cason <nos### [at] deletethis povrayorg> wrote:
> Warp wrote:
> > abyss.pov is still rendering incorrectly (ie. with a black background).
>
> Noted, thanks, this has still to be addressed.
>
> > I also noticed that stackergold.pov takes 10 times longer to parse
> > with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
> > in my computer).
>
> Good find, thanks ... this is caused by the fact that as of this beta each
> attempt to open a file causes a call to the frontend that has to be replied
> to (the frontend controls locating files and granting access permission, and
> in the long term - once support is added - can even send the file contents to
> the backend via POVMS).
>
> Obviously this has to be made more efficient; for some reason the results
> aren't being cached though they are supposed to be (stackergold's use of
> macros causes a lot of file access).
>
> -- Chris
I saw the same issues using the 64bit version running woodenbox.pov
AMD64 +4000 2GB-DDR400 nVidia 6800 SLI
version 3.6 @ 512x384 no/AA = 3.53seconds or 55676.66pps
version 3.7.0 beta10 @ 512x384 no/AA = 12.59seconds or 15612.48pps
*Alan
Post a reply to this message
|
|
|
|
Chris Cason wrote:
> With respect to the doc/view concept, a parsed scene is a 'document' and a
> render is a 'view'. The 'document' is everything in the scene except the
> camera settings, and the 'view' is the camera settings, output resolution,
> output file type, gamma correction, and so forth. Each document and view has
> its own internal identifier and the POV-Ray code uses these ID's when
> communicating between the front and back ends of the codebase. When a scene
> is succesfully parsed the frontend is told about it, and it then using that
> ID creates a view and subsequently asks the backend to render that view.
Would this also allow a "portal" texture type to be used, where the
surface of an object is basically a "view" of a separate "document"?
...Chambers
(...after a long hybernation)
Post a reply to this message
|
|
