This conversation threatens to turn into six blind men of Indostan describing an elephant.
http://hinduism.about.com/od/hinduismforkids/a/blindmen.htm
Let me be number six - the one holding the tail, since it is the most dangerous one if you've ever seen an elephant defecate. I feel the "out of memory" failure is erroneous - but does signal a common rendering problem.
Please join in with your own necromancy about this issue.
Some comments:
• Users often misuse the saved Archicad file size as indicated on disk to predict the project's rendering challenge. This is the fault of GDL efficiencies. For instance: an Archicad model containing one million identical bookcases is a tiny file until it is assembled in 3D where every polygon of the model must be visually established. You can never know the size of your model or its rendering challenge from the saved file size.
• While it is conceivable that in machines with minimal RAM, that a 3D file could be assembled to be so large that there might not be enough memory, Archicad's swap-to-disk routine can fill a hard drive with data related to the rendering process - the temporary file. You would hear this happening and it would take some time before the system ran out of disk space.
• Keeping some sort of process monitor open can teach you about how ell your compute manages its resources. For instance, My Mac G5 2x2 from four years ago, having 3.5 Gb of RAM NEVER accesses more than 1.8 Gb even when rendering complex scenes, and I have done many complex renderings with overlapping refracting elements and numerous light sources.
• Imaging textures in OpenGL DOES take more resources, so turning them off saves the computer some effort. If you want even faster renderings, minimize the 3D assembly time by using wireframe instead when starting a rendering. You might also consider reducing some of the other OpenGL qualities when doing a shaded view just for the sake of speed in mere 3D imaging. On the other hand, the OpenGL rendering aspect - distinct from processing the 3D model assembly aspect handled internally - should be handled by the graphics routines and RAM on your video card, leaving the foundation resources alone.
• My experience is that "out of memory" failures don't happen because of lacking computer resources, but rather, from corrupted elements. You work away happily and think all is well until you make an impossible slab or place a object with bad parameters. The computer then "has a snit" resolving a mobius strip-like slab opening and "VOOM" all the resources are consumed and you are "out of memory."
In earlier versions of Archicad, the dialog didn't offer to rationalize slab errors like it does now, and ignoring that warning when assembling the model is perilous for 3D. OpenGL has error tolerance that LightWorks doesn't, so a successful 3D view doesn't guarantee a rendering.
• Things can go wrong in files. This might seem like Geek Necromancy Voodoo [GNV], but sometimes I have fixed problems by copying the file to another volume under the belief that it will "rationalize" itself. I wear a black, pointy hat and repeatedly chant "No one is going to call ME an early adopter" while waiting for the copy to finish.
• Sometimes a corrupted situation is resolved by copying the entire 3D model into a new, blank file. While you might try this as an experiment, it is hardly a solution in complex projects with published layout views.
• Memory "leaks" do exist. I hear they are collecting in a big vat on a hill in Boston where you can smell molasses on hot summer days. If restarting your computer can solve the problem of getting a fresh start, that is great, but it is not my experience [limited to Macs.]
• Imported data CAN interfere with rendering since AutoCAD files can contain 3D data that is impossible to render - it looks irrational to the LightWorks engine.
• Always turn on the rendering report. It can help identify where the file went bad.
Dwight Atkinson
