Yes. Basically the universal workflow is this:
Software V: modeling, UV's, shading, texturing, etc (mesh and materials)
Software X: rigging, animation, simulations, etc (rigs and animation)
Software Y: import Alembic/Cached animation, lighting, lookdev, render, etc (lighting and rendering)
Software Z: composition and post FX's
Any work with rigging and animation is usually locked to the software you rigged in, other words all the pipeline work you do in Software X is locked in Software X till you cache it and export it. There is no interoperability of inner Software X's functionality with any other software (without breaking) other than baked Alembic cache system or simple rigs with FBX (even then they can break).
Introduction to rigging xsi
Re: Introduction to rigging xsi
oh. that seems way interesting.Rork wrote: ↑07 Dec 2018, 14:29
TL:DR: Yes!
But in all seriousness, -every- 3D application has it's own rigging philosophy. And non of them are compatible. Too many differences.
So yes, rigging is a major pain between applications.
That's why animation between applications is often transferred as Alembic, as was mentioned. Or baked down FBX. Something that is basically just point data + transfer information.
Or is used for big projects, where you want to work on scenes as light as possible, and when the rig isn't needed anymore, bake the results and start with that. E.g. for rendering, or simulation/FX.
But this is a topic that can get technical very quickly
rob
indeed, i'll start by google "baking in fbx" to seek out the possibilities. thanks a lot!
Who is online
Users browsing this forum: trendiction [Bot] and 58 guests