If switching resolutions is the issue, consider if there is FCurve animation data being loaded onto parameters in the model.
There is a known issue in 2013 with generation of FCurve data taking ridiculously long (5000% longer - no exaggeration). I had to write a C++ command to work around the problem as our imports were taking forever. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Enrique Caballero Sent: Wednesday, January 29, 2014 8:09 PM To: [email protected] Subject: Re: Importing of Models Deathly Slow Matt your awesome, Thanks for all of the information, I am checking everything on the list now. I've just discovered that if i load a model in using the import menu, or via scripting it takes 7 seconds, but if i drag and drop it in, it takes 46 seconds for some reason. Not a big deal that one though. It seems the real heavy toll is taken when we switch model resolutions. Importing a vanilla referenced model takes about 7 seconds with no delta changes. Switching that same referenced model to another resolution, with no significant entries in the model delta, takes about 45 seconds. The resolutions that im switching to and from are both animation rigs, very light, and the delta has basically nothing in it Anyway I'll play around with it. And test against all of your suggestions. Thanks alot :) -E On Thu, Jan 30, 2014 at 11:53 AM, Matt Lind <[email protected]<mailto:[email protected]>> wrote: We're using 2013 SP1 (32 bit) and not experiencing any deathly slow imports. We have environments with 5,000+ referenced models, and while they do take a while to open because of their size, nothing along the lines of what you're reporting. I would check a few things that have caused us grief in the past: 1) Lights: for whatever reason if a model has a light and is imported into a scene as a referenced model, performance slows dramatically. 2) Model delta: If users have manipulated many parameters within a model, that will load up the delta property with many logged entries which you can think of as a pseudo construction history. The more entries, the more overhead you will have with referenced models. When a user does something, then undo's it, the end result will be correct, but an entry will be recorded for the modification, then another entry for the undo operation to undo it. Double the fun. I'd look for those entries and delete both instances to lighten the load. If the models aren't intended to be modified once referenced, for example, they're only placed in an environment. Then there is no reason for the delta to be loaded with many parameter entries. That's a sign of a user improperly selecting and moving the model around. For example, selecting the objects in multi-mode and dragging them into position as a set which would record 3 parameters for each object, instead of middle clicking to select the model and move it as a branch selection which records a total of 3. 3) Operators: look for performance intensive operators such as the Tangents operator used for baking normal maps with ultimapper. Any operator which modifies clusterproprety data on sample clusters (UV, Vertex Color, User normal) will be very computationally expensive. 4) Undo history: Default is 50. In the old days we got away with 10. The more undo's you have the more memory you consume and the more work Softimage has to do with updating the stack when each action is performed. Shouldn't be an issue with your scenes, but doesn't hurt to check by setting undo history to zero, then load the scene. 5) Events: I found this one the hard way. If you have any events to process the scene when importing or exporting a file (eg; siOnBeginFileImport, siOnEndFileImport, siOnBeginSceneLoad, siOnBeginSceneSave, siOnEndSceneSave, ...) it might be getting triggered when a model is loaded as a referenced model. Softimage treats loading of a model as a file import regardless of context. So whether you're importing the model, loading a scene, fabricating a new referenced model, updating referenced model in the scene, etc... softimage treats it the same under the hood - it'll trigger any event that deals with file import/export. If you're event script does something time consuming such as scan the scene or call databases, and you have many models in the scene, the event will be called once for each model. If you have events implemented, scrutinize the code with a fine toothed comb. 6) User interface: If you have a lot of views open, or performance intensive views like the FCurve open in a viewport, expect draing loading the scene. If you have realtime shaders enabled (such as High Quality viewport) or other shading intensive option, that puts load on the scene as the UI gets updated with each model imported. Set shading to wireframe. When in doubt, put UI to factory defaults. 7) Network: If data is coming from a server, check your network connection. Do you have any computers mapped which are not accessible, or slow? There's more, but I cannot remember off the top of my head. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Enrique Caballero Sent: Monday, January 27, 2014 5:51 PM To: [email protected]<mailto:[email protected]> Subject: Importing of Models Deathly Slow Hey everyone, We are having a recurring problem here that I have just learned to live with, but am hoping maybe someone can shed some light on it for me. Importing of referenced models has always been slow in Softimage, but around 2013 it got much slower for us. This is with extremely lightweight rigs as well. Simple props with limited geo, and usually incredibly few deformers. Nothing fancy. It is normal for it to take up to 3 minutes for us to load a scene that has maybe 10 simple props and 2 simple characters. The problem is worse if we try to switch rig resolution. And the problem becomes far worse if we import a character that has fur (ice strands), this can take significantly longer. Does anyone have any tips on alleviating this, or know if it possibly has something to do with our config? Our network is quite fast here, its actually very impressive hardware for such a small shop. So I would be surprised if its network related. Thanks, Enrique
