Forum: Bryce


Subject: Does this crash Bryce 7.1 pro on your system?

ddaydreams opened this issue on Feb 12, 2012 · 19 posts


rashadcarter posted Wed, 07 March 2012 at 6:40 PM

Quote - I crash on the following.

-Every use of the Instance Lab crashes my system within seconds of trying to manipulate the different instances. 

-Use of the spray render about 50% of the time, or at least locking up the program forcing me to close out and re-enter.

-The Tree Lab if I change certain functions.

So, I'm crashing about every 15 minutes or less.

Then again, I have very low ram on my system (256mb).  Was fine for Bryce 5, but Bryce 7 kills it like a plate in a shooting gallery.

So far, I'm very disappointed.  I can't get a single scene done because it crashes before I can save it.

 

I have made sense of the IL. I was on the committee that helped Daz3D to build Bryce 7, so I've seen how this works under the hood. I will help you out with this if you are still interested.

Admittedly, 256mb is very little ram. It is not surprising you are having some issues. But do not despair. So long as there is sufficient space on your hard drive Bryce will still access 2gb of ram, but it will be very slow because it will write everything above 256mb to the hard drive which recovers memory slower than ram. Still, you should be able to see files much larger than 256mb. There are several reasons why you might be getting crashes. I will explain them and give some ideas to help you out.

Before I get into specifics let me cover some general stuff.

Bryce remains a 32 bit application limiting file sizes to less than 2gb. This can be changed with LAA (Large Address Aware) which will allow usage to go as high as 3.6gb. Further, Bryce still does not have multiprocessor support for any functions other than rendering. All Lab navigation and implementation of modifcations during a session are ported through only a single processor.

When working with lots of instances several problems arise due to the lack of multiprocessor support.

The "virtual" polygons comprising an instance are not as virtual as one might think and must be counted as real in some cases. Back when Bryce was first designed there were only but so many polygons one could cram into a single scenario, now with instancing that number has increased 10000 fold. Therefore, it is natural that scene navigation becomes super slooooooow. It can sometimes take minutes for even simple modifications to be applied to a complex scene, at which point one might think the software has crashed but alas it is still working. It can take half an hour to save a scene that is loaded with instances. Keep all of this in mind so you know the difference between a true crash and a slow working situation.

Always keep the Task Manager open whenever you are running Bryce, this is the only way to avoid crashes due to memory. Files larger than 1.7gb probably will not save properly (unless using LAA) so save before that point. Also, it is important to note that files larger than 1.7gb will not reopen (Again, assuming there is no LAA)

I have found that when instances are first painted the ram usage associated with the new instaces is not fully reported in the Task Manager. If you paint 100mb worth of trees during a session, when you close then reopen the file you will see the memory usage is actually 500mb. If you paint 500mb worth of instances into a scene, it will reopen at nearly 2gb or possibly more, leading to a crash.

I should state that the undo buffer in Bryce is very primitive. The ONLY way to clear the buffer is to close then re-open Bryce. The buffer tries to remember the last 15 modifications. no matter how massive. Creating a layer of instances counts as a single but extremely large modification, thus the memory keeps it stored for 14 susequent modifications in case the user decides to undo it. This grows memory quickly if we delete the layer and go painting another right away. Try to avoid using the undo button whenever possible. Better to close and reopen

Now lets talk about the Instance Lab itself. There are two screens, the Brush Editor and the Painter. One big mistake people make is jumping directly into painting. You must first assign the Brush as the object you plan to paint. Assign rotation, scaling, all of that. After you get your pie chart adjusted, now you can start painting.

In the Painting screen, try NEVER to paint continual strokes, instead use dabs. If you apply continuous strokes you will find the resulting instances will appear to be aligned and not randomly placed no matter how high a randomness setting is used in the IL. To get a nice natural look, you need to use brushes of many various sizes and what not. Dabs not strokes! Strokes also causes us to paint more instances than we intend, leading even faster to an out of memory crash.

Important Note: You can paint along the Normals of the object by pressing ALT while painting. This is how you'd paint onto a sphere for example.

Lastly, when instances are first born they are grouped as Unnamed. This group is linked to the target object. Often the target object will be a terrain. I have found that it is best to ungroup the instances and regroup them once they are born. This is because if you let them remain linked to the terrain, if you make any changes to the terrain geometry it undermines the logic of the attached instances and causes a crash. The vertices of the terrian move around beneath the innocent instances causing confusion within the application. So long as there are no instances linked to the terrain, no problems will arise if you make further changes to the terrain.

Grouped objects do not rotate as they should. There is a workaround but I dont want to overwhelm you with too much today.

Objects high in polygons cost more to instance than objects low in polygons. Imported meshes require more memory than primitives as we all know. So plan ahead, keep in mind the memory usage during the session and the expected usage upon re-opening. Consider how slooooow the wireframe navigation will become when the scene is loaded with virtual polygons. LAstly, almost forgot to add, it is best to use "Show as Box" in the Attributes of your grouped Instances, this will take a lot of strain off the screen updating, speeding up navigation.

Hmm, that was a lot so go ahead and digest what I gave you and let me know if more questions arise. Best of luck. To give you an idea who I am My gallery is located here: http://www.renderosity.com/mod/gallery/browse.php?user_id=496780