Matt, I have to ask. What could you possibly have from the Softimage 3D days that you'd want to recover? No cynicism, just genuinely curious. :)
Even things that I created and thought were amazing back then, I could (and would) re-make in days and to a far higher standard with modern tools. It's like playing old computer games that you loved from the past. They're invariably shit. :) ...OK, except maybe Command and Conquer: Red Alert... I'll always have time for that (anyone who feels the same should head over to http://www.openra.net btw... ;) DAN On Tue, Dec 23, 2014 at 1:43 PM, Matt Lind <[email protected]> wrote: > Virtual PCs work for now, and so does keeping archives of files around for > the interim. One problem you may run into is expiration date of your > licenses. I ran into this problem with my older XSI licenses. While > Softimage called them 'permanent' licenses, they're actually 10-13 year > time bombs. They're called permanent because Softimage assumed nobody > would need to exhume data that far into the future as a newer release of > the software would be available for that purpose. That's great until there > are no more new releases. > > In due time everybody will hit the same problem - what to do when you can > no longer maintain the ecosystem? That's where I'm at now and why I'm > writing an exporter. In my particular case commercial formats such as > .fbx. .obj, .xsi won't suffice because they don't support the necessary > features. I have scenes which are facades with a shader applied to make > the illusion of 3d on a 2d surface. .fbx doesn't support shaders, so > converting those scenes will get the polygons to convert, but not the > shaders - what good is that? Even if the shaders were rewritten for the > target application, .fbx does not contain the necessary information to make > the connection. Many formats are designed for editing, not archiving. > They're also proprietary in nature making it a risky medium to store data > long term. Anybody have the specs to the .fbx file format? thought so. > File formats have shelf lives too. I think it's best to keep data in it's > original format until you have a specific destination. Each time you > migrate data it loses some of it's integrity. > > I'm not going to support my content indefinitely, but I am going to design > a format which can properly archive it with enough information to > reconstruct it in another application if a feature isn't directly > supported/available. I can do that with Softimage|3D content because it's > doesn't support complex data such a render passes, ICE trees, render trees, > and so on. XSI is another beast and will be much more difficult to support > in that regard. > > > Matt > > > > > --------------------- > Date: Tue, 23 Dec 2014 11:57:20 +0100 > From: Tim Leydecker <[email protected]> > Subject: Re: How do you guys make sure XSI files and Softimage 7.5+ files > will open in 2016? > To: [email protected] > > Just to be clear, I don?t want to portray Adsk as evil, I am bitching > about the > extra hurdles involved in finding the service packs to a specific release?s > version and making sure all files neccessary are downloaded and named > properly. > > In my personal case, I can pretty savely assume Softimage 2010, 2012, > 2014 version jumps, > so that?s not so bad actually. It?s a bit more difficult for 3rd party > renderer versions and > the 32bit>64bit jump for plugins like the sRGB nodes from Harry Bardak > in some legacy > projects. Anything 64bit I am also positive will most likely be fine, > like Sven suggests > (one also learns a bit about project structuring, my old stuff has more > final_v003.var2 files than now...) > > In terms of general backup strategy, I also got bitten once, losing a > drive when swapping > machines and then having to rebuild that data from iterative backups on > other drives. > Not nice, tedious actually. I can recommend "Beyond Compare", that > worked great for me > in putting together a working version of a project and even completely > restructuring my > files into project specific folder structures, weeding out duplicates > and reducing the chance > of missing files by collecting things into one master folder branched > into apps, files, etc. > > I do have to check if my dongle is still working, thought. A virtual > machine is a very good tip. > There?s a change I have a full backup of a working system drive > available. I used "Drive Snapshot" > in the past but haven?t touched those backup files in years. To be > honest, there?s not too much > stuff I would be proud in showing off, maybe some snippets from my > thesis would be worth > being polished and put on display, after more than 10 years... but I > doubt it... > > For the last couple of years, I will mostly have *.obj and *.fbx files > plus *.psd map files > as well as *.ztl and *.mud files, that stuff is pretty save to open with > newer versions atm. > > Thanks for your thoughts, > > it?s a bit spooky to realize 10 years ago now also looks like 10 years > > ago... > > > Cheers, > > tim > > > Am 23.12.2014 um 10:36 schrieb Rob Wuijster: > >> Just to add some thoughts on this... >> >> I started building virtual pc's for this 'occasion' some years ago, >> just to be on the safe side. >> >> I still have a Win95/98/NT/2000/XP virtual disk lying around with some >> 'critial' software installed, just to be able to open up that one >> program from years ago. >> Or to run some other stuff that's impossible in the newer version of >> Windows now. >> >> At some point I had to convert my virtual pc 'disks' to a new virtual >> pc program, but that was less hassle than doing all Matt described. ;-) >> >> I think we're all in the same situation at the moment. I also have a >> boat load of assets, created over the years going back to Softimage 3.0. >> All neatly packaged in a separate project as scenes or models. All >> shaded and textured, ready to go. The more 'beefy' assets are now >> models linked to a Arnold .ass file for quick handling and rendering. >> >> At some point we sadly have to leave Softimage behind, so what to do >> with all these assets? Depending on what's next, there's probably a >> slow conversion to this new 3D application. Or conversion to .obj or >> .fbx for longer, more app agnostic storage. >> >> For me, having the virtuals pc's/software lying around is the easiest >> solution at the moment. How this all will play out in the next years >> is another story ;-) >> cheers, and happy holidays to all! >> >> Rob >> >> \/-------------\/----------------\/ >> > >
