Friday Flashback #611

[Stephen Blair]

https://xsisupport.com/2026/01/30/friday-flashback-611/

Five Unleashed and 3ds Maya...

[Sven Constable]

And if Softimage would have been even one or two years earlier with its initial release of XSI! Just that tiny fraction of time in its existence… we would most likely still work have it. 😊

With the newest version 24.2 in 2026. Imagine that. With all the nice features and cutting edge technology. Below houdini of course but superior to max and maya easily.

 

Sven   

--
You received this message because you are subscribed to the Google Groups "Softimage Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xsi_list+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xsi_list/CANi5zxnnSV1JPKZR%3DqDPeGO2nrxiyKv4weQ5fEHOi-B2EnA_Zg%40mail.gmail.com.

[Sven Constable]

‘would most likely still work have it.’

Sry, typo. We would most likely still work with it.

 

Nice weekend all.

Sven

To view this discussion visit https://groups.google.com/d/msgid/xsi_list/003001dc921f%2494336570%24bc9a3050%24%40imagefront.de.

[Matt Lind]

I disagree.

Getting to market 2 years late was a major setback, but even if they had
made it to market on time, XSI would likely still have met an early
death due to technological decisions that were made.

XSI's core is COM/OLE, which is long deprecated by Microsoft. Finding
quality engineers who understand it and would still be willing to work
with obsolete technology was becoming a problem - and similarly why Modo
was likely retired.  COM/OLE effectively made XSI a windows application
and not easily portable other operating systems.  I don't know if the
move to COM/OLE was planned from the outset as part of the Digital
Studio project, or was a reaction to Maya making it to market first, but
either way it sealed the application's fate early on.  Customers did not
want to use COM/OLE for plugin development as that was the original SDK,
and the backlash forced the addition of a pure C++ API, but the C++ API
had holes as certain features/access were never available forcing
developers to still jump into COM/OLE now and again as needed.  The
NURBS modeling was the emphasis of XSI 1.0, but ImageWare, the developer
of the NURBS library used by XSI, was acquired soon after XSI hit the
market, and support for the library dwindled.  mental ray was a powerful
renderer, but tightly entwined in the application, and long in the tooth
as faster competitors came online.  While other renderers could be
adopted, mental ray could not be easily removed - as was demonstrated by
the XSI 6.0 debacle, which was effectively a repeat of the Creative
Environment 2.65 debacle.

XSI would've needed a major facelift along the lines of what Maya
received with it's parallelization upgrades.  The user interface was
multi-tasking, but single threaded and a bottleneck to performance. The
custom hardware shaders and viewports were abysmally slow and usually a
version or two behind in API support.  ICE was essentially an embedded
application with it's own proprietary architecture.  The VBScriptand
JScript scripting engines were still on ECMA script 5.6 from the year
1998.  You can band aid things only for so long before it catches up
with you.  While XSI was in much better shape than Softimage|3D at the
same point in it's life, XSI still needed significant overhauls in key
areas to clean up the application. When 'Sumatra' was originally
pitched, it was pitched as a platform for 'the next 10 years', not
infinity.  10 years goes by quick.


Matt







------------------------

[davids...@gmail.com]

Yes, its one of the reasons XSI failed. Do you think it could have been re-written to get rid of COM/OLE?



David Saber

--
You received this message because you are subscribed to the Google Groups "Softimage Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xsi_list+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/xsi_list/EA2P220MB13087C286069810F8E73DA91E99DA%40EA2P220MB1308.NAMP220.PROD.OUTLOOK.COM.

[Matt Lind]

Only a Softimage engineer could answer that, but based on my experience in other realms, I would say no.  There is a universe where that could be done, but it's like the opening scene of the movie 'Raiders of the Lost Ark' where Indiana Jones replaces the gold monkey head with a bag of sand.  In order to succeed you must address every detail because even the smallest mistake can be catastrophic.  You must consider the fallout before you go down that path.  I would cite XSI v6.0 and Creative Environment 2.65 as examples of what happens when you try to do that, and why it shouldn't be done.

Softimage was riding a wave of success in 1993.  Creative Environment v2.6 was a very solid release with inverse kinematics, lattice deformations, and other important tools that until then had not existed under a single application, and were user friendly enough that artists could be employed to use them instead of engineers.  It was the main tool for animating the dinosaurs in Jurassic Park.  On the success of that movie, Microsoft came knocking and acquired Softimage with the intention of using their other product, code named 'Digital Studio', to tame web 1.0.  In order to improve the bottom line of the company and turn into a household name, Microsoft wanted to port Creative Environment to the Windows NT operating system (it was exclusively on Silicon Graphics UNIX workstations), drop the price by more than half (it cost more than an automobile), and rebrand it as Softimage|3D.  Creative Environment was developed by contract developers working on subsystems independently.  One guy wrote the renderer, somebody else wrote the animation system, etc...  Eventually the application became a team managed product, but it wasn't like that at the beginning.  There was no formal SDK or automation capabilities.  The only way to use the application was through the buttons provided in the user interface.  Which meant, as long as the buttons activated the right features, it didn't matter how it was wired under the hood as long as it worked.

With the financial stability provided by Microsoft, Softimage decided it was now time to get under the hood and fix all the issues that had plagued the application.  The modeler was infamous for being very buggy resulting in many data corruptions, crashes, and lost work.  It was the Achilles heel of the application. So for Creative Environment v2.65 they dove in and tried to fix the modeling core....but it didn't go as planned.  As one bug was fixed, new bugs would appear.  As those new bugs were fixed, other new bugs appeared.  It was a game of whack-a-mole.  The post mortem revealed that because of the application's ad-hoc development pattern, many workaround functions were written to patch specific problems.  But as the original problem was fixed, it inadvertently broke the workaround function, and that rippled out to the surface of the application creating all the grief.  Eventually the ripple effect got so big that customers could no longer work and many service packs had to be issued to get things under control again.  It nearly sank the company.  Service packs were versioned with letters, not numbers.  It wasn't resolved until v2.65J many months later.  This was back in the day when the software was issued on 4mm DAT tapes, not CDs.  This adventure was fresh on the mind and likely the motivation to announce project Sumatra in 1995, which would later be released as XSI in May 2000.

For XSI v6.0, I do not know the specifics that lead to the debacle, but the version I heard was something like this:

After every financial quarter, publicly traded companies usually conduct a teleconference call so shareholders can ask questions of management about performance of the company, future outlook, etc..  Avid Technology, then Softimage's parent company, had just undergone a shakedown in management.  The interim president and staff were on their first shareholder phone call in October/November 2006.  During the Q+A part of the call, a shareholder asked about Softimage, such as when the next release was scheduled as it had been a while since the previous version (v5.11) went out the door.  The response from Avid was that v6.0 would ship by the end of the year (i.e. in less than 60 days).  With the release of XSI v5.11, Softimage had finally reached a point where they could exhale after spending the previous 5 years clawing their way back into relevancy as a result of getting to market 2 years late behind Maya.  During that clawback period, some shortcuts had to be taken in developing/implementing certain features in order to maintain schedule.  For example, using mental ray's library for raycast selection in the viewports (or so I'm told).  Softimage decided it was time to tear XSI down to the studs and clean up the code in preparation for the next big push.  It was expected to be a big undertaking requiring at least a year to complete.  Well, when the Avid president spoke on the teleconference call, it put Softimage on the clock unexpectedly and they were legally bound to deliver on that promise.  At that particular point in time, XSI was completely disassembled like an automobile at a chop shop.  Softimage had a matter of weeks to put humpty dumpty together again and ship it as XSI v6.0 including new features.  Failing to do so would put them in very hot water with the SEC for violating disclosure laws with regards to things that affect their stock on the exchanges as it could be construed as insider trading or similar.  In order to satisfy the directive, Softimage couldn't just re-package 5.11 and push it out the door.   They had to incorporate enough new code that it was justified as a new release.  When you try to put a year of development into a 5 week window, there's bound to be a lot of things that don't work.  That's why XSI v6.x was such a disaster and why there were so many service packs released that year....and why some of the issues from that release still persist in the application to this day.

So to answer the question - to get rid of COM/OLE would require the entire application core be rewritten from scratch.  While possible, it's a very big undertaking with a lot of risks.  It's usually quicker and easier to write a new application from scratch implementing the desired changes as it allows you to run full speed ahead focusing on your goals instead of looking over your shoulder making sure you dotted your i's and crossed your t's at every step and being penalized with every mistake.


Matt



---------------------