Sat, Nov 30, 11:44 PM CST

Renderosity Forums / Bryce



Welcome to the Bryce Forum

Forum Moderators: TheBryster

Bryce F.A.Q (Last Updated: 2024 Nov 26 4:28 pm)

[Gallery]     [Tutorials]


THE PLACE FOR ALL THINGS BRYCE - GOT A PROBLEM? YOU'VE COME TO THE RIGHT PLACE


Subject: Question: Limit on # of objects in scene?


clyde236 ( ) posted Wed, 12 February 2003 at 4:35 PM · edited Sat, 30 November 2024 at 11:40 PM

Hi all, I have a quick question. Does Bryce have a limitation on the number of objects that can be included in a scene? I am making a house model, and I need to populate the rooms with objects that would be found there (i.e. kitchen articles, bathroom articles, etc.) This is making the file quite large, which is no problem (I'm running a G4 with 895 MB RAM, 40 GB hard drive and have allocated 300 MB to the memory available to Bryce) but of course, as the file grows (and I use quite a few .dxf files) it naturally takes longer to load. This is not a complaint, I expect it. I'm just worried that I may "overpopulate" the model to the point where Bryce won't work with it anymore. That hasn't happened yet, and I am hoping it won't. Unfortunately, because of lighting influences, I can't really break the model into component structures (which would be smaller) because the loss of some components alters the others. It's hard to explain...but if you live in a glass house, you'd understand! Anyway, do you think I am in danger of making a file that Bryce will eventually be unable to work with? I can't find a limitation notice in the manual, but there are a lot of things I can't find in the manual! Thanks for your help!


Stephen Ray ( ) posted Wed, 12 February 2003 at 8:01 PM

If I recall correctly Bryce imports the model then converts it. The conversion process is all done using ram ( does not swap to disk ). If you run out of ram during the conversion, errors occur. I've never had a project go corrupt, and I've made some over 400MB, but I have heard others who have. There's always save as if you want to be safe.

Stephen Ray



shadowdragonlord ( ) posted Wed, 12 February 2003 at 10:18 PM

Aye, it should be enough RAM to do the job, although on a MAC who can say? But, internally, I don't think Bryce 5 has limits like number of objects/number of polygons... For example, all of these complex scenes we create will actually be realtime, travellable worlds at some future point, when processor speeds are fast enough to make render times obsolete. Keep that in mind, the best is still yet to come! Hell, in ten years they'll be making video games set in our old BR5 files!


Doublecrash ( ) posted Thu, 13 February 2003 at 4:39 AM

I work with a very limited RAM (128), and I didn't encounter any problem so far, even with over 200Megs file with 10,000+ objects (the most crowded scene so far), so... I think you have the amount of RAM that enables you to handle large scenefiles. Save often, specially before importing a DXF or a complex model... I know it could be a pain, specially if the file is very large, but it shields you from nasty surprises. Stefano


paulo ( ) posted Thu, 13 February 2003 at 9:28 AM

Bryce does have limits. Remember, the size of your file is limited to the amount of RAM your system has. Bryce will not make use of virtual memory, or paging files. Ex: if your file is 100 megs, you need to have at least 200 megs of RAm (hard). As for file size, the maximum file size bryce will accept is a 1 gig. file. Number of objects and number of polys is also important. From what I have tested, the max number byrce will accept is about 20-25,000 objects at around 1 gig. These tests were performed on a windows machine with 3.5 gigs of RAM running dual 2.4 Mhtz Xeon processors. WIN XP.


Rayraz ( ) posted Thu, 13 February 2003 at 11:48 AM

tens of thousands of objects aren't neccesarily a problem however I suggest you make several scenes wich can be merged for the final render. That will keep the loading-saving times short and if one file goes corrupt you don't lose the whole project. Working with split-up scenes also improves the workflow because of the lower complexity of the seperate scenes.

(_/)
(='.'=)
(")
(")This is Bunny. Copy and paste bunny into your signature to help him gain world domination.


Doublecrash ( ) posted Thu, 13 February 2003 at 1:40 PM

Hm... the size of my file is limited to the amount of RAM in my system? Paulo, for me it's not like this, I swear... I've worked on files larger than the 128Megs I have. Stefano


Aldaron ( ) posted Thu, 13 February 2003 at 2:35 PM

The only thing memory really limits is the size of model that can be imported. Otherwise Bryce DOES use virtual memory.


Rayraz ( ) posted Thu, 13 February 2003 at 2:45 PM

And it uses a lot too. The TMP-file act's like it's small, but when your computer chrashes bryce doesn't get the time to delete it and you can see the actual size after rebooting. I've had that problem once with a scene of more than 1Gig. I got an out of memory error, but when I checked the amount of data on the disk there was 6GB used while the partition was 7,5 GB. 1.5 GB just seemed to vanish into thin air. But after the crash and reboot the TMP-file suddenly showed it's real size and it was actually a 1.6GB file! The bryce TMP's look like they are size-stealth to me. I now have 2 new harddisks, so the problem is gone. Speaking of memory: Does anyone know how to delete the _restore directories that windows makes? I can't delete them the normal way. Windows won't let me do that. The problem is that my _restore dir on c: is more than 1 GB and it's still growing with every crash of 'system stability degrading anomaly'. The ones on my D,E and F drives are only 3KB, so I can live with that, but 1GB of files that I never use and can't delete is just a shame.

(_/)
(='.'=)
(")
(")This is Bunny. Copy and paste bunny into your signature to help him gain world domination.


SevenOfEleven ( ) posted Sat, 15 February 2003 at 8:04 PM

I wonder if the _restore dirs can be deleted from a dos box? Why won't windows let you delete the file? Might want to do a scandisk to make sure the disk drive paperwork is ok. I have a picture that has 6 digits worth of polygons and it will be getting more. Bryce is starting to chug and regular operations are starting to take more time. Select something and wait for the rainbow lollipop to go away and stop spinning.


sriesch ( ) posted Sat, 15 February 2003 at 8:11 PM

I have one scene that I kept adding objects to and somewhere along the line it suddenly started displaying all objects as boxes only instead of the normal flat shaded mode while I was moving them (they revert back to shaded mode when I let go of the mouse button.)

I'm not sure if this is a problem caused by some of the objects I have, a limitation of my graphics card (can only display x number of shaded objects at once or something), but perhaps it could be some limitation within Bryce where you can't have more than a certain number of objects or polygons or something at once in that mode.

I tried deleting a bunch of stuff, and after most of it was deleted, the shaded object mode started being used normally again while moving objects. It works normally at 1000 objects, and it fails at 1550 objects. I haven't bothered trying to narrow it down from there.


Aldaron ( ) posted Sat, 15 February 2003 at 8:29 PM

The higher the resolution of the meshes you have set to display the higher the requirement of RAM to use. When you start to reach this limit Bryce converts meshes to bounding boxes to save memory. You can reduce the resolutions manually to save memory and thus work with more objects, etc.


Rayraz ( ) posted Sun, 16 February 2003 at 12:01 PM

Dos boxes also don't work. It's not a problem according to scandisk either. It's probably some freaky Microsoft thing. there's .Cab-files in there and backup's of the registry. those can come in handy, but keeping 12 different versions of back-upfiles at once is a bit overkill I think.

(_/)
(='.'=)
(")
(")This is Bunny. Copy and paste bunny into your signature to help him gain world domination.


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.