@scroll_lock did a really nice article about “rig data serialization” or what I call “Data centric rigging”
I agree with some parts, but not when it is the best scenario to use it. So I would like to start a healthy conversation to see the different points of view.
Here is my original reply on Twitter: https://twitter.com/troll_lock/status/1269634996983271425?s=20
Hey @Miquel, thanks for the invite 
I love discussions of those sorts. Here is where I’m coming from mostly:
If we separate the concept of a rig into two - control and deformation rigs, then there is no need to rebuild the deformation if only the control needs to change in some way. And by rebuilding we usually mean also decouple / serialize your data and then back again.
For me the best approach is to serialize this data at publishing, which will still allow you all the benefits of reusing the data over multiple assets, while still being able to rebuild the rig fast while keeping the deformation stack intact. In fact, I was thinking to mock up similar approach with mGear, in my mind what needs to happen is:
In fact now that I write it I see this was the exact approach we were doing at Blue Sky when I was there last (maybe it changed since then - 2017, but I doubt it)
We basically had one additional step in the building process:
Connect just constrained / or connected in some other way the control to the deformation rig. We were still supporting crazy amount of code to import/export data from the deformation stack, but it just wasn’t part of the building process.
Hi @scroll_lock
I agree, that if you don’t need to rebuild the deformation part, it can be a big gain to keep that part in a Maya asset while changing the behavior control part.
But, at less for the project that I work, where everything is rigged and animated manually (Cloth, hair, chains, and other character details) the bast majority of changes comes from adjusting the controls and deformation of these elements. So there is no easy way to keep the deformation part.
Probably it is possible in some situations, but other issues can easily arise from this, like leftover nodes or untracked modifications
Going the route of full rebuild each for each rig iteration ensures that everything is more under control, and when we scale to many rigs (we have projects 60+ characters and several resolutions, that can be hundreds of rig assets) having everything serialized and sharing many of the data allow us to do mass updates just changing a few data pieces.
But just to be clear the idea of having the behavior and deformation rig separated (this is very common also in games) is a good idea and not necessarily exclude one to another. But for my experience, it doesn’t solve all the cases that you can find in production.
In the mGear roadmap, I have planned a tool to improve the way that we use custom steps. It will be a nodal processing graph. In this tool, one of the functionalities that I would like to have is the ability to consolidate part of the execution graph in a Maya asset, so you can continue the build from that point or spawn different branches for different character variations. I hope with this approach we can get the best of the 2 approaches
Hi guys, interesting theme here. I’m working in small studio but our rig pipe is based on rig data serialization. I think it depends very much on team. If team is capable to maintain and update the code I don’t see any problem to use it in small studios. For my freelance projects I use mGear(that’s why I’m here 
). So my vote is for “Data Centric Approach”(DCA). However It would nice to have tools that will update control without process all deformation layers/stack. Specially when building heavy and complex rigs.
I’d like to point out that advanced skeleton does exactly this. You basically tag joints with the type of controller you want and then it creates a control hierarchy that hooks into the deformation skeleton.
Unfortunately advanced skeleton is kind of limited to what is supports. I really like the custom steps and automation from mgear.
Blockquote
If we separate the concept of a rig into two - control and deformation rigs, then there is no need to rebuild the deformation if only the control needs to change in some way
Good points @iRex and @Noll! @Miquel what I hear you saying is that in your studio you are dealing with mass amount of characters and variants, which is actually the defacto use case for data serialization. That’s where it shines I am fully aware of the potential there. But in the last year I worked with a lot of studios, some of which can barely say they have a “rigging department” because they rarely do rigging (and that’s why they hired us) and in the rare cases when they DO rig a character it’s usually a one-off character. So I am mostly comparing studios, team sizes and just talking about different approaches and patterns. Even in big studios like Blue Sky we preferred to go the other way by separating the control and deformation rigs and only rebuilding the control rig when we wanted, BUT we also had a lot of tools to serialize / deserialize data and rebuild a whole project’s assets without even the need to go into Maya. For example if we wanted to roll a show wide change to the leg rig, we would simply change a setting on the show level rig template, hit a button and all the rigs would start rebuilding on the farm with the new change. It was beautiful, powerful, but also very hard and expensive to support all the infrastructure for that. So we were taking advantage of the data-centric approach, we just didn’t serialize/deserialize on rig build, but rather on rig publish.
In web development right now there is a lot of debate on “microservices architecture” vs “monolithic architecture”, which is quite honestly the same thing - do you divide your application in multiple sub-applications or do you just make one giant monolith application. And here is Martin Fowler who I really value as a thinker and book writer say about that: https://www.youtube.com/watch?v=u_LnubpBDCA
Anyway, I think we all agree there are many ways to skin a cat and with the blog post I just wanted to point people to take into account their team size and needs when deciding on what approach to take.