files sizes

 From:  Michael Gibson
4196.8 In reply to 4196.5 
Hi macray,

> Another thing you might take into consideration: the
> amount of RAM that is used.

Yes, that's actually what limits things - not really file disk size specifically.

When a file is loaded, the memory consumption of it in RAM is a lot more than just the disk size, for a lot of various reasons but one big one is information calculated for the display.

If you're working with large files that are getting close to the maximum amount of memory that can be used (about 1.6 GB on a 32-bit system, or something like 3.6 GB on a 64-bit system) you can help reduce memory consumption by turning down the display settings as mentioned in the 2nd post in this thread. The lower density display mesh will look a bit chunkier than the default one but it will reduce memory use by quite a bit.

You can also make more memory available to MoI by just running it on a 64-bit system instead of a 32-bit system - even though MoI is a 32-bit program if you run it on a 64-bit system it will have twice as much memory available for it to use. That's because on a 32-bit system the upper half of the 32-bit memory address range is reserved for use by the operating system, but on a 64-bit system that's not the case and the full 32-bit address range is given to the application to use.

> With my file I'm close to 1.5gb RAM usage and I experienced some
> strange crashes of MoI that never occured ever before when I tried
> to export too many things at once via .obj.

Yes, running out of memory is a particularly tricky thing to guard against, it's probably the easiest way to crash MoI. Unfortunately it's a particularly difficult thing to deal with well because it can alter program code flow at quite a lot of different points.

So to make things run smoothly you don't really want to hit an out of memory situation at all, keep a bit more of a buffer before that happens - lower display settings, or work on things as separate files instead when you are getting close to this limit.

> As I don't see a 64bit version mentioned anywhere this
> might be a bottle neck in future for me - any plans to
> change that Michael?

It takes quite a bit of work to maintain multiple versions at the same time, so right now I don't really have any specific plans to have a 64-bit version. Maybe at some point in the future when I can just switch to only have that and not a 32-bit version at all, but that will probably be quite a while.

There are actually other things that are more important than that for handling large data sets, like having an instancing system.

But as I mentioned above, there are benefits to running the current 32-bit version on a 64-bit operating system, you actually get double (or even a bit more than double actually) the amount of addressable memory if you do that.

So if you're getting close to a 1.6 GB RAM usage right now, running on a 64-bit operating system would actually help deal with that.

- Michael