Would you like to react to this message? Create an account in a few clicks or log in to continue.

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files

2 posters

Go down

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files Empty Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files

Post by denz_arki2008 Mon May 25, 2009 11:40 am

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files
By Neil Blevins


I often get given reports of crashes or problems in a 3d file. While it's nice to have someone to turn to when you're in a bind, the truth of the matter is if you quietly hand all your problems to someone else, what will happen if that person is no longer there? What if their too busy? While the joy of creation is a beautiful thing, the realities of the situation is you're using technology, and technology can break, and unless you're lucky enough to have a TD whose sole job is to solve your issues, it's up to you to know how to fix your own problems, or at least simplify them as much as possible before presenting them to be fixed.

The art of finding and categorizing bugs is a very systematic and scientific process. First, you have a problem, your file crashes or produces weird results. Step 1, you need to know exactly what in your scene is causing this problem.

In general, assuming you're using a decent 3d program, a clean fresh scene with nothing in it should not crash or show any strange behavior. Assuming that to be true, the way to discover the problem in your scene is to get your scene as close to that initial state as possible. If you've eliminated every object and effect except one, and the file still crashes, chances are that one remaining object is your problem.

The following discussion is what I do when someone hands me a 3d file (in 3dstudio max), but can be generalized to other 3d packages. For the sake of this piece, we'll assume your problem is a crashing file, but again, a similar method can be used if you just have a file that's producing strange results. If it is a crasher, remember to save a file every time you change something, so you have something to go back to if your file crashes your 3d program.

1) Start deleting objects until the file no longer crashes. Many bugs occur because of a single bad object, or bad interaction between a group of objects. Remember to check for hidden and frozen objects. Once you've figured out which object(s) are responsible, try and delete everything not related to those objects, so you have a file with very minimal geometry. Try deleting any modifiers on your object, or collapse your object to a mesh and see if the problem goes away. One common way of figuring out which object is responsible is called the "Divide And Conquer" technique. Open your scene, delete half of the objects in the scene. If the file still crashes, then the object responsible is in that half. If the file doesn't crash, reopen the file and delete the other half of the scene. Then repeat the procedure, your scene becoming half as big with each iteration. This will allow you to figure out what the offending object is much faster without having to delete each object in the scene individually.

2) Remove any 3rd party plugins. Any plugin you're using such as a modifier, a special atmospheric plugin, etc, remove from the scene. If it stops crashing, you know it was a plugin compatibility problem, and report which plugin was giving problems.

3) Remove all environmental and render effects, remove background.

4) Assign a plain standard material to all remaining objects in your scene. If it stops crashing, it may be a material problem. If it does stop crashing, go back and start assigning standard materials to any object that you can while still retaining the crash.

5) Once you've simplified the number of materials, start simplifying the materials themselves, by slowly turning off reflections, refraction, removing bitmaps, and any other special features you're using in your material. If you find a single material that is crashing, try applying it to a simpler object such as a sphere. If it still crashes, then it's probably your material, and not your material interacting with a strange piece of geometry.

6) Take your current saved file, and merge the objects from that file into a fresh copy of max. If it doesn't crash, then it may have been a problem somewhere in the settings of your old file (or possibly your file got corrupted somehow). Open two copies of max, take your original file and start changing its parameters until you have default values assigned to everything. Check for crashes while changing parameters to see if you can narrow down which parameter may be causing the crash. If it crashes at render, for example, change a parameter, and try rendering. Does this still happen if you change all your render defaults back to their default value? Does it crash if you change your antialiasing filter? If motionblur is turned off?

If your file still crashes and you've done all these things, then you now have a very clean simplified file. If it's a crash with a piece of 3d software, then contact the makers of the software. If it's a crashing plugin, contact the makers of the plugin. You now have a very simple file to hand to them, and probably that vital piece of information such as "This geometry crashes the program" or "This setting when checked crashes" or "this material doesn't produce expected results when assigned to this type of object". For bonus points, try and reproduce the crash starting from a fresh clean file, and if you manage to crash it, report such an event with easy to follow steps for the programmer...
1) Open max
2) Open file
3) Press this button
4) Change that spinner
5) Render
6) Max crashes
Also giving info on what copy of max you have, OS info, type of hardware used in your computer etc.
While this may seem like a lot of work, if you don't do it, the person you hand the file to will have to do it, and they have the added issue of not being familiar with your file. And he probably has a bunch of other files to look at to. You have to ask yourself, would I prefer him spending his time figuring out what the bug is, or would I prefer him spending his time fixing the bug? Hopefully these steps can be of some use to you, and in fact they will, giving more precise and simplified bug reports means a programmer is far more likely to fix a problem promptly, and then you'll be back rendering in no time.
denz_arki2008
denz_arki2008
Punk Zappa
Punk Zappa

Number of posts : 1346
Registration date : 23/09/2008

Back to top Go down

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files Empty Reducing Memory Usage To Render A Memory Hungry Scene

Post by denz_arki2008 Mon May 25, 2009 11:44 am

Reducing Memory Usage To Render A Memory Hungry Scene
By Neil Blevins
Created On: May 19th 2006
Updated On: June 28th 2008
Here are a few tips to help you render a really large scene, or to render a really large bitmap of your scene in 3dstudio max. It's quite common to work on a scene for quite some time, doing 640x480 test renders, and then reaching a point where you want to render the scene at 2048 pixels or higher. You hit render, and bam, you get the out of memory error, and max crashes. Here's a few things to try.


1) Reboot: Before doing a new render, reboot your system, to purge all those extra processes that accumulate in ram as you use your computer.


2) Close all other applications: Seems obvious, but it's surprising how much RAM other small applications can take up. For example, iTunes seems to gobble up about 0.1 of a Gig of RAM, even though common sense seems to suggest it wouldn't take up too much memory.


3) Turn off the vfb: The "Virtual Frame Buffer" (vfb) which is now called the "Rendered Frame Window" takes up a lot of memory. So for the privilege of seeing a preview of your render, you're giving up potentially 200 to 300 meg of RAM, especially if you're rendering a 2k or 3k image. Go to the renderer options and uncheck the Rendered Frame Window Checkbox. If using a 3rd party renderer like Brazil, make sure you turn off it's frame buffer as well. Then set the renderer to save the result as a file in the Render Output section. This will save you tons of RAM.


4) Do a netrender: Even for still frames, even if you only have one computer, using backburner or a different netrenderer can save tons of RAM, because it doesn't need to fully load max to render your scene. So I usually set up my home computer as both the manager and the server, I go into max, I set off a netrender, making sure I have the "Initially Suspended" checkbox checked, then close max, then go into the Monitor and initialize the job (if you forget to submit the job uninitialized, your computer will try and load 2 copies of the scene, one in the netrender, and the copy of the scene that's already open in max, and that's a very bad thing). Check the manual for more info on using backburner, or whatever network renderer you choose.


5) Command Line Rendering: You can also use command line rendering to render your file. Just look up Command Line Rendering in the help file.


6) Upgrade to 64bit max: Starting with max9, max now comes in two flavors, 32bit and 64bit. To use the 64bit version of max, you'll need a 64bit compliant computer and a 64bit OS like winXP64 or Windows Vista 64. This version of max can use way more ram than a conventional 32bit system. So you can add 4 Gigs, 8 Gigs, pretty much however much RAM you need for your scene, rather than the standard 2 Gigs that 32bit systems generally max out at. One note, many plugins compiled for 32bit max have not been compiled for 64bit max yet, although this will change as time progresses, so before making the switch, make sure all the plugins you need have 64bit versions as well.

7) Turn off bitmaps displayed in the viewport: This doesn't reduce memory for a netrender, but if you want to do an interactive render inside max, it's quite possible that a bunch of your memory is being eaten up displaying maps in your scene in the viewport (I was surprised the other day when I found out about half a GIG of RAM was being used up displaying a bunch of large maps in the viewport). Just go to the Views Menu and click on the "Deactivate All Maps" option. Note: In max 2008, this feature has been changed, now go to Views, Show Materials In Viewports As, Standard Display.


8) Turn On Conserve Memory: If rendering in Scanline renderer, go to the Render dialog, Renderer, Memory Management, and check "Conserve Memory" The help file is kinda vague about this feature, but it claims "When on, rendering uses less memory at a slight cost of memory time. Memory saved is in the range of 15 to 25 percent. The time cost is about four percent."

9) Bitmap Pager: Go to Customize, Preferences, Rendering, Bitmap Pager, turn it on, and play with the settings. It can drastically reduce the amount of memory necessary for scenes with large bitmaps, or for rendering very large images. The settings can sometimes seem like black magic (and I think they are), but here's some basic information I've found after doing a bunch of tests and speaking to some knowledgeable people. Lets say you have a scene with 100 bitmaps in it. The bitmaps all vary in resolution and disk size, say between 100k and 11,000k on your disk. Now lets say your goal is to use the least amount of memory possible (although note that the less memory you use, the slower the render will go).


Making the Page Size large means fewer page files, since all the paging goes to a few large files instead of a bunch of small files. Changing this value doesn't seem to affect memory much, personally I'd set this to a largish value, so that large bitmaps don't get broken into too many small pages.
The smaller the Bitmap Size Threshold, the more files that are paged. This is because more files are larger than this threshold, so they get put into the pagefile. So for less memory usage, make this a small value.
Making the Memory Pool smaller means the less stuff in memory and the more stuff that goes to disk. So make this a small value to conserve memory.
Also of note, it seems that changing your settings requires a restart. So if you change your settings, you then need to save your file, and restart max to have those settings take effect.


10) Smaller Buckets: If using a bucket based renderer such as Brazil or Mentalray, try reducing the bucket size. A smaller bucket size will mean less stuff needs to be in memory to render that bucket. This should render slightly slower, but can reduce the memory requirements, especially if you're using high sample rates.


11) Strips Setup Dialog: This feature lets you render your image in chunks, and is useful for rendering very large bitmaps. First, do a netrender, and when the Network Job Assignment dialog comes up, check Options -> Split Scan Lines, then click Define to set it up. Do a search for "Strips Setup Dialog" in the help file for more information on how this feature works.


12) Reduce Poly Count: Now might also be a good time to ask yourself if you've optimized your polycount. I know you had tons of fun modeling every tiny detail on that car, but do you ever actually see that bolt you modeled in the shot? Do you really need a 30 sided cylinder for that object in the far distance that's 2 pixels tall? Take a moment to go through your scene and see if you can be a bit more economical, you'd be surprised what you may find.


13) Reduce Bitmap Size: In the same spirit as #12, do you really need a 4k map for an object that's 10 pixels tall on the screen? Always keep your original highres map backed up, you never know when you may need it, but instead of reading in the full 4k map in max, try making a 1k of 512 pixel version of the same map, see if you notice a difference. You'll certainly notice a difference in memory usage.


14) Remove Unneeded Mapping Coordinates: UVs take up RAM, so if you have a 10,000 poly object with 3 or 4 UV sets (i.e., you've applied a number of UVWMapping or UVWUnwrap modifiers set to a number of map channels), but the material assigned to the object doesn't require UVs, you're wasting a lot of memory. Use the Remove UVs Utility to kill those unused mapping coordinates and save memory.


Hopefully some of these tips will help you render those hard to render scenes.
denz_arki2008
denz_arki2008
Punk Zappa
Punk Zappa

Number of posts : 1346
Registration date : 23/09/2008

Back to top Go down

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files Empty Re: Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files

Post by mammoo_03 Mon May 25, 2009 10:24 pm

sir denz, maraming salamat for sharing.
mammoo_03
mammoo_03
The Exhibitioner
The Exhibitioner

Number of posts : 2417
Age : 44
Location : manila, makati, dubai
Registration date : 20/09/2008

http://www.coroflot.com/archmlcm

Back to top Go down

Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files Empty Re: Why Is My File Crashing? A Short Essay On Reporting and Solving Bugs and Crashing Files

Post by Sponsored content


Sponsored content


Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum