Mboncher,

Thanks for checking out my stuff Mboncher!!!!

Hopefully you have had the opportunity to read and follow the IL tutorial I mentioned. If not then some of what I'm about to post might not make sense.

Even though they are instances, they still carry a certain degree of information. At the very least an instance still has a location in 3d space requiring no less than 3 parameters, a rotation of three parameters, and a size requiring three parameters and then there is the source geometry which must be kept track of. This is why instances cost so much on memory.

A few things to keep in mind

Lots of people mistake Bryce slowness as a crash. Actually, the Instance Lab (IL) rarely crashes. It does however get so slow that users assume there must be a crash. If no crash report flies up, then it is not an actual crash. In some scenes such as Alpine Valley it can take a full 2 minutes of thinking before it applies even the slightest changes to a scene. This is super frustrating. This is the reason that preparation is so key. You must always have a plan, never play it by ear on something like this. Make lots of test renders before trying to settle in on any specific choices. Try to get the scene set up as best you can before you sgtart painting instances because as you know things slow down a lot once you start painting. Saving scenes with instances can take up to twenty minutes!! Re-opening scenes with instances can also take an eternity. Until we get 64 bit and multi-processor support for all functions, we will be dealing with this slowness.

Bryce has some odd limits within itself. The more polygons in the source geometry, the faster its resulting instances will consume memory by means of virtual polygons. Virtual polygons are just like real polygons and there are limits to the number of total polygons a Bryce scene can handle. But there is also a limit on the total number of instances a scene will tolerate, this is due to the 9 or so parameters required by each instance for it to exist. This is why a single blade of grass even though it is extremely low in polgons cannot be instanced a billion times to cover a landscape with grass. You are better off creating a clump of grass blades as a single object and paint that clump all around as this is more efficient. You are looking for a balance between total polygons and total number of instances painted.

As above mentioned, the virtual instances still have geometry. The wirefram view tries to represent this geometry. Bryce only uses multiple processors for rendering, it only uses 1 core for scene navigation. That's why complex scenes are so slow to navigate. When Bryce was first released there was no risk of the wireframe becoming so complex it would slow down the user. But with instances this is easy to do sadly. The best solutiuon is to use the "Show as Box" in the Attributes of the tree before you start painting it onto the terrain. This way all of the resulting instances will also be Show as Box and you will find navigation speeds remain tolerable even in really complex scenes.

Note: If you are not careful you can cause a crash when painting instances onto a terrain. As you may well know, when you first exit the instance lab after a painting session the resulting instances will be called "Unnamed." Unnamed is linked to the target object, in this case a terrain. It is best I find to always ungroup UNNamed and re-group it with a new name. (This process could be slow and it could require you to re-set the show as box option to speed things back up).

If by some chance you need to use terrain clipping, you dont want the instances linked to the terrain during that time or a crash will surely occur. Say for example that before I start painting I clip a terrain so that the bottom part is not visible in the wireframe or render. I am assuming that there is a water level and clipping the bottom of the terrain will prevent me from painting plants into areas that will eventually be submerged in water. I conduct my painting session like normal, I exit the IL, and I then decide I want to unclip the terrain. Well, if your instance group is still linked to the terrain Bryce will crash. You need to unlink the Unnamed group from the terrain before you do any more clipping. The reason this causes a crash is that instances are assigned to vertex and face numbers. Altering the clipping will break the associations because it alters the number and sequence of the vertices the instances are attached to. Resulting in a crash. It sort of pulls the carpet out from underneath the instances.

Last note on instances. Keep a close eye on memory usage at all times. Always keep the task manager open and always watch page file usage. For some reason after a scene with instances has been saved and re-opened the memory will be much larger than it was during the original session. I am not sure why this is, but as a general rule if you paint 100mb of instances in the origianl session it will cost around 400mb after being re-opened. I'm not sure if this is due to some corruption or legacy bug yet to be squashed. This is one area where crashes can pop up and surpise you because last time you checked memory usage seemed fine. Nope, sometimes you get surprises.

On the subject of a road cutting through a terrain, you will find this information as well over at Daz3d.com. A power user and buddy of mine for many years David Brinnen has a host of Youtube videos related to Bryce and i think I recall a few that deal with cutting roads and trails into terrains. Look him up and you will be very pleased.

Large Address Aware is extremely awesome. It is a stand alone program that you can use to extend the memory of not only Bryce but almost any 32 bit application. it does require at least 3gb of system ram though. I am not at my home computer to find all the links for you just yet. But I will look into it when i get back into NYC.

Talk to you soon.