Introduction to rigging xsi

Links and discussions concerning tutorials
User avatar
Posts: 857
Joined: 09 Oct 2012, 20:48
Skype: ondraise
Location: Colombia

Re: Introduction to rigging xsi

Post by Draise » 07 Dec 2018, 15:57

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).

User avatar
Posts: 42
Joined: 07 Sep 2016, 01:46

Re: Introduction to rigging xsi

Post by nicole » 07 Dec 2018, 17:07

Rork wrote:
07 Dec 2018, 14:29

TL:DR: Yes! :P

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 ;)

oh. that seems way interesting.
indeed, i'll start by google "baking in fbx" to seek out the possibilities. thanks a lot!