Author Topic: ATTN: Ferry - Question about how Lumion handles files  (Read 2247 times)

cpercer

    Reputation: 20
ATTN: Ferry - Question about how Lumion handles files
« on: January 21, 2011, 12:02:38 am »
January 21, 2011, 12:02:38 am
I understand that Lumion collapses meshes based on material, so which is better: a single .dae file with 100 instances of the same object (file size - 139,740 KB) or a single .dae file of 1 instance of the same object (file size - 1,743 KB) placed 100 times within Lumion?

Aaron

    Reputation: 80
ATTN: Ferry - Question about how Lumion handles files
« Reply #1 on: January 21, 2011, 12:11:28 am »
January 21, 2011, 12:11:28 am
Good question cpercer! I've been wondering about this too.

cpercer

    Reputation: 20
ATTN: Ferry - Question about how Lumion handles files
« Reply #2 on: January 21, 2011, 04:31:09 am »
January 21, 2011, 04:31:09 am
Another thing I was wondering is if Lumion loads all the objects in all the scenes that have been created automatically for every scene or is the library like a pre-load staging area and only the imported objects used in the scene are loaded?  I had a memory crash the other day and I wonder if somehow all the objects in the library had an effect on memory usage.

ATTN: Ferry - Question about how Lumion handles files
« Reply #3 on: January 21, 2011, 08:22:58 am »
January 21, 2011, 08:22:58 am
If you place 1 object 2 times it goes into the bake engine. So memory wise it is better to have 1 small and place that 100 times. Then having it split in 2. Since a big model that you use only 2 times will then be 3 times in memory. If you create only 1 then there is not a big difference. However applying materials might be faster on the small object.

 

If you load a new scene all old objects except trees are removed from memory. Then depending on which models are used in the scene those files are loaded in memory and the baking engine bakes what is needed to be backed. One extra point of advanced information is: When you move an object it unbakes and is draw per instance for the group it is in. So for example 100 characters are baked then moving 1 unbakes its group which might be 20 characters so you get 24 drawcalls 4 for the remaining 80 characters and 20 for the unbaked characters. Then going to the weather section it bakes the 20 back to 1. You might see the small hickup when going to weathermode of the bake engine. This also means that if you move 5 characters of the 100 which all where in a different group you might get 100 non baked instances. So if you are moving a lot of items sometimes go to the weather section to bake it all and improve a bit of framerate. 

 

If this story is hard to understand just ignore it all it all should work automatically for you so don't worry Wink

 

If Lumion tells you 'out of memory' that is CPU memory! We will soon also get out the 64 bit version so you never have that anymore.

Aaron

    Reputation: 80
ATTN: Ferry - Question about how Lumion handles files
« Reply #4 on: January 21, 2011, 10:29:52 am »
January 21, 2011, 10:29:52 am
Oooooohkay Confused I'll have to read this a couple of times but if I fail to understand it with my relatively simple brain, I'll just run it through Google translator

for stupid people trying to understand something complicated Laugh

ATTN: Ferry - Question about how Lumion handles files
« Reply #5 on: January 21, 2011, 01:27:28 pm »
January 21, 2011, 01:27:28 pm
There is a reason we create Lumion and you use it Wink 

 

But you asked so you got the answer.

Aaron

    Reputation: 80
ATTN: Ferry - Question about how Lumion handles files
« Reply #6 on: January 21, 2011, 01:34:20 pm »
January 21, 2011, 01:34:20 pm
Already halve way through processing the info. By the end of the day I'm sure I'll have figured it out completely Laugh

The soon-part on the 64-bit I consider a very welcome additional piece of intel.

Thanks again Smile

ATTN: Ferry - Question about how Lumion handles files
« Reply #7 on: January 21, 2011, 01:36:22 pm »
January 21, 2011, 01:36:22 pm
In software development soon is always relative :P

cpercer

    Reputation: 20
ATTN: Ferry - Question about how Lumion handles files
« Reply #8 on: January 21, 2011, 05:11:18 pm »
January 21, 2011, 05:11:18 pm
So I guess I exceeded the 3 GB limit for Lumion.  I am trying to get to the bottom of why this happens so I can limit the early morning insanity that comes with a deadline and a memory crash!

Is all the loading of objects done in the GPU memory?  What is it that causes Lumion to run out of CPU memory, the number of objects or accumulated object size?

ATTN: Ferry - Question about how Lumion handles files
« Reply #9 on: January 21, 2011, 06:10:09 pm »
January 21, 2011, 06:10:09 pm
All models also exist in cpu memory. But to minimize the cpu memory one thing that will always help a bit is restart Lumion which should be fast before loading a massive scene. If you see the out of mem you probably saw it during import. Use Collada for the least memory consuming import. Load it in an just started Lumion and quit after importing and restart with gigantic models. Of course the 64 bit verison solves these problems. Certainly with a 3gb 580 GTX :P

cpercer

    Reputation: 20
ATTN: Ferry - Question about how Lumion handles files
« Reply #10 on: January 21, 2011, 10:00:52 pm »
January 21, 2011, 10:00:52 pm
The out of memory message came while placing people in the scene.  Then again while trying to reload the scene after crash.  After three or so messages, a file finally loaded but some of the meshes had been deleted (one specific material). I do agree that collada is the best method to import models into Lumion but only because the materials are much better maintained.

For example, when importing an FBX version of a model the file size is 54,558 KB, but the meshes of differing materials are often combined or will not allow the application of any material at all.  Maybe this has more to do with Autodesk shared materials vs. Standard materials.  The same model imported as a collada has a file size of 256,748 KB and I rarely have material problems.

Obviously for stability purposes, I'd rather use the smaller model.  Would OpenCollada plug-in reduce the file size compared to the Autodesk Collada export?  Or maybe using standard materials on an FBX would work.  I'm just using max as an intermediary for Revit conversion, so I'm not an experienced user.  Any hope of improving assignments of mental ray materials?

ATTN: Ferry - Question about how Lumion handles files
« Reply #11 on: January 22, 2011, 08:05:35 am »
January 22, 2011, 08:05:35 am
You might as well use the large DAE file since even if it is compressed eventually it all becomes uncompressed anyway. I am not a mental ray specialist but i do know that many advanced material tricks are not possible in realtime and must be faked by using the standard material.