Have you tried instantiating new Image nodes rather than editing the paths? Or rebuilding the shaders from scratch (yuck)? You could also try your path fix, then while it's still working, save the entire shader out as a RTcompound (NOT a preset), then delete the old material shader completely, and load the compound. (Compounds, IIR, are just xml descriptions of the nodes and their connections, so instantiate fresh nodes on loading.)
Sounds like it could be some corruption in the shader node. By any chance was the model saved out of an early release of SI 2012? That's when we had that nasty bug with the disappearing shader connections. On Wed, Nov 20, 2013 at 5:21 PM, Ponthieux, Joseph G. (LARC-E1A)[LITES] < [email protected]> wrote: > It's a new scene. But some of the objects are older Model exports that > have been imported. > > So for the resolved paths that's the weird thing. When I brought the > models in they were pointing to a defunct path. I edited the paths and they > pointed to the new location just fine. Rendered with the texture just fine. > But then after a while they get disconnected(go red). > > They still point to the new location, I can access the location and the > file just fine through Windows explorer, but when I click on Refresh in > External Files Manager they stay red as though they are defunct and report > a status of invalid. I can select one of the files and "Browse Selected > Path" the directory will open and I can see the file. If I double-click the > file it will update and make the file valid again(grey). But if I wait a > while or look at it again tomorrow, it will go invalid again at some point. > > I see this problem frequently. I think I may have even commented about it > on this list before. Would be nice if I can figure out what is causing it. > > -- > Joey Ponthieux > LaRC Information Technology Enhanced Services (LITES) > Mymic Technical Services > NASA Langley Research Center > __________________________________________________ > Opinions stated here-in are strictly those of the author and do not > represent the opinions of NASA or any other party. > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Luc-Eric Rousseau > Sent: Wednesday, November 20, 2013 3:15 PM > To: [email protected] > Subject: Re: I'll be back... > > Softimage remembers the last place it resolved a file name, and tries that > place when you load the scene. > it's a cache, you cannot find it in the external file list. > if all the images resolve to a new path and you save the scene, you should > be good. It's probable that if some images don't resolve it continues to > try that cached location. So fix all those path that do not resolve in the > External File List > > On Wed, Nov 20, 2013 at 3:05 PM, Ponthieux, Joseph G. > (LARC-E1A)[LITES] <[email protected]> wrote: > > While troubleshooting erros in a scene I stumbled across this error in > > the script editor: > > > > > > > > # INFO : 4000 - Server '\\SERVER_NAME' is unreachable. Marked as > > invalid for the next 300 seconds > > > > > > > > "SERVER_NAME" has been out of service for years. Its not even plugged > > in anymore. I'm currently using a scene that contains some older > > geometry that was built during a time when SERVER_NAME was in service. > > Now the scene is apparently looking for the server. > > > > > > > > > > > > I've searched for SERVER_NAME in every project in the current database > > of Project Manager. Nothing found there. > > > > > > > > I've searched for it in the External Files Manager. Nothing found there. > > > > > > > > I've searched for it in the Render Manager. Nothing found there. > > > > > > > > I've search for it in Explorer/Sources/Images and queried each image. > > Nothing found there. > > > > > > > > > > > > I've been unable to find it anywhere I thought to be a relevant place > > to look. Any ideas on what I might be overlooking? > > > > > > > > -- > > > > Joey Ponthieux > > > > LaRC Information Technology Enhanced Services (LITES) > > > > Mymic Technical Services > > > > NASA Langley Research Center > > > > __________________________________________________ > > > > Opinions stated here-in are strictly those of the author and do not > > > > represent the opinions of NASA or any other party. > > > > > > >
