Wonderful  Beta 3.7 current #
Using the exact same scene files but swapping out all 3 executable I get the
following results in a 3000 x 4000 render

STD 3.6              62 minutes
regular 3.7 Beta     30 minutes
SSE 3.7 beta         27 minutes

The generated files look identical with the same file size for the 2 beta
files, slightly larger for the 3.6 file.  I used whatever defaults and
identical INI settings.

Is there a reason for the default "block style" rendering in 3.7 rather that
the "scan-line style" of 3.6?

But.....  both of the Beta renders crashed after the first frame
(rendering to png with default settings) while the 3.6 render continued onto
the next frame. I haven't tried any other output formats yet but I probably
will.

Post a reply to this message

Andycadd <And### [at] comcastnet> wrote:
> Is there a reason for the default "block style" rendering in 3.7 rather that
> the "scan-line style" of 3.6?

  Yes: SMP.

> But.....  both of the Beta renders crashed after the first frame
> (rendering to png with default settings) while the 3.6 render continued onto
> the next frame. I haven't tried any other output formats yet but I probably
> will.

  Could you provide a short scene (and rendering settings) that shows this?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Andycadd <And### [at] comcastnet> wrote:
> > Is there a reason for the default "block style" rendering in 3.7 rather that
> > the "scan-line style" of 3.6?
>
>   Yes: SMP.
>
> > But.....  both of the Beta renders crashed after the first frame
> > (rendering to png with default settings) while the 3.6 render continued onto
> > the next frame. I haven't tried any other output formats yet but I probably
> > will.
>
>   Could you provide a short scene (and rendering settings) that shows this?
>
> --
>                                                           - Warp



When I remove some of the model  it renders just fine in animation mode
when I crank the resolution down it runs just fine in animation mode
probably if I turn off display it would work fine also
----------------
It must be that a GIG of ram is just on the line for a successful render at
8000 X 2000 with a rather large model file
----------------
Strange that it would start and render/display the first frame

not so Strange that it works just fine with 3.6 but not 3.7 as 3.7 probably
uses a little more memory overhead

''''''''''''''''
what follows is the log for the first frame a very large model (I put a
cropped portion in the images directory titled "future hotel") rendered in
3.6
''''''''''''''''

Render Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 3
  Antialiasing.........On  (Method 1, Threshold 0.040, Depth 3, Jitter 1.00)
Render Statistics
Image Resolution 8000 x 2000
Pixels:         17004000   Samples:         4247388   Smpls/Pxl: 0.25
Rays:           21251388   Saved:                 0   Max Level: 1/6
Ray->Shape Intersection          Tests       Succeeded  Percentage
Cone/Cylinder                  1294518               0      0.00
CSG Merge                       215753               0      0.00
Mesh                          21797976         1498108      6.87
Sphere                        42502776        42502776    100.00
Triangle                    1718215371        28586386      1.66
Bounding Box                2302667593      1172313524     50.91
Shadow Ray Tests:            884757   Succeeded:                338247
Shadow Cache Hits:           338169
Smallest Alloc:                   0 bytes
Largest  Alloc:                   0 bytes
Render Time:
  Photon Time:      No photons
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  8 minutes 45 seconds (525.734 seconds)
              using 4 thread(s) with 991.436 CPU-seconds total

End of First Frame

'''''''''''''''''
here is the error messages
'''''''''''''''''
Possible Parse Error: Cannot find file 'C:povtsstone9bel11.pov', even after
trying to append file type extension.
Parse Error: Cannot open input file.
Possible Parse Error: Cannot parse input.
Possible Parse Error: Cannot find file 'C:povtsstone9bel11.pov', even after
trying to append file type extension.
Parse Error: Cannot open input file.
Possible Parse Error: Cannot parse input.
Render failed
-
CPU time used: kernel 78.80 seconds, user 8602.11 seconds, total 8680.91
seconds.
Elapsed time 4525.23 seconds, CPU vs elapsed time ratio 1.92.

Post a reply to this message

Andycadd <And### [at] comcastnet> wrote:
> not so Strange that it works just fine with 3.6 but not 3.7 as 3.7 probably
> uses a little more memory overhead

  No, there's nothing in 3.7 which should use more memory than 3.6. It is
not normal. If you can come up with a good example scene, it would be very
helpful.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Andycadd <And### [at] comcastnet> wrote:
>> not so Strange that it works just fine with 3.6 but not 3.7 as 3.7 probably
>> uses a little more memory overhead
> 
>   No, there's nothing in 3.7 which should use more memory than 3.6. It is
> not normal. If you can come up with a good example scene, it would be very
> helpful.

You are mistaken, it is normal. The image output was changed, which does
matter if you have a 8K x 2K pixel image - that image will consume 320M
bytes of memory right now, as disk buffering has not been implemented yet.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> You are mistaken, it is normal. The image output was changed, which does
> matter if you have a 8K x 2K pixel image - that image will consume 320M
> bytes of memory right now, as disk buffering has not been implemented yet.

  Ah, I thought it already did that...

-- 
                                                          - Warp

Post a reply to this message

Andycadd nous apporta ses lumieres en ce 08/10/2006 00:25:
> Warp <war### [at] tagpovrayorg> wrote:
>> Andycadd <And### [at] comcastnet> wrote:
>>> Is there a reason for the default "block style" rendering in 3.7 rather that
>>> the "scan-line style" of 3.6?
>>   Yes: SMP.
>>
>>> But.....  both of the Beta renders crashed after the first frame
>>> (rendering to png with default settings) while the 3.6 render continued onto
>>> the next frame. I haven't tried any other output formats yet but I probably
>>> will.
>>   Could you provide a short scene (and rendering settings) that shows this?
>>
>> --
>>                                                           - Warp
> 
> 
> 
> When I remove some of the model  it renders just fine in animation mode
> when I crank the resolution down it runs just fine in animation mode
> probably if I turn off display it would work fine also
> ----------------
> It must be that a GIG of ram is just on the line for a successful render at
> 8000 X 2000 with a rather large model file
> ----------------
> Strange that it would start and render/display the first frame
> 
> not so Strange that it works just fine with 3.6 but not 3.7 as 3.7 probably
> uses a little more memory overhead
> 
> ''''''''''''''''
> what follows is the log for the first frame a very large model (I put a
> cropped portion in the images directory titled "future hotel") rendered in
> 3.6
> ''''''''''''''''
> 
> Render Options
>   Quality:  9
>   Bounding boxes.......On   Bounding threshold: 3
>   Antialiasing.........On  (Method 1, Threshold 0.040, Depth 3, Jitter 1.00)
> Render Statistics
> Image Resolution 8000 x 2000
> Pixels:         17004000   Samples:         4247388   Smpls/Pxl: 0.25
> Rays:           21251388   Saved:                 0   Max Level: 1/6
> Ray->Shape Intersection          Tests       Succeeded  Percentage
> Cone/Cylinder                  1294518               0      0.00
> CSG Merge                       215753               0      0.00
> Mesh                          21797976         1498108      6.87
> Sphere                        42502776        42502776    100.00
> Triangle                    1718215371        28586386      1.66
> Bounding Box                2302667593      1172313524     50.91
> Shadow Ray Tests:            884757   Succeeded:                338247
> Shadow Cache Hits:           338169
> Smallest Alloc:                   0 bytes
> Largest  Alloc:                   0 bytes
> Render Time:
>   Photon Time:      No photons
>   Radiosity Time:   No radiosity
>   Trace Time:       0 hours  8 minutes 45 seconds (525.734 seconds)
>               using 4 thread(s) with 991.436 CPU-seconds total
> 
> End of First Frame
> 
> '''''''''''''''''
> here is the error messages
> '''''''''''''''''
> Possible Parse Error: Cannot find file 'C:povtsstone9bel11.pov', even after
> trying to append file type extension.
> Parse Error: Cannot open input file.
> Possible Parse Error: Cannot parse input.
> Possible Parse Error: Cannot find file 'C:povtsstone9bel11.pov', even after
> trying to append file type extension.
> Parse Error: Cannot open input file.
> Possible Parse Error: Cannot parse input.
> Render failed
> -
> CPU time used: kernel 78.80 seconds, user 8602.11 seconds, total 8680.91
> seconds.
> Elapsed time 4525.23 seconds, CPU vs elapsed time ratio 1.92.
> 
> 
> 
> 
> 
> 
> 
I've been hit by that error somes times doing animations. Render some frames, 
then it looks like the path to the source file get lost. The can't find file 
error message always reffers to the actual scene file. It looks like the file 
gets actualy parsed, then the error pops up.

-- 
Alain
-------------------------------------------------
Inside every older person is a younger person wondering what happened.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> > Andycadd <And### [at] comcastnet> wrote:
> >> not so Strange that it works just fine with 3.6 but not 3.7 as 3.7 probably
> >> uses a little more memory overhead
> >
> >   No, there's nothing in 3.7 which should use more memory than 3.6. It is
> > not normal. If you can come up with a good example scene, it would be very
> > helpful.
>
> You are mistaken, it is normal. The image output was changed, which does
> matter if you have a 8K x 2K pixel image - that image will consume 320M
> bytes of memory right now, as disk buffering has not been implemented yet.
>
>  Thorsten

Disk buffering  .....  that is working in 3.6 currently?
How come the windows virtual memory doesn't just pick this up?
PLEASE excuse my ignorance.

Post a reply to this message

Andycadd wrote:
> Disk buffering  .....  that is working in 3.6 currently?

There is no "disk buffering". What POV-Ray 3.6 and earlier do is write the
file to disk line by line. While POV-Ray 3.7 also writes the file in a
temporary format to disk to support a continue trace in case of a crash, it
further keeps a whole copy in memory as it will now write the final image to
disk at the end of the render, rather than write it incrementally and
(mis)use it as continue trace buffer like 3.6 and earlier did.

The problem with using any fixed image format for continue trace in 3.6 and
earlier is that image formats do not actually store all the information
necessary to properly continue a trace, in particular with anti-aliasing
enabled. Hence this problem has been addressed in 3.7.

> How come the windows virtual memory doesn't just pick this up?
> PLEASE excuse my ignorance.

Because you still only have 2 GB to 3GB (depending on Windows version) of
address space for a 32 bit application.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Andycadd wrote:
>> How come the windows virtual memory doesn't just pick this up?
>> PLEASE excuse my ignorance.
> 
> Because you still only have 2 GB to 3GB (depending on Windows version) of
> address space for a 32 bit application.
> 
> 	Thorsten

If it's really a problem with memory addressing, as you seem to be 
suggesting, perhaps a more suitable error message could be introduced?

...Chambers

Post a reply to this message