Big Pov Files

Big Pov Files

Post by harri.. » Fri, 19 Apr 1996 04:00:00



Hello Povers.
I have been attempting to run a large (21 megs w/ 96,540 objects)  Pov
file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
povray causeway swap file, and it seems to die when ever I try to parse it.  
I can seem to get it to run through just about every step of the parsing stage
in about a day, but it just CHOKES big time when it comes to the light
buffer.  I left my machine on for THREE days and it was still creating the
buffers!!!  Is there some way I can turn these buffers off, or will I save
time in the long run by letting it sit in the coner chuging away?
Any help would be apriciated,

Thank you,
Neil Herriford

--ps, anyone have a p6 200mhz that I can, ah, borrow for a few weeks to
run this file through?  <g>
--

Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)

 
 
 

Big Pov Files

Post by Andreas Dilg » Sun, 21 Apr 1996 04:00:00



>Hello Povers.
>I have been attempting to run a large (21 megs w/ 96,540 objects)  Pov
>file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
>povray causeway swap file, and it seems to die when ever I try to parse it.  
>I can seem to get it to run through just about every step of the parsing stage
>in about a day, but it just CHOKES big time when it comes to the light
>buffer.  I left my machine on for THREE days and it was still creating the
>buffers!!!

I think you'll find that the rendering won't complete in your lifetime.  The
problem is in the swapping to disk.  Considering that you already have a
large file that would take many hours (days?) to render, even if it all fit
in memory, then add the fact that hard-drive swapping is many thousands of
times slower than RAM, you have a rendering that will take many thousands of
days to complete.  You didn't mention how much real memory memory you have.

I had a similar situation using Gforge a week or so ago, where I tried to make
a 1000 x 1000 heightfield (needs over 8MB of RAM - I only have 8MB), and it
ran for a whole day and hadn't shown any sign of finishing.  I reduced the size
to 600 x 600, (needs about 3MB), and it completed in about 15 mins.

Quote:>Is there some way I can turn these buffers off, or will I save
>time in the long run by letting it sit in the coner chuging away?

You can turn the light and vista buffers off by using -UL -UV (read the docs),
but I'm not sure it will help in the long run or not.  I would suggest making
the scene less complex, or getting a lot more memory (pretty cheap these days).

Cheers, Andreas.
--
Andreas Dilger   University of Calgary  \"If a man ate a pound of pasta and
(403) 220-8792   Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \   cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/       hungry?" -- Dogbert

 
 
 

Big Pov Files

Post by Bjarne Nygaa » Thu, 02 May 1996 04:00:00


hi..
I have rendered a scene with 47000 objects (mostly soft triangles) on a
DX2/66 with 32Mb and 16MB under Linux with 100Mb swapfile using pov3.06b.
During the run 50-55MB of swap is used for the structures.
As you say it is the parsing that takes time. But it is not CPU activity
wich causes the bottleneck, -it is disk I/O. Most of the parsing time the
CPU workload is down to 1-5%. When going from 16MB to 32MB the parsing
time went 1 hour to 25min. The picture itself was rendered in ca. 12 hours.
Using earlier versions of POV than 3 would spend must more time rendering.
With a scene as mine I would say that time has gone down to 1/3 or 1/4.

That is a performance boost that I like :)
Congratulations POV-team.

Bjarne Nygaard

: Hello Povers.
: I have been attempting to run a large (21 megs w/ 96,540 objects)  Pov
: file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
: povray causeway swap file, and it seems to die when ever I try to parse it.  
: I can seem to get it to run through just about every step of the parsing stage
: in about a day, but it just CHOKES big time when it comes to the light
: buffer.  I left my machine on for THREE days and it was still creating the
: buffers!!!  Is there some way I can turn these buffers off, or will I save
: time in the long run by letting it sit in the coner chuging away?
: Any help would be apriciated,

: Thank you,
: Neil Herriford

: --ps, anyone have a p6 200mhz that I can, ah, borrow for a few weeks to
: run this file through?  <g>
: --

: Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)

 
 
 

Big Pov Files

Post by Andreas Dilg » Sat, 04 May 1996 04:00:00




>I have rendered a scene with 47000 objects (mostly soft triangles) on a
>DX2/66 with 32Mb and 16MB under Linux with 100Mb swapfile using pov3.06b.
>During the run 50-55MB of swap is used for the structures.
>As you say it is the parsing that takes time. But it is not CPU activity
>wich causes the bottleneck, -it is disk I/O. Most of the parsing time the
>CPU workload is down to 1-5%. When going from 16MB to 32MB the parsing
>time went 1 hour to 25min. The picture itself was rendered in ca. 12 hours.

The question I had for the originaly poster was how much real memory he had.
He mentions a 128 MB swap file, but how much RAM?  You are correct that the
disk I/O will take by FAR the most time when swapping to disk.  You will be
happy to know that the parsing speed has been dramatically improved by
Dieter for the next version of the beta (Linux beta already available).  We
now use hasing tables for doing keyword matches rather than linear or
(for a brief period binary subdivision) searches.  This speeds up the parsing
time for scenes with many objects by 25-50%.  There have also been some
other parsing speedups.  Of course, nothing will help if you don't have enough
real memory to do the job...

Cheers, Andreas.
--
Andreas Dilger   University of Calgary  \"If a man ate a pound of pasta and
(403) 220-8792   Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \   cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/       hungry?" -- Dogbert

 
 
 

1. BIG BIG BIG problem in MAX

Jon,

The problem is not with MAX, but your modeling techniques.  There are
several things you can do to improve the appearance of your AT-AT.

First of all, build your model with as few polygons as possible and
still achieve the look you want.  Stay away from booleans if possible.
With a little planning, you can model almost anything without resorting
to using booleans.  If you must use booleans do it early in the modeling
phase . . . the more complex your model the more likely the boolean
function will screw up.

Make sure there are no co-planar polygons.  If it is not necessary, do
not have 'many objects intersecting another'.  Check your surface
normals - some of your polygons appear to be facing the wrong direction.
Weld your vertices and apply smoothing to eliminate 'oddly shaded
objects'.

--
Randy Kleinman

2. how to create sky

3. An BIG PSD file opens into a New file

4. compression with manipulation

5. That big Pov project a while ago...

6. concours

7. POV-ray dumps core when input is big...

8. brazil/finalrender

9. Pov + Big Pics + Multiple Machines ?

10. Using POB SDK to convert .POV files to .POB files

11. Trees in PoV and include files producing include files

12. AD: BIG BIG SALE AT DYNAMIC REALITIES

13. Big Big Image