RE: Scene crash on startup - any advice
Nested models is where you went wrong. Don’t nest models inside of each other, especially if they’re referenced as it creates a situation where dependencies cannot be resolved should one of the nested items get updated. Softimage has decent infrastructure for managing dependencies between scene and referenced model, but not when the dependency is between two or more models. If you have many copies of the same model throughout your scene, consider using instances which eliminates the problem of duplicate material libraries and accelerates interactivity of your scene considerably. This will also reduce file size quite a bit as you only need one master model for the instances, not one referenced model per instance as you’re doing now. You can use standins as you mentioned. The difference between the two is instances will be of greatest benefit in the viewports whereas standins are of benefit at render time. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jon Hunt Sent: Sunday, August 03, 2014 1:34 AM To: softimage@listproc.autodesk.com Subject: Re: Scene crash on startup - any advice Thank you both Peter and Matt for your lengthy replies. I've found your replies informative and interesting. I am trying best possible to work to best practices and feel a little reassured! I am not doing much else other than laying out the models in the scene. I do have some geo in there (landscape) and some models I have made local. In summary the scene is a large camera move that flies through a village that is fairly dense with houses. I have built 3 variations of house with windows/doors/chimneys and so it is modular so I can avoid any repetition and build a custom house. This inevitably means I have reference models inside reference models. However through research I have not gone more than 2 levels deep with them and arranged the embedded ref models inside nulls for any SRT transforms. All models have master files that I have setup and refer back to when I make any changes. I think where I have gone wrong is if I want to make another variation of a house on the fly, I have taken a house model and made the top part of the hierarchy local and duplicated sub parts which are still referenced in. In doing this it has prompted me to share or copy material libraries. If I want another variation. I should build it in master file and bring it back in. I have done this 4/5 times in say 40 models, so I know where to fix it. Another workflow I could be using (should be using?) is stand ins. I did do a test render on Friday without using them and with a basic lightning setup up it munched it up. I am not overly concerned about the scene being to heavy now. I am unsure of this crossover as to when I should be using standins verses ref models. This is a separate conversation I am sure. I also have a deadline looming and need the darn shot rendered! Thanks, Jon On Sat, Aug 2, 2014 at 9:42 PM, Matt Lind speye...@hotmail.commailto:speye...@hotmail.com wrote: A scene size of 53 MB containing mostly referenced models indicates there is still a lot of data, such as animation (FCurves) or data applied on top of the referenced models in model deltas, still in the scene. the first thing to try is rolling back your scene to a previous version (including referenced models) if you have been using source control. The done fixing hidden cluster error indicates a geometry problem. With a scene containing many referenced models, it's likely one or more models was imported into the scene as a referenced model, modified in some way that applied a dependency which needs geometry information, and the referenced model was later edited offline outside the scene. Next time the scene opens, Softimage is surprised because the referenced model is in a different state than the last time the scene was saved and has all this dependency data it doesn't know what to do with, so mayhem breaks out. For example, if you applied an object-to-cluster constraint, the constraint operator has a dependency on the cluster. If you delete the cluster from the referenced model outside the scene, the next time the scene opens and uses that model, Softimage will see the constraint operator and try to connect to a now non-existent cluster, then get confused. There are some topology operators which generate hidden clusters behind the curtains from user view which are used as a scratchpad for calculations. It's very possible the above scenario has occurred and the operator's cluster in question cannot reconnect to it's dependencies because one or more of it's inputs has disappeared from the model being changed outside the scene. One test is to open each referenced model locally in an empty scene. Check the script log before doing any work on each model, if you get the error message again, then you've found the problem. Freeze its modeling
Re: Scene crash on startup - any advice
This Thread contains a great roundup of the (comparatively -extremely few-) things to keep in mind, allowing to (comparatively -extremely easily-) deal with (and effectively troubleshoot) virtually any project scope with SI, and is what makes it 'limitless' while remaining very managable/workable. Wish we could somehow pin stuff! On 08/04/14 11:46, Matt Lind wrote: Nested models is where you went wrong. Don’t nest models inside of each other, especially if they’re referenced as it creates a situation where dependencies cannot be resolved should one of the nested items get updated. Softimage has decent infrastructure for managing dependencies between scene and referenced model, but not when the dependency is between two or more models. If you have many copies of the same model throughout your scene, consider using instances which eliminates the problem of duplicate material libraries and accelerates interactivity of your scene considerably. This will also reduce file size quite a bit as you only need one master model for the instances, not one referenced model per instance as you’re doing now. You can use standins as you mentioned. The difference between the two is instances will be of greatest benefit in the viewports whereas standins are of benefit at render time. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jon Hunt Sent: Sunday, August 03, 2014 1:34 AM To: softimage@listproc.autodesk.com Subject: Re: Scene crash on startup - any advice Thank you both Peter and Matt for your lengthy replies. I've found your replies informative and interesting. I am trying best possible to work to best practices and feel a little reassured! I am not doing much else other than laying out the models in the scene. I do have some geo in there (landscape) and some models I have made local. In summary the scene is a large camera move that flies through a village that is fairly dense with houses. I have built 3 variations of house with windows/doors/chimneys and so it is modular so I can avoid any repetition and build a custom house. This inevitably means I have reference models inside reference models. However through research I have not gone more than 2 levels deep with them and arranged the embedded ref models inside nulls for any SRT transforms. All models have master files that I have setup and refer back to when I make any changes. I think where I have gone wrong is if I want to make another variation of a house on the fly, I have taken a house model and made the top part of the hierarchy local and duplicated sub parts which are still referenced in. In doing this it has prompted me to share or copy material libraries. If I want another variation. I should build it in master file and bring it back in. I have done this 4/5 times in say 40 models, so I know where to fix it. Another workflow I could be using (should be using?) is stand ins. I did do a test render on Friday without using them and with a basic lightning setup up it munched it up. I am not overly concerned about the scene being to heavy now. I am unsure of this crossover
Re: Scene crash on startup - any advice
"while remaining very managable/workable" referring to enormously complex scenes full of stuff happenning at the same time. Maya can handle more objects and more polys (in terms of sheer count displayed at a time) but perhaps in addition to what has been mentioned here, there are also so many ways to treat islands and clusters as objects, and ICE deformations are multithreaded super fast, along with working with (and playing back.. or capturing near real time) fully SubD-ivided characters (live), technically making SI faster than Maya in many(if not most) real-world (complex) contexts, while also being the most memory effecient of them all literally by a factor of 2 I kid you not. And as far as I can tell, that easily accessible limitlessness is definitely one of the (essential) things missing to 'get there' in the 2 main runner-ups, very-much concerning both C4d hanging (despite -tons- of things to do and think about to make it better) AND Modo exploding (quite seemingly not getting better with time) (both of which also having incredibly nifty, efficient, and sometimes unique tools) But it's as if everything was made to make isolated setups, but SI and Maya. Except Maya is such a pain in the ass (in an ever increasing number of ways)... So bring your XSI sticker to siggraph! :) On 08/04/14 20:01, Jason S wrote: This Thread contains a great roundup of the (comparatively -extremely few-) things to keep in mind, allowing to (comparatively -extremely easily-) deal with (and effectively troubleshoot) virtually any project scope with SI, and is what makes it 'limitless' while remaining very managable/workable. Wish we could somehow pin stuff! On 08/04/14 11:46, Matt Lind wrote: Nested models is where you went wrong. Don’t nest models inside of each other, especially if they’re referenced as it creates a situation where dependencies cannot be resolved should one of the nested items get updated. Softimage has decent infrastructure for managing dependencies between scene and referenced model, but not when the dependency is between two or more models. If you have many copies of the same model throughout your scene, consider using instances which eliminates the problem of duplicate material libraries and accelerates interactivity of your scene considerably. This will also reduce file size quite a bit as you only need one master model for the instances, not one referenced model per instance as you’re doing now. You can use standins as you mentioned. The difference between the two is instances will be of greatest benefit in the viewports whereas standins are of benefit at render time. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jon Hunt Sent: Sunday, August 03, 2014 1:34 AM To: softimage@listproc.autodesk.com Subject: Re: Scene crash on startup - any advice Thank you both Peter and Matt for your lengthy replies. I've found your replies informative and interesting. I am trying best possible to work to best practices and feel a little reassured! I am not doing much else other than laying out the models in the scene. I do have some geo in there (landscape) and some models I have made local. In summary the scene is a large camera move that flies through a village that is fairly dense with houses. I have built 3 variation
Re: Scene crash on startup - any advice
Actually, it has been my experience that while Maya can definitely handle a larger number of individual objects, it starts to chug much earlier than Softimage with a lot of polygons Maya can handle more objects and more polys (in terms of sheer count displayed at a time) -- -=T=-
Re: Scene crash on startup - any advice
Thank you both Peter and Matt for your lengthy replies. I've found your replies informative and interesting. I am trying best possible to work to best practices and feel a little reassured! I am not doing much else other than laying out the models in the scene. I do have some geo in there (landscape) and some models I have made local. In summary the scene is a large camera move that flies through a village that is fairly dense with houses. I have built 3 variations of house with windows/doors/chimneys and so it is modular so I can avoid any repetition and build a custom house. This inevitably means I have reference models inside reference models. However through research I have not gone more than 2 levels deep with them and arranged the embedded ref models inside nulls for any SRT transforms. All models have master files that I have setup and refer back to when I make any changes. I think where I have gone wrong is if I want to make another variation of a house on the fly, I have taken a house model and made the top part of the hierarchy local and duplicated sub parts which are still referenced in. In doing this it has prompted me to share or copy material libraries. If I want another variation. I should build it in master file and bring it back in. I have done this 4/5 times in say 40 models, so I know where to fix it. Another workflow I could be using (should be using?) is stand ins. I did do a test render on Friday without using them and with a basic lightning setup up it munched it up. I am not overly concerned about the scene being to heavy now. I am unsure of this crossover as to when I should be using standins verses ref models. This is a separate conversation I am sure. I also have a deadline looming and need the darn shot rendered! Thanks, Jon On Sat, Aug 2, 2014 at 9:42 PM, Matt Lind speye...@hotmail.com wrote: A scene size of 53 MB containing mostly referenced models indicates there is still a lot of data, such as animation (FCurves) or data applied on top of the referenced models in model deltas, still in the scene. the first thing to try is rolling back your scene to a previous version (including referenced models) if you have been using source control. The done fixing hidden cluster error indicates a geometry problem. With a scene containing many referenced models, it's likely one or more models was imported into the scene as a referenced model, modified in some way that applied a dependency which needs geometry information, and the referenced model was later edited offline outside the scene. Next time the scene opens, Softimage is surprised because the referenced model is in a different state than the last time the scene was saved and has all this dependency data it doesn't know what to do with, so mayhem breaks out. For example, if you applied an object-to-cluster constraint, the constraint operator has a dependency on the cluster. If you delete the cluster from the referenced model outside the scene, the next time the scene opens and uses that model, Softimage will see the constraint operator and try to connect to a now non-existent cluster, then get confused. There are some topology operators which generate hidden clusters behind the curtains from user view which are used as a scratchpad for calculations. It's very possible the above scenario has occurred and the operator's cluster in question cannot reconnect to it's dependencies because one or more of it's inputs has disappeared from the model being changed outside the scene. One test is to open each referenced model locally in an empty scene. Check the script log before doing any work on each model, if you get the error message again, then you've found the problem. Freeze its modeling construction history using Freeze M, then export to update the .emdl. If you know of constraints or other operators, such as object-to-cluster, and have knowingly deleted the cluster, then try recreating the cluster to satisfy the scene next time it is opened. If all the models import successfully into empty scenes, then reopen the original scene and see if the error still occurs. If it does, then the problem is likely caused by data local to the scene and not in a referenced model. Data in model deltas is considered local to the scene, not the model. However, it's unlikely the problem is in model deltas if it's giving you 'hidden cluster' errors, but in the rare chance it is, check the 'removed items' section of the delta and cross reference it with the other categories for dangling entries. Every item appearing in the removed items list will have an associated entry in another category of the model delta. for example, if you import the referenced model, change it's position, then undo that action, there will be entries in the 'stored positions' category to record the position change, and an associated entry in the 'removed items' category to undo that position change (All the
Re: Scene crash on startup - any advice
Hi Peter, ha ha I'm happy to hear both workflows! each scenario is different seeings I explained more about the shot and that it needs rendering! Localizing everything has been on my mind! seeings that the models are locked versions. I have named all my materials (I did a pass of going through each master model file converting my shaders to arnold + tweaks and deleting unused materials through the external files tool) but do confess from one house model to the next I shall have duplicate materials that will be essentially connecting the same texture file. Particularly the wood texture that services all the wooden beams that are a feature of the houses. I have a lot of material libraries and am sure I could consolidate this to a global material library. I shall be kicking out multiple passes but more separating out objects with mattes rather than a set of channels to recomp. I am finding I am getting good results from Arnold and don't overly want to complicate things nor have the time. A decent compositior would tear my head off for saying this I'm sure! I have held up on the scene until later today. I felt it be productive that I light another scene (seeings I can open it!!) besides it made me feel better! I'm gonna check out the scntoc manager later but back at work/uni tomorrow so failing this I shall save a reference version of the scene then localize it all. Thanks again, Jon On Sun, Aug 3, 2014 at 11:17 AM, pete...@skynet.be wrote: Well, I’m going to suggest the exact opposite of before [image: Smile]. Why don’t you try and localize EVERYTHING to the scene (did you get to open it when offloading the models?) – make sure all geometry is frozen and delete all unneeded clusters. and do a good cleanup of the materials - assuming you have named you materials it’s just a matter of selecting all corresponding parts and assign them to the same material (one single wood material, one single metal material,... for the whole of the scene) Also remove unused materials and clips – and do it repeatedly – it never hurts to click those buttons too often. You can also merge all objects with the same material (eg all chimneys, all rivets,...) which can drastically reduce the amount of objects without resorting to clusters. If you just want to render a single beauty pass – you can merge complete houses - you’ll end up with clusters and cluster materials – which is no good for working with passes. It’s basically consolidating your scene, flattening it down, removing all dependencies. This makes it ‘uneditable’ – but since you are ready to render that’s fine. It’s actually not uncommon for film pipelines to include this as an automated step when sending off the scene to render. (saving it as a separate render only version – that only serves that purpose: getting your renders out.) *From:* Jon Hunt jonathan.m.h...@gmail.com *Sent:* Sunday, August 03, 2014 10:34 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Scene crash on startup - any advice Thank you both Peter and Matt for your lengthy replies. I've found your replies informative and interesting. I am trying best possible to work to best practices and feel a little reassured! I am not doing much else other than laying out the models in the scene. I do have some geo in there (landscape) and some models I have made local. In summary the scene is a large camera move that flies through a village that is fairly dense with houses. I have built 3 variations of house with windows/doors/chimneys and so it is modular so I can avoid any repetition and build a custom house. This inevitably means I have reference models inside reference models. However through research I have not gone more than 2 levels deep with them and arranged the embedded ref models inside nulls for any SRT transforms. All models have master files that I have setup and refer back to when I make any changes. I think where I have gone wrong is if I want to make another variation of a house on the fly, I have taken a house model and made the top part of the hierarchy local and duplicated sub parts which are still referenced in. In doing this it has prompted me to share or copy material libraries. If I want another variation. I should build it in master file and bring it back in. I have done this 4/5 times in say 40 models, so I know where to fix it. Another workflow I could be using (should be using?) is stand ins. I did do a test render on Friday without using them and with a basic lightning setup up it munched it up. I am not overly concerned about the scene being to heavy now. I am unsure of this crossover as to when I should be using standins verses ref models. This is a separate conversation I am sure. I also have a deadline looming and need the darn shot rendered! Thanks, Jon On Sat, Aug 2, 2014 at 9:42 PM, Matt Lind speye...@hotmail.com wrote: A scene size of 53 MB containing mostly referenced models
Re: Scene crash on startup - any advice
ha ha I'm happy to hear both workflows! each scenario is different seeings I explained more about the shot and that it needs rendering! think of it in photoshop terms: on one hand you work in layers, adjustment layers and groups – to be able to make modifications but at some point you flatten – all or part of it – to simplify, because you have to for certain things, for performance or to export the final version that’s used elsewhere – while keeping the layered version of course. Making one huge 3D scene where everything is interconnected, non-destructive, procedural, modifiable is great – especially while going through design changes – but at some point it can become counterproductive and consolidating things can be your way out. The balance between these two is not a simple black and white thing – no absolute rules. Sometimes you need a mixture of both, sometimes either extreme. And when you run into trouble on one end, it might be worth trying the opposite approach. I think it’s an important skill to acquire, to understand these strategies, to know when to simplify and consolidate and when not to – ideally before things start to fall apart . The photoshop analogy is far from perfect btw: flattening makes a file smaller and lighter. Localizing models is going to make the scene bigger I hope you get your shot/shots out – and can consider such things when things calm down. ... but do confess from one house model to the next I shall have duplicate materials that will be essentially connecting the same texture file. a few duplicate materials or a couple of libraries is far from a problem – if you kept an eye on things you’re fine. But I’ve run into scenes with thousands of unnamed materials, that are all just the same default phong. It’s always worth it to go over what you have done - the more you can clean up, the less bloat the software has to deal with. You’ll run into situations where this becomes the difference between being able to achieve what you’re after or not. About working in passes – again there’s no absolute rules. Sometimes you’re better off with passes and channels for absolutely everything, combining hundreds of passes in comp – sometimes a single pass and the odd mask or two. Afaik - the industry is moving a bit away again from multi-pass towards beauty rendering – in no small amount because of Arnold. But there’s still a lot to be said for being able to tweak in comp – and avoiding 3D re-renders. ... From: Jon Hunt Sent: Sunday, August 03, 2014 1:35 PM To: softimage@listproc.autodesk.com Subject: Re: Scene crash on startup - any advice Hi Peter, ha ha I'm happy to hear both workflows! each scenario is different seeings I explained more about the shot and that it needs rendering! Localizing everything has been on my mind! seeings that the models are locked versions. I have named all my materials (I did a pass of going through each master model file converting my shaders to arnold + tweaks and deleting unused materials through the external files tool) but do confess from one house model to the next I shall have duplicate materials that will be essentially connecting the same texture file. Particularly the wood texture that services all the wooden beams that are a feature of the houses. I have a lot of material libraries and am sure I could consolidate this to a global material library. I shall be kicking out multiple passes but more separating out objects with mattes rather than a set of channels to recomp. I am finding I am getting good results from Arnold and don't overly want to complicate things nor have the time. A decent compositior would tear my head off for saying this I'm sure! I have held up on the scene until later today. I felt it be productive that I light another scene (seeings I can open it!!) besides it made me feel better! I'm gonna check out the scntoc manager later but back at work/uni tomorrow so failing this I shall save a reference version of the scene then localize it all. Thanks again, Jon On Sun, Aug 3, 2014 at 11:17 AM, pete...@skynet.be wrote: Well, I’m going to suggest the exact opposite of before . Why don’t you try and localize EVERYTHING to the scene (did you get to open it when offloading the models?) – make sure all geometry is frozen and delete all unneeded clusters. and do a good cleanup of the materials - assuming you have named you materials it’s just a matter of selecting all corresponding parts and assign them to the same material (one single wood material, one single metal material,... for the whole of the scene) Also remove unused materials and clips – and do it repeatedly – it never hurts to click those buttons too often. You can also merge all objects with the same material (eg all chimneys, all rivets,...) which can drastically reduce the amount of objects without resorting to clusters. If you just want to render a single beauty pass – you can
Scene crash on startup - any advice
Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
Re: Scene crash on startup - any advice
try offloading all the ref models before loading the scene by editing the .scntoc file. Sent from my iPhone On 02-Aug-2014, at 7:51 pm, Jon Hunt jonathan.m.h...@gmail.com wrote: Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
Re: Scene crash on startup - any advice
Enable Skip the loading of floating objects in the scene debugging preferences. Or try merging the scene into a new scene. On Sat, Aug 2, 2014 at 10:21 AM, Jon Hunt jonathan.m.h...@gmail.com wrote: Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
Re: Scene crash on startup - any advice
Thanks for the quick replies guys. Alok, I havent edited .scntoc files before. Having a look, would I alter the active resolution of each model to 0 the resave over the .scntoc file? Stephen, I have tried merging scenes and skip loading of floating objects option on and both together. Its doesn't crash out as such it just hangs so I am unsure how long to leave it to quit it through task manager. Thanks, Jon On Sat, Aug 2, 2014 at 3:32 PM, Stephen Blair stephenrbl...@gmail.com wrote: Enable Skip the loading of floating objects in the scene debugging preferences. Or try merging the scene into a new scene. On Sat, Aug 2, 2014 at 10:21 AM, Jon Hunt jonathan.m.h...@gmail.com wrote: Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
Re: Scene crash on startup - any advice
you can download the scntoc manager that I wrote. It is available as a stand alone application as well as a soft addon. you can get it from rray.de otherwise yes you need to set the resolution to 0 manually. Sent from my iPhone On 02-Aug-2014, at 8:23 pm, Jon Hunt jonathan.m.h...@gmail.com wrote: Thanks for the quick replies guys. Alok, I havent edited .scntoc files before. Having a look, would I alter the active resolution of each model to 0 the resave over the .scntoc file? Stephen, I have tried merging scenes and skip loading of floating objects option on and both together. Its doesn't crash out as such it just hangs so I am unsure how long to leave it to quit it through task manager. Thanks, Jon On Sat, Aug 2, 2014 at 3:32 PM, Stephen Blair stephenrbl...@gmail.com wrote: Enable Skip the loading of floating objects in the scene debugging preferences. Or try merging the scene into a new scene. On Sat, Aug 2, 2014 at 10:21 AM, Jon Hunt jonathan.m.h...@gmail.com wrote: Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
RE: Scene crash on startup - any advice
A scene size of 53 MB containing mostly referenced models indicates there is still a lot of data, such as animation (FCurves) or data applied on top of the referenced models in model deltas, still in the scene. the first thing to try is rolling back your scene to a previous version (including referenced models) if you have been using source control. The done fixing hidden cluster error indicates a geometry problem. With a scene containing many referenced models, it's likely one or more models was imported into the scene as a referenced model, modified in some way that applied a dependency which needs geometry information, and the referenced model was later edited offline outside the scene. Next time the scene opens, Softimage is surprised because the referenced model is in a different state than the last time the scene was saved and has all this dependency data it doesn't know what to do with, so mayhem breaks out. For example, if you applied an object-to-cluster constraint, the constraint operator has a dependency on the cluster. If you delete the cluster from the referenced model outside the scene, the next time the scene opens and uses that model, Softimage will see the constraint operator and try to connect to a now non-existent cluster, then get confused. There are some topology operators which generate hidden clusters behind the curtains from user view which are used as a scratchpad for calculations. It's very possible the above scenario has occurred and the operator's cluster in question cannot reconnect to it's dependencies because one or more of it's inputs has disappeared from the model being changed outside the scene. One test is to open each referenced model locally in an empty scene. Check the script log before doing any work on each model, if you get the error message again, then you've found the problem. Freeze its modeling construction history using Freeze M, then export to update the .emdl. If you know of constraints or other operators, such as object-to-cluster, and have knowingly deleted the cluster, then try recreating the cluster to satisfy the scene next time it is opened. If all the models import successfully into empty scenes, then reopen the original scene and see if the error still occurs. If it does, then the problem is likely caused by data local to the scene and not in a referenced model. Data in model deltas is considered local to the scene, not the model. However, it's unlikely the problem is in model deltas if it's giving you 'hidden cluster' errors, but in the rare chance it is, check the 'removed items' section of the delta and cross reference it with the other categories for dangling entries. Every item appearing in the removed items list will have an associated entry in another category of the model delta. for example, if you import the referenced model, change it's position, then undo that action, there will be entries in the 'stored positions' category to record the position change, and an associated entry in the 'removed items' category to undo that position change (All the entries in the deltas are evaluated, and the removed items list acts to cancel out anything that appears in the previous lists). If you cannot find a pair for each entry, then something's wrong. In which case, flush the item from the removed items list by selecting and deleting it. I recommend this over deleting the entire delta as some tend to do, because deleting a model delta is often unnecessary and only loses all your work. In most cases the problem isn't too hard to find as long as you pay attention to what you're looking for. Matt Hi List, Asked a thousand times before I'm sure. I have researched and having no Joy and could really do with some suggestions please. Soft 2014 SP2 - Scene opens at Uni on an identically specced HP workstation machine. I noticed my home machine (when the file did work) took about 20mins to load whereas at Uni it was around 5 minutes. Scene size 53mb Scene contains mostly reference models. Following the help topics I turned on scene debuggingLoad recovery journal file. I have have pointed it to an existing text file but it hasn't written anything to that. I do have a .lrf file but I am unsure what to do with this? I restart xsi and I get prompted 5 or so time about having a ghost model. It continues to load but then hangs without crashing after sticking on done fixing hidden cluster Any input would be muchly appreciated Jon
