I don’t care whether mux is 0 or 1 in the least. What I do care about is that the development of Flame proceeds along relatively utilitarian lines.
If 1000 people can save 5 seconds a day, but it costs 1 person an hour a day thats a net benefit. It sucks to be that one person, but in the long run this approach pays dividends.
Not claiming that changing mux is necessarily a net benefit, and I recognize that determining which things are a net benefit can be very difficult.
That said, I think its generally agreed that restoring archives and working on old setups is a relatively small percentage of what we do as Flame artists. The average Flame artist almost certainly spends less than 1% of their time in such scenarios. So as a general rule it seems to me that anything beneficial to the other 99% of time should be weighted appropriately against the need for archive compatibility.
Especially because the further removed you are from a project in time the less likely it is to be restored. Realistically, the vast majority of archive restores are probably less than five years removed from their initial creation. That puts a time limit on any possible negative effects from a lack of backwards compatibility whereas avoiding changes to the program that could provide a benefit moving forward is a daily tax on all of us in perpetuity. Again weighing these things out it is difficult, but since the benefits of a change accrued in the future are theoretically limitless that tilts the scales heavily against the time limited nature of negative effects from a lack of backwards compatibility.
I had to revise all the wide shots in this spot 3 years after we initially shipped it:
There was a crap ton of cleanup, rig removal, keying etc needed to put that together. Not having the archive would’ve meant days and days of redoing already completed work. Sorry, but breaking archiving in the name of imagined productive gains concocted with made-up numbers is a horrible, HORRIBLE idea.
Andy’s idea of the Gmask Tracer vs legacy Gmask node is a much better way of addressing these issues imo.
I don’t know that any of us, even those who do care, care a lot about the mux input numbers.
The larger issue is that the rationale behind many not-improved aspects to the software (text, the color corrector, particles, etc) is that to improve them even somewhat (a la the mux input change) would break backwards compatibility. This then begs the question how much of the software is being held back out of this concern.
Maybe Autodesk should designate certain versions of the software to be license-able for X years so that those who need to restore old jobs can do so without that need being a drag on overall development.
If we had a versioning system of nodes we could avoid this. Using this mux discussion as an example…
A mux in pre 2024 could be called mux when called for a batch. 2024 could call that same mux for legacy and mux2.0 for new scripts. Mux would be hidden from the node bins and search menus so you could only create mux2.0 from scratch.
Seems like a smart way forward @fredwarren and I’m sure you’ve already considered it.
I think that’s what Houdini does. I keep doing tutorials from 2-3 years ago where they tell me to use some node that is no longer there, and then I google it and the manual is like, “yeah, we nuked that. this replaces it”
Nuke absolutely does it although recently they hid it from the user. There are still stupid old nodes in there that no one uses except for old scripts. You used to be able to get a full listing and call the bezier node rather than roto.
If changing a mux has rippling effects for legacy, that same issue arguably stands in the way of all small fixes that could be developed and deployed quickly with little regard to previous software versions.
Those small fixes or updates could be huge when weighed together. At least how I see it.
