Good question. You'd think a 'permanent' (or 'perpetual') license as it was termed would be permanent and perpetually available. That should be challenged.
As for revisiting old projects - let me share my experience doing the same with Softimage|3D: I started my career as a 3D character animator, but transitioned to the technical side when XSI made it's debut years later. Back in the day (~2002) I ported all my SI3D work to XSI, but many years later while upgrading my computer and transferring data (~2012), a mishap occurred causing the ported data to be lost. By this time XSI no longer had the SI3D scene importer, so redoing the port would involve re-installing an older version of XSI (v7.5 or earlier). Most of my content was for cartoon projects in real time games, but with a novel NURBS engine. That meant lots of use of Cardinal/BSpline patches and NURBS surfaces for modeling, QuickStretch for animation, MetaClay for organic modeling and cartoon FX, and heavy use of nulls and IK chains with envelopes, and of course, constraints and expressions. Rendering made heavy use of toon ink and toon paint shaders, but ordinary phong/blinn/lambert/constant otherwise. From past experience, I knew firsthand how those tools lacked support of many features I used in SI3D and often produced horrifically mangled results. I determined I could do a better job writing my own exporter/importer, and possibly do it faster than redoing the port by hand. Upon installing SI3D I got the cold splash of ice water on my face. The application ran just fine, but as soon as you click a menu or something that required polling the license, it would dump to desktop because FlexLM was coded for Windows XP / 2000. I think the longest session I got was 15 minutes. I found an old installer for Windows XP and was able to resuscitate everything, but bugs and more crashing persisted until I also installed XP Service Pack 3. While everything ran normally, it quickly reminded how far things have evolved since. Softimage|3D is a single threaded application complying with the OpenGL 1.x specification (maybe OpenGL 2.x), mental ray was only licensed for two processors (or logical cores). I had to install on an older computer to ensure the limit wouldn't be reached as there was no way to do it in the GUI. If the limit was reached, renders aborted (command line renders were no problem as there's a flag you can specify for max thread count). Furthermore, my old computer was prone to interference from my WiFi router. Therefore, I had to turn off my internet service during renders or else suffer scrambled pixels in images. On the plus side, modern day Nvidia graphics card drivers fixed all the old bugs that used to cause SI3D to dump to desktop. So the graphics were relatively smooth even if feature challenged. FYI - I did try installing SI3D in a virtual machine, but couldn't get the virtual machine to acknowledge the dongle for licensing. The next splash of water was trying to install the SI3D SDK. For those that don't remember, SI3D had two SDKs: DKit and SAAphire. DKit was the original SDK and only provided very high level access to the API much like Apple products don't give anything of substance to the end user (i.e. useless). SAAphire was introduced in 1995 and was intended to replace DKit as well as act as a bridge to transition to XSI, but when project 'Sumatra' started experiencing problems, developers got reassigned to Sumatra putting SAAphire on the back burner, and was left largely incomplete. Next harsh reality was learning the SDK had to be matched to the version of SI3D in use. Not just major release, but minor release too! I had Softimage|3D 3.9.2.2 but the SDK was for 3.9.2. That tiny difference was enough to cause the SDK plugins I compiled to not operate. Fortunately I found the installer for SI3D 3.9.2 and was able to make a match (next option would've been SI3D 3.8.1 ....shudder). Once SAAphire was installed I discovered I also had to write all the code with MS Visual C++ v6.0 because newer compilers didn't have backwards compatibility settings. Ugh. I surfed the web for a few weeks before I found a copy of MSVC++ 6 on Amazon for $130. Had to be a "professional" edition as the regular edition didn't have all the right libraries. After MSVC++ 6 was installed and I attempted to 'build' a plugin, I then learned that SAAphire plugins cannot be 'built' from the GUI. You have to use a makefile, which in itself is not a big deal, but using a makefile meant that the IDE functions such as code search, autocomplete, function/class lookups, syntax highlighting, and other features programmers rely on were no longer available for use. Basically, the IDE was reduced to a glorified copy of Microsoft Notepad. Now the fun part - writing the exporter code. Writing an equivalent exporter in XSI is trivial and can be done with scripting, but it's a wrist-cutting experiment at best in SAAphire as you must write your code in C, not C++ (no scripting). SAAphire didn't support really basic things either - like getting the name of the scene camera (head scratcher considering SI3D only supported one camera in the scene). You could get the name of the camera interest, but not the camera. Objects did not have 'class' or 'type' associated with them like they do in XSI. Instead, they had a combination of IDs (integers) which had to be cross referenced with each other to figure out what it was. For example, the 'ID' was 0, but the 'algorithm' was a 3, then the object is an ordinary null. If the ID was 0 and algorithm was also 0, then the object was used in dynamic simulations and had special attributes which had to be looked up independently. You had to cross reference with another id lookup to find out how the object was used in simulations (nail, fain, wind, gravity, ...). Another hair-puller was how envelope data was stored. In XSI, you get a handle to the envelope operator on the deformed geometry (envelope), then request the envelope weights which are returned to the caller as a 2D array of floating point values arranged in ascending order by vertex index and deformer index. In SAAphire, there are 5 different types of envelopes, each has their own process, and the procedure to get the data is opposite of how it's done in XSI. You have to get a handle to the envelope deformer (bone), then query which envelope(s) it deforms. Then you go to each deformed envelope to get the weights for that deformer, and must compile and organize that giant 2D array yourself. Let me mention the list of deformer weights is sparse - as in, only non-zero weight values are recorded (to save memory), you must determine which vertices were left out and fill in the blanks yourself, and nothing is numbered or alphabetized to tell you which way the data should be structured. It is assumed the order presented is the order you should preserve in your own data structures - but that doesn't always hold true. Furthermore, there are no direct links (pointers) to get a handle on an object returned by these queries. Instead, you must manually traverse up/down the scene graph until you find the object that matches the description of the object returned in the query. Very painful process....but not as bad as discovering the scene reader/loader function does not have the ability to read anything but the most current version of a scene in a database folder. If there are 7 versions of the scene and you want to load version 5, SAAphire would always load version 7, but tell you it loaded version 5. Nice! I found this feature especially handy (sarcasm). Again, for those who do not remember, unlike XSI which stores the entire scene in one file (.scn) sans referenced models, the SI3D file format was not a single file. It was multiple files linked by 'relations'. There was a central ASCII text file which described which objects (elements) comprised the scene and how they were related to each other (relations), but the actual element data was recorded in separate binary files (one per element) and stored in specific folders (chapters) within the project (database). If your scene had 1,000 objects, then upon saving the scene there would be the main scene description file (.dsc) plus 1,000 model files (.hrc) in the database. If you saved a 2nd version of the scene, SI3D had to first check each of the 1,000 files to see if they already exist, then rename the newly saved files to v2 so they don't collide with v1 when saving (Yes, it took forever to read/write that data. Data corruption was a common problem). If the current version saved exceeded the maximum number of revisions allowed in user preferences, then the earliest versions of the files had to be located and deleted. If you needed to access scene information about an element other than name, parent/child, or other trivial information, SAAphire would pull that information from the file on disc in the database, but would only read the most recent version of that element, not the version matching the scene currently loaded. So despite file versioning being a core feature of the application from day one, SAAphire didn't support it. There were many other unsupported features such as Quickstretch. You can access the icon in the 3D views which controls the effect, but it does not provide access to the Quickstretch parameter values. There are no SAAphire functions to access the parameter values. After much hunting and pecking, I found I could hack the scene's .dsc (ASCII text - similar to XSI's .scntoc) to get the parameter values - but then it gets even better. The values recorded in the .dsc are not the values you see in the GUI. They are instead encoded through a cipher so they are assured to take only 'n' characters of space in the .dsc file. Therefore, you must decode the cipher in order to extract the parameter values of the Quickstretch operator from the .dsc. Which I did....painstakingly. Anyway, many more of these follies. Eventually I worked around almost all of them to produce an exporter that successfully exports an SI3D scene so it can be imported into another application. I chose XSI with the assumption that the common features would align 1:1 making import all the easier. Wrong! Even the common features, while common, did not operate the same way in XSI. Quickstretch exists in both applications, but the XSI version is a lobotomized version of the SI3D version, and does not share any parameters. So all that work to extract the ciphered parameter values was for naught. Ugh. Likewise, while the SI3D mental ray shaders were ported to XSI by Softimage, they do not produce the same results! In many cases, shaders would require an object list to isolate which objects are affected by the shader, but the ported SI3D shaders were disabled from using object lists....why? Ugh. Anyway, lots more stuff along these lines. All in all, it took about 2 months to get familiar enough with SAAphire to write the exporter, and another 3 weeks to actually write it. On the XSI side it was much faster. It took about 2 weeks to get the importer up and running to load full scenes, and another few weeks to discover all the bugs and employ the workarounds for the edge cases. Total time = about 4.5 months. That sounds like a lot, but it's still faster than the time spent in 2002 porting the data the first time using the importer provided by Softimage which produced horrifically mangled results. So on that front, my prediction was correct. Some problems were not able to be worked around. For example - geometry. Most of my content was built in patches (BSpline/Cardinal/Linear) and/or MetaClay (metaballs). XSI supports NURBS and polygons, not patches or metaballs. In many cases I was able to convert the patches to polygon mesh with Catmull-Clark subdivision smoothing to produce an identical looking result, but that also had the ripple effect of forcing me to port all the tools to XSI to maintain that conversion. for example, the deformation by surface operator (aka patch deformation) works by mapping vertices of the deformed object to the UV parametric space of the deforming surface. Well, when the underlying deforming surface is converted to polygons, the UV parameter space no longer exists. So the deformer had to be rewritten to function on polygon mesh geometry (at greatly reduced peformance). The best I could do with metaClay was to import the metaballs as nulls with a custom property preserving the parameter values as experessed in SI3D. Maybe a shader would be written to render the metaClay....if I get the muster to take on such a project. Another example is FCurve interpolation. SI3D's Function curve editor used Hermite curves while XSI's Function curve editor uses NURBS curves with Cubic interpolation. The difference is how motion eases in/out between keys and the difference is very noticeable. The only workaround was to plot one key per frame in SI3D. Another problem was how shapes and clusters were interpolated for the simliar reasons, but plotting shapes isn't as fruitful as plotting transformations. The point of my long-winded story here is to illustrate that my case was relatively trivial in terms of content and support requirements, but even with that low bar it proved to be very challenging to move data to a modern platform where it could be archived and preserved. When all was said and done, I was able to preserve about 85% of my work 'as it was', and the other 15% required various degrees of elbow grease to get back into form. Some of that 15% could not be reproduced exactly and is therefore lost to father time. Given today's content creation environments are much more complex that what I dealt with above, you can only imagine how much more difficult porting can be. Focus of USD, Alembic, and other common exchange formats is on preserving certain fundamental features like geometry and transformations, but at the expense of specialty features such as shaders or plugins. While that fundamental list is growing, it will always be a subset of the features you use in a specific DCC application. So you have to decide how important it is to preserve your work and in what form. For example, do you need to access the source files in the future, or are you content with the final result? If you want access to source data from a retired application, then my suggestion is to keep all the installers, license keys, service packs, documentation, and so forth. Make sure you have a computer **of same vintage** as the application, preferably offline, where it can live in isolation of evolution so it won't be inadvertently invalidated from a software upgrade or other external issue. Optionally, you could try a virtual machine, but the caveat is you might not be able to access the licensing in hardware if it uses an older technology (That's what bit me in attempts to get SI3D in a virtual machine as the dongle uses a parallel port and modern computers don't have them. I tried a parallel to serial port adapter, which works on a physical machine, but not a virtual machine). Then, of course, keep all your content in a safe place so it can be accessed when needed. Finally, document all the quirks that need to be known about anything that can be a problem in accessing the content. For example, does a particular scene require special handshake to render correctly? If so, what is that handshake? Document it, and make sure you've taken care of any dependencies associated with it. I think XSI will continue to function for a long time, but the most likely problems will be the licensing. Another potential issue is OpenGL support. SI3D still runs on modern graphics cards because they still support OpenGL 1.x and OpenGL 2.x. That might not continue for much longer as manufacturers look for ways to thin the OpenGL support requirements to get driver sizes smaller and more manageable. XSI in particular is heavily coupled with Microsoft's COM/OLE. While I don't think it'll stop working tomorrow, the writing is on the wall. Netview is already disabled in many ways from internet security protocols implemented to inhibit Internet Explorer's ActiveX scripting environment. With Windows 7 support expiring this week - you may want to download any support needed on that front as newer / current versions of Windows might not allow such features to run even if offline. In short, create an environment that is a snapshot of the application's best working form, then preserve it. Matt Date: Mon, 13 Jan 2020 12:17:40 +0100 From: ron...@toonafish.nl Subject: Re: Softimage mailing list: 2019 by the numbers To: "Official Softimage Users Mailing List. I stlll use Softimage every day. I?m slowly trying to switch to Houdini ( for the thrird time ) but it?s not much fun when you know there's a Ferrari in the driveway, but have to use the bycicle to get from A to B :-) Maybe for complex Special FX Houdinin is great, but for modeling and character stuff I keep on running into strangely convoluted workflows or basic stuff that?s just not possible or takes so much time to create a procedural workaround for you forgot what you wanted to do in the first place by the time you?re done. Besides that I still have to work on some old projects in Soft every now and then. Btw, how will we be able to revisit old Softimage projects when Autodesk stops activating old licenses next year and you have to install it on a new computer ? I just did a fresh install on a new workstation so I hope I?m covered for a few years. But what if I need to reinstall it in a few years on a new workstation ? Ronald van Vemden Toonafish | Owner and Creative ----------------------------------------------- 3D Graphics & Animation Toonafish Cyberfish Laboratories tel. +31(0)6 46715175 email: ron...@toonafish.nl On 11 Jan 2020, at 01:39, Matt Lind <speye...@hotmail.com> wrote: Most telling statistic is that Stephen Blair is the top poster of the year, and he typically only posts the Friday Flashback thread. I almost tried to avoid the list this year and I still ended up in the top ten. Once support left the product, so did the users. I'm curious to know how many people are still actively using XSI. I don't mean tinker with it, but actually using it regularly for meaningful work. Matt Date: Thu, 9 Jan 2020 02:33:28 +0000 From: Matt Morris <matt...@gmail.com> Subject: Re: Softimage mailing list: 2019 by the numbers To: "Official Softimage Users Mailing List. Feeling a little maudlin at those figures. Had a quick look back at list activity: 2011 ? 2013: holding pretty steady at around 12k posts a year. 2014: 14k posts (eol announcement) 2015: 4055 (crazy drop off) 2016: 3282 2017: 2311 2018: 1058 2019: 657 ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with “unsubscribe” in the subject, and reply to confirm. -------------- next part -------------- An HTML attachment was scrubbed… URL: https://u9432639.ct.sendgrid.net/wf/click?upn=msg1YMqKv6PblZ6nn0inv01qYUEyUw3vT4pz1mW-2BzrMacQxEaFtH0MCboytOBZxKwf8uiWIxxK63b-2FJamAZeLaqkb0E-2BR96OL7OqHRatlOxX-2F0uiTwPEvu3iR-2Fh6XyCga1W2ykJ4WyKa-2BPnFNexVgMgsQ4wz8mH1Ad3R-2BAt3Cdg-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18hojRNJeeUrnwRuO9PCes7aLvDl94c8XIzjh5rMOF-2FWY8NJD5MdQuO-2FiOzKYQev5zL9OR1ZPS-2BzIXXY3o4-2BHC6aEKH9fU6yuw0O4vXBES067ztSApi9yrB8-2BPNTBj-2FVC6QUdNvFCE41Mi1yJboid9IG-2BpehAbbKFo16uA1HzRpZP4 ------------------------------ Message: 3 Date: Mon, 13 Jan 2020 11:19:14 +0000 From: Jordi Bares <jordiba...@gmail.com> Subject: Re: Softimage mailing list: 2019 by the numbers To: "Official Softimage Users Mailing List. https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchiLG9o7ECJDJ0Mw-2FRzSlfldhFWvv2G7M9xrogMv-2BiUgrG-2BmCVAfC2HxBWG0Czpbw8UUe9Xkbh68Twjp-2FiA-2FSErMU-2FEk2CkvoTC04KpO5Ly475MLQNUViwPoaAMpEaEjwAYOu4T567ozlZeZdMMtM3KXVN7uiAm1z1BQ0qjBHp2w-2F-2FQwXlBtX2tzzsgIZeJUn-2BNDHd-2F8uwGE5ZF2Eq-2FY2ZqBmx5k55MzKISsJnDJeY3fayRu-2F5H0jmMAIIKfbzOpvL5VCKROaG-2F-2Bcu-2B1I50MUh3xMLetQ5jkU-2BabpORZzaMoWfOddNTvcQ3nF0mzSaLAJhfz8vrzGLSSqf8J3FdFB-2Big-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18hpATqtY8-2FBzsXfQtKKELQ5VbRSC4RoKwqrdTeK8Kq6jxZIWyKWYl5tuImxLzqujCjUtIUXFyOxjnRe-2FApEeuiYuEz5FzLULSOeAdjiaf984oeV0g2R7gq9Dg5WRfXgPWQwTeVjQxBTRW7eBpNIL6WVJOq-2Bizj05yvTo3Ang7-2B8bW " <softimage@listproc.autodesk.com> Message-ID: <2643c0c0-68b1-4c9a-ae1c-dea3109e3...@gmail.com> Content-Type: text/plain; charset="utf-8" It is hard go move away from XSI if you still can go back?the same with languages, only full immersion works and the results are normally astonishing in the sense that you will feel confident much sooner than you think. But I do certainly understand the need for being productive and it is not an easy task with any package. My suggestion would be do one small job with it, no effects, just something easy, materials/render kind of thing? hire a Houdini artist to help you out on the transition and execution of the job and you will be moving on the right track. Regarding your question, I am also interested, it has been more than 8 years since the announcement so it is quite telling there are still artists using it. XSI was so freaking good! jb On 13 Jan 2020, at 10:44, balazs kiss <fospu...@gmail.com> wrote: I do, every day, and I think 2 or 3 more guys in our office as well. Others are on maya or houdini, moving slowly towards houdini, but it is a slow process, and it is hard to learn it. There are things I'd rather do in houdini, but xsi/ice still feels a lot more intuitive.. On 1/11/20, Matt Lind <speye...@hotmail.com> wrote: Most telling statistic is that Stephen Blair is the top poster of the year, and he typically only posts the Friday Flashback thread. I almost tried to avoid the list this year and I still ended up in the top ten. Once support left the product, so did the users. I'm curious to know how many people are still actively using XSI. I don't mean tinker with it, but actually using it regularly for meaningful work. Matt ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with ?unsubscribe? in the subject, and reply to confirm. -------------- next part -------------- An HTML attachment was scrubbed… URL: https://u9432639.ct.sendgrid.net/wf/click?upn=msg1YMqKv6PblZ6nn0inv01qYUEyUw3vT4pz1mW-2BzrMacQxEaFtH0MCboytOBZxKwf8uiWIxxK63b-2FJamAZeLaqkb0E-2BR96OL7OqHRatlOwq9gAMGwg68AN4J9gpQYNF-2BDCY2VjPT4UCo6KsUPuuvhoKDP-2FRDfHqb6FnxUShftY-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18ho3PCvj4n-2FVXDxn67Ijv-2BZIMFuejGViFlkpjI0b6GPCPN4OaNnM33kk6yh7olHIQtd1gB9XebbhFAM0YW1vceCgQudCqfhnBfslTXu8Uj3Gh-2BS3vQ6vtYmJMp1VpclFF8i-2Fv8mIlIqGNorYAuyOjJjNp9fT-2FvxvECc2VClsmxwTH ------------------------------ Message: 4 Date: Mon, 13 Jan 2020 12:52:28 +0100 From: michael johansson <mich...@lowend.se> Subject: Re: Softimage mailing list: 2019 by the numbers To: "Official Softimage Users Mailing List. https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchiLG9o7ECJDJ0Mw-2FRzSlfldhFWvv2G7M9xrogMv-2BiUgrG-2BmCVAfC2HxBWG0Czpbw8UUe9Xkbh68Twjp-2FiA-2FSErMU-2FEk2CkvoTC04KpO5Ly475MLQNUViwPoaAMpEaEjwAYOu4T567ozlZeZdMMtM3KXVN7uiAm1z1BQ0qjBHp2w-2F-2FQwXlBtX2tzzsgIZeJUn-2BNDHd-2F8uwGE5ZF2Eq-2FY2ZqBmx5k55MzKISsJnDJeY3fayRu-2F5H0jmMAIIKfbzOpvL5VCKROaG-2F-2Bcu-2B1I50MUh3xMLetQ5jkU-2BabpORZzaMoWfOddNTvcQ3nF0mzSaLAJhfz8vrzGLSSqf8J3FdFB-2Big-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18hkCtLxzYIH-2FchFTIE5p9e0IBgS4giwi8KOaZNA-2F3Gg5ND7BgCAQQnkM2u5BPz2k-2FWhiUlVSFKp9Z8tlJBRj7AH5UhuQFZmMWkWV02DKtutgobfYXNEB1wnzB6ggvT5FFlEbVs32v06TBoGKjv9kqTMsvdo9YSghrkRwDVMvCPhB3 " <softimage@listproc.autodesk.com> Message-ID: <cada-txy37ymkkky7x-qjkuhoqdyvfyzp4tb7s+yasy_prqh...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I still since 1994 use softimage more or less everyday. Mostly for conceptual visualizations and prototypes and finding it hard to get up to speed with modelling in any other application, so i will continue with Softimage as long as I can. Den m?n 13 jan. 2020 kl 11:44 skrev balazs kiss <fospu...@gmail.com>: I do, every day, and I think 2 or 3 more guys in our office as well. Others are on maya or houdini, moving slowly towards houdini, but it is a slow process, and it is hard to learn it. There are things I'd rather do in houdini, but xsi/ice still feels a lot more intuitive.. On 1/11/20, Matt Lind <speye...@hotmail.com> wrote: Most telling statistic is that Stephen Blair is the top poster of the year, and he typically only posts the Friday Flashback thread. I almost tried to avoid the list this year and I still ended up in the top ten. Once support left the product, so did the users. I'm curious to know how many people are still actively using XSI. I don't mean tinker with it, but actually using it regularly for meaningful work. Matt ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with ?unsubscribe? in the subject, and reply to confirm. -------------- next part -------------- An HTML attachment was scrubbed… URL: https://u9432639.ct.sendgrid.net/wf/click?upn=msg1YMqKv6PblZ6nn0inv01qYUEyUw3vT4pz1mW-2BzrMacQxEaFtH0MCboytOBZxKwf8uiWIxxK63b-2FJamAZeLaqkb0E-2BR96OL7OqHRatlOxSSMkqepB2zSw2b-2B6OwgwMTbqAv60ETy-2BHlNxa3OkOT2YMoxOrMNZVw6UewWBE2fc-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18hrcdSIEDdNoyXhTveERR0sGMuEtMYfJNDfYDeNGRF5KBvQjsYoGh4sAjnWnqqM88r52tnr1kq-2FwZwic06gLFzxt8KvhhljnVWJkU4nS6HmYB981pjiC-2BIxuAtPqa6kGOGchg0G-2Fi6ot26KkXj7g4Vsy96MVzDFQB1RyiIeq3ncaD ------------------------------ _____________________________________________ Softimage mailing list Softimage@listproc.autodesk.com https://u9432639.ct.sendgrid.net/wf/click?upn=msg1YMqKv6PblZ6nn0inv01qYUEyUw3vT4pz1mW-2BzrOluqBVZWkvoHAPYy9DTW9xmhOTWxvVP-2F6J9TazGUzf3A-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuROad09aQt2y9GXIz28Rldt21NQ8pBSiMXl0UOKlp18hsETZlYxYs7RD9sbhE-2BaJUxwOyba-2BlsS7Myc7M3bqlawvti9FpHN5tQ-2F9MnUkGsfThtsQkoGU9aM0xMjjIjscwqq8PAdMZC-2B0gf0aZBSoiwAojJB-2FG4Rz-2B2Ik7bqABiOhGrvld02QAstJyyB8rkiXJ-2F6byRIuo0S-2Bl9iGl4lNSgk End of Softimage Digest, Vol 134, Issue 9 *************************************** ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
