Summary
Softimage XSI’s raytraced shadows (in Mental Ray, the native rendering backend) become broken with a major release. They created shadow artifacts at the shading terminator in high detail meshes. This was easily observed as a regression from earlier XSI versions. Also, when compared against a similarly configured scene rendered in Maya’s Metal Ray integration.
The VFX/Anim company in question had an up-to-date service contract and an assigned service contact. They were relatively high-profile users of the software, having been featured in SoftimageXSI’s yearly show-reel multiple times.
The Softimage service contact refused to accept that the bug, was a bug; and log it as such. The service contact was gate-keeping the development team and sending back poor amateurish advice to the company instead.
Eventually the company used their high-level contacts to go around the service contact and get the bug seen by the development team. The development team immediately realized what had broken and put a fix in for the next version of XSI.
However, because the company didn’t have enterprise level support and instead had standard (paid but not elevated) support, the fix would not become available to them until the next product release cycle. Repeated requests to release a hot-fix or QFE (quick fix edition) went ignored by Softimage.
The company was forced to forgo the use of raytraced shadows for their project.
Takeaways
Customer support (CS) can be a hinderance rather than a boon to both vendor and client.
The customer support rep in question became somewhat infamous within the Softimage user community. However, it’s important to note that said support rep was never removed from their post or their clients.
This is unfortunately, the norm for many proprietary software products. It’s really never okay to assume that CS will do the job right.
A good software vendor will be able to constantly review their CS team’s performance and eventually weed out bad eggs. But it’s not appropriate to assume that a large software vendor is doing this properly. The block may be semi-permanent. And such a block, if it exists, does need to be considered when (re)evaluating the use of the software.
Sometimes, higher level contacts are the only way.
It’s extremely unfair. But sometimes, high level schmoozing, glitz and being ‘important’ are the only way to get legitimate problems recognized and resolved. And sometimes, even that’s not enough to get full resolution.
Proponents of ‘tech-meritocracy’ and the functioning of ‘free markets’ should make note here: Having a very important, well-documented, provable bug; and presenting it to a private tech company operating in a free market; doesn’t necessarily result in the bug being fixed. Nor should it be assumed that this experience is an anomaly. There’s little proof of a positive or a negative outcome being common.
Rather, having clout is often the only way to guarantee a reasonable outcome. That’s not tech-meritocracy. Being right doesn’t matter.
Very bad (costly) work-arounds may be necessary
When these issues metastasize, a company cannot just throw its hands up and cancel the project. Rather, a work-around will become necessary.
In this case, using all kinds of other ridiculous light types and settings. The project rendered orders of magnitude slower, and created visual artifacts.
This had effects on cost (render-times==electic-bills) and client satisfaction probably was lower (which can also be costly).