workaround for crash on exit due to changing image used by material
I wanted to share a workaround that may be helpful. There seems to be a bug where sometimes, but not always, if you go into the material library and replace the image being used by pasting a new one, that will seem to work but when you try to exit and save your scene, Bryce will crash. However, unless I'm just getting lucky a few times in a row, it appears that the following can be done to avoid the crash so you can actually change the material again instead of being stuck with it forever:
After selecting the original object, instead of clicking its 'M' and pasting a new image in, Edit > Copy Material, create a new cube then Edit > Paste Material onto the cube. Click the cube's 'M', replace the image in the library, then save and exit. Restart, delete the cube, rerender the affected object that shared the same material that has been changed.
Hopefully this is helpful.
Comments
What platform are you on, PC or MAC? I personally have never experienced the bug you are describing. Sounds downright hairpullingly disastrous. Thanks for this work around. If I ever hit this bug I'll be happy for this thread.
PC.
It doesn't happen all the time, often it works fine. I'm not really sure how often it happens, except that I have encountered it often enough to finally make the connection between the exit crash and the material edit (not real obvious, I must have just made that one change and exited once, tried it again, and realized then). I had a few things that I wanted to change but couldn't in two recent projects, and the prospect of deleting and reimporting and trying to recreate the objects as a workaround would have been way too much work, so I started trying to find some workaround, and mostly by accident discovered this one.
Mostly my crashes when using the Mat room occur when I do too many changes without saving and closing Bryce down to clear the undo stack
There is another little known trick for clearing the undo stack without closing the file. The undo stack holds the most recent 15 actions. Some actions are more ram intensive than others. For example if you were to delete a layer of instances on a terrain the action will use much more ram than a simple repositioning of a sphere primitive. So to save time and headache with saving I simply replace the ram intensive actions within the stack with low ram intensive actions. At the point memory starts getting our of hand I will create a sphere or cube primitive and I will simply reposition the item about 15 times. Sounds nuts I know, but the ram usage most certainly drops for the scene overall and now I can continue working. Since I tend to build scenes with a lot of complexity and a single save can take 20 minutes....I simply cannot stop and save as often as I would prefer if I don't want to lose interest in the project.
One feature I'd like to see in the next Bryce update is more user control over Undo thresholds and behaviors. Being able to determine my own tolerance for undo stack depth or allowed total memory for Undo buffering seems like a wise choice.
It would be so nice if all work Bryce did was done in allotted HD space and not memory. Sean/Rashad, thanks for the tips.
If the scene saves fast - not taking so long as in Rashad's example - you can save the scene, create a primitive, then revert to saved to clear the undo buffer.
A really evil behaviour of Bryce is how objects in libraries are handled. When you click on the thumbnail of an object, it gets loaded into memory, even if you get out of the library by the X, it stays in memory. If you click on several thumbnails in the library while looking for the object you want, each object is loaded into memory. That an item loaded into a library and is later deleted stays in the library, filling it up, is also very bad.
There is another little known trick for clearing the undo stack without closing the file. The undo stack holds the most recent 15 actions. Some actions are more ram intensive than others. For example if you were to delete a layer of instances on a terrain the action will use much more ram than a simple repositioning of a sphere primitive. So to save time and headache with saving I simply replace the ram intensive actions within the stack with low ram intensive actions. At the point memory starts getting our of hand I will create a sphere or cube primitive and I will simply reposition the item about 15 times. Sounds nuts I know, but the ram usage most certainly drops for the scene overall and now I can continue working. Since I tend to build scenes with a lot of complexity and a single save can take 20 minutes....I simply cannot stop and save as often as I would prefer if I don't want to lose interest in the project.
One feature I'd like to see in the next Bryce update is more user control over Undo thresholds and behaviors. Being able to determine my own tolerance for undo stack depth or allowed total memory for Undo buffering seems like a wise choice.
Thanks for that tip Rashad, will save me lots of frustration.