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, <[email protected]> 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 <[email protected]> > *Sent:* Sunday, August 03, 2014 10:34 AM > *To:* [email protected] > *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 <[email protected]> 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 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 debugging>Load 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 >> > >
