[softroom]

I am finding the lack of backwards compatibility between 2.6 and 2.5 incredibly frustrating.

It's certainly great that the software continues to develop, and at times that will probably mean dropping some legacy support in order to unlock new possibilities.

We're midway through a project and we needed to tweak some images produced under 2.5 for a client, and now find that the lighting setup has changed completely. We're being forced to rework everything for 2.6 since our render farm provider has dutifully upgraded to the latest version of the software - Normally I'd never upgrade mid-project, but given Maxwell's processor demands realistically requiring a render farm, we're kind of tied into this upgrade.

Because the multi light channels operate completely differently - matching between the 2.5 and 2.6 shots is impossible.

Or am I missing something major here like a "retain compatibility" switch on file output??

[Mihai]

The problem with MXI emitters is a bug but the other things you mentioned shouldn't be happening for example with emitter strenght. The strenght has not changed but the units used to display the ML emitters which now use real units. Could you post an example of the difference in strength between versions?

[softroom]

Thanks for coming back to me - I have toned down my previous rant - since if the MXI issue is a bug, it's unfortunate (and it's quite a fundamental bug not to have caught in testing) but hopefully you can fix this in an update.

However, the bigger problem with balancing renders between 2.5 and 2.6 remains.

We have a number of complex scenes, where we have to use Multilight to adjust the balance between IES internal illumination and the Physical Sky and Sun. I'd love to be able to do this in advance and not use Multilight afterwards, but there certainly wasn't the adjustability in 2.5 to be able to do this.

So we now have to re-render with 2.6 and try to adjust the complex lighting setup to match the 2.5 images we will be blending the finished results into (there was some complex retouching in the earlier images that I do not wish to repeat).

Now - this should have been quite easy - just open up the 2.5 MXI with all the customised Multilight settings, export the emixer data, and import it into the new 2.6 MXI.

Oh, if it were so simple. Of course, the new lighting system has now two different channels for the sky, and the IES is configured differently. So 2.6 can't read the 2.5 emixer data. Surely a numerical transformation matrix between the two would have been possible - or just a switch to use the 'classic' 2.5 setup, rather than the 2.6 version.

I can entirely sympathise with how complex managing software development for a product like Maxwell must be, but some simple checks to see what happens when you try to render a scene created in the previous release would seem prudent - perhaps you did this and we are just experiencing unusual glitches? I would understand more if it was a jump between a whole digit release (2.x to 3.x), but for an incremental release it's very disruptive to workflow. As I mentioned previously, I would never normally upgrade mid-project, but since we are tied to using a render farm to get the images out in a human-timescale, and they can only run a single version (which, correctly is now 2.6), we're stuck.

Don't ever stop improving - just keep us production-pressured customers, for whom ongoing compatibility is a serious consideration, in mind!

[RobMitchell]

To be fair it does seem like the majority of your issues have come from the fact you're using a different version of the software midway through a project, which is never a good thing and really points towards an answer to most of your topic's queries. I know you also realise this as you've already stated, and I appreciate you're bound to using a render farm who have upgraded, but it can't be blamed too much on Next Limit when that's the case. If I updated my modelling software while I was still working on a 3D model and they'd removed a tool I needed, it wouldn't feel right to blame them as such. But the situation you're in is pretty unfortunate - especially as you can't 'downgrade' - so I can absolutely see where the annoyance has come from.

We're still not on v2.6 purely for this reason. We've got a few projects that are yet to be fully signed off and we know there's a high chance of making large to subtle tweaks before it's done, as is usually the case in CGI.

You've got a good point, though. It's pretty difficult to know when you should commit to the upgrade jump sometimes. Not only because of tool and setting changes, but also because of potential bugs.

[softroom]

You're quite right - (apart from a bug issue with MXI emitters) the issue is entirely because we've been forced to switch half way through a project.

But the underlying question is one of what degree of responsibility NextLimit wish to take towards smoothing the upgrade path for their customers. It doesn't seem like it would have been that big a deal to write a piece of translation code to cover the lighting change with an optional switch - but just to instantly make the previous emixer files incompatible (without any warning of this in the documentation) is quite an oversight.

Just seems like the implications weren't fully thought through. Nobody can be expected to think of everything - but a bit more real world testing could have highlighted this. In the grand scheme of things it's not a disaster - MWR still produces the best results out there - it's just been very disruptive and annoying and makes me wary going forwards.

Shades of the Apple Final Cut X story?