PDA

View Full Version : Maya Reference Objects



erikals
10-14-2015, 10:55 AM
posted upon request >


Seems the blog is updated

"the truth is that being able to update an important model design instantly in 5000 shots on a television project is extremely useful and is only possible because of the legacy of LightWave’s dual architecture approach. That is a fact that I stand by."

That dual architecture approach is obsolete because other 3d appz have referencing that don't need this much touted feature of old lightwave.




the bit boring thing about unified apps is that you have to 'export' models.
when working with movie sets this can tend to be tiring, as people forget to use referencing, one would therefore often have to find the correct scene, for then to 'export' the correct model. this is how it's done in Maya > https://vimeo.com/48579833
if you have 500+ scenes, this gets to be extra time consuming.

with the LightWave method however, it's straight forward. (just remember to use "Enable Bump" for displacement)
LightWave also stores Endomorphs inside your model... http://erikalstad.com/emoti/heart-1.gif


@ lightscape
Yes....and no.

We're talking about a different kind of referencing here. I've been working with Scene Referencing in different packages, and often had some bad surprises. Referencing is a delicate topic.
Rob is of course talking about model referencing, which is something somehow always available in LightWave thanks to its dualism (LWS and LWO). Replacing a model in LightWave is a pretty natural operation, that doesn't need any further and specialized "referencing" definition in the software. It comes for free, without much trouble for the user.
In other packages replacing a mesh for a rigged character with another mesh is something not as immediate as it can be done in LightWave, where you have zero risk of introducing any dangerous variable in a production.

Of course we perfectly understand the importance of support for Scene Referencing. But we also think it should be something very easy to use and "risk free" for the final user. Needs to be approached carefully.

Surrealist.
10-14-2015, 11:19 AM
Well first of all referencing (even objects) in LightwWave is not nearly the same as in Maya or other apps.

Have a look at the app in question - in the manual preferably - for the difference. It is likely you won't fully be able to understand it though unless you have used said app quite extensively. But for a mental exercise it won't hurt to do some actual work on it and look into it yourself rather than rely on someone like me to tell you what it is.

Suffice to say. There is no such thing in LightWave. This has been discussed numerous times over the years.

Second. Referencing is a conscious workflow. If you use it, you use it for a reason. And you set up your workflow from the beginning to take advantage of it.

Third to use objects across multiple scenes it does not require referencing or importing exporting. You can also import Maya scenes into a Maya scene.

Similar to LightWave workflow, you create rigging scenes for characters that are separated for their own purpose. And you normally create separate object scenes for their own purpose. This workflow has also been discussed endlessly in other threads. I am not sure why it has to come up again.

But here we are discussing the same things over and over again.

So there is little to no difference between the two workflows. The difference is the technology in Maya gives you generally more advanced options than current LightWave.

There is also quite an extensive Level of Detal workflow in Maya and a few other things useful for large scenes. Similar in some ways to things you can do in LightWave, but again, generally more advanced.

For more details consider actually studying these other apps more seriously.

It will help you to understand LightWave better as well.

Rayek
10-14-2015, 11:21 AM
Quoting Rob:

Several loud voices in the forums were continually pointing out the weaknesses of LightWave’s dual architecture and I simply wanted to provide some balance to that rhetoric because the truth is that being able to update an important model design instantly in 5000 shots on a television project is extremely useful and is only possible because of the legacy of LightWave’s dual architecture approach. That is a fact that I stand by.

While I understand him defending Lightwave's dual architecture, I would argue that replacing objects in 5000 shots is "only possible because of the legacy architecture" is a bit misleading.

What I would like to see in an upcoming new Lightwave, are similar options which I have access to in Blender: in a library file I create groups with objects. I can then link to those groups. With a simple add-on (edit linked library), I can easily switch to the original library file with one click (with an option to open a second instance of Blender), and edit the object(s) and meshes, materials, etc. in the group. Swapping out a mesh inside a group is just one drop-down list away. And then I switch back to the original file with a click on a button, and the changes are applied to the master file.

It sounds similar to LW's replace object approach. The difference is that Blender's approach is more akin to accessing a database table (data blocks) in an external database - and I have a choice of options what to link to. I also have the option to reference an object which remains in place and cannot be transformed/translated at all, or create a proxy, and simple duplicating options to break the original link, or keep it linked. I can have scenes which are linked to other external scenes, or copy a scene with all the objects linked, so I can extend upon it. Or link up images externally.

Anyway, the point I am trying to make here is that a consolidated application may offer a much more flexible referencing system - offering features which are impossible to achieve in a dual architecture such as Lightwave's.

For example, while I am working with the external library file (which can consist of as many sub-scenes I want, with linked objects between scenes and other external libraries!), I have the option to render the result in real-time while working on materials. What is more, I can link externally to the light setup I use in the master file, so my material setup will look identical to what I may expect when the library object is rendered in the master file. Or create a quick linked scene within the library file to test different light setups. The referencing in Blender works well within a team structure too this way.

It really is a very flexible referencing system once you get accustomed to the terminology. It can speed up things immensely.

I would love to see similar referencing features built into an upcoming Lightwave release. But that can only happen after LW becomes consolidated as a single, non-dual, application. Based on Rob's words, it will hopefully happen before Lightwave's 30th birthday.:thumbsup:

erikals
10-14-2015, 11:29 AM
Suffice to say. There is no such thing in LightWave. This has been discussed numerous times over the years.
and i never said there was


Second. Referencing is a conscious workflow. If you use it, you use it for a reason. And you set up your workflow from the beginning to take advantage of it.
never said anything else


Third to use objects across multiple scenes it does not require referencing or importing exporting. You can also import Maya scenes into a Maya scene.
never said anything else


you really need to read what i'm writing. not sure why you think i wrote all of the maya referencing was inferior.

bobakabob
10-14-2015, 12:24 PM
To keep things simple: The LWS file format combined with Replace Object in Layout as Rob says allows for a very efficient CA workflow so you can animate a proxy or WIP character mesh whilst still modelling / updating the character(s) intended for rendering separately. Layout LWS stores the animation file and it's then a matter of swapping out characters on rigs. Correct me if I'm wrong (I would be very glad to be) but an advantage over Maya is that weights (if you need them) are actually embedded in the LWO file whereas in Maya they are essential and "projected" onto the mesh from the rig and so may need extensive editing following swapping out meshes. You can "save" weights as image files but I've had patchy success when updating files and also encountered some unpredictable results with updated referenced meshes not correctly binding.

In Maya referencing is essential to keep file sizes low and productions efficient especially if you're loading character meshes with multiple blend shapes. Without this approach a simple scene can be several gigs in size so you don't want to think about too many incremental saves. So referencing allows work simultaneously on animation and modelling whilst keeping file sizes tiny by comparison.

Surrealist.
10-14-2015, 12:56 PM
and i never said there was


never said anything else


never said anything else


you really need to read what i'm writing. not sure why you think i wrote all of the maya referencing was inferior.

I was responding in a general way to what both you and Lino have said. All of the quotes you put up there.

You said this:


the bit boring thing about unified apps is that you have to 'export' models.
when working with movie sets this can tend to be tiring, as people forget to use referencing, one would therefore often have to find the correct scene, for then to 'export' the correct model. this is how it's done in Maya > https://vimeo.com/48579833
if you have 500+ scenes, this gets to be extra time consuming.

Apples to apples. The exact thing can happen in LightWave. There is absolutely nothing about the unified app workflow, Maya or otherwise that can cause this. It is therefore not a valid point. At all.

Mainly for all of the reasons I stated above in my comparison between the two apps.

Surrealist.
10-14-2015, 01:15 PM
Correct me if I'm wrong (I would be very glad to be) but an advantage over Maya is that weights (if you need them) are actually embedded in the LWO file whereas in Maya they are essential and "projected" onto the mesh from the rig and so may need extensive editing following swapping out meshes. You can "save" weights as image files but I've had patchy success when updating files and also encountered some unpredictable results with updated referenced meshes not correctly binding.

Actually they are not really projected from the rig. I mean initially yes if you want to start that way. And then you paint further to refine it. The weights are not really embedded in the same way. Everything in Maya works on a nodal system so, you have a nodes that store the information and they are plugged into the mesh (to simplify). And the nodal system is also not my specialty. But that will suffice as an explanation.

Copying weights from one version of a character to another is fairly straight forward. You can just shift select and choose copy weights after you give the new character a skin definition. Obviously your results will change depending on different the two meshes are. But it works very well if you are making modeling changes or other things that might add history you don't want. Or in the case you have an updated version you can swap it out very quickly.

erikals
10-14-2015, 01:28 PM
as people forget to use referencing, one would therefore often have to find the correct scene, for then to 'export' the correct model
so that is not a valid point???

LightWave also stores Endomorphs inside your model...
not a valid point??

an advantage over Maya is that weights (if you need them) are actually embedded in the LWO file
no valid point?


you know what! next time you go into attack mode like in that other thread, think twice

bobakabob
10-14-2015, 02:25 PM
Actually they are not really projected from the rig. I mean initially yes if you want to start that way. And then you paint further to refine it. The weights are not really embedded in the same way. Everything in Maya works on a nodal system so, you have a nodes that store the information and they are plugged into the mesh (to simplify). And the nodal system is also not my specialty. But that will suffice as an explanation.

Copying weights from one version of a character to another is fairly straight forward. You can just shift select and choose copy weights after you give the new character a skin definition. Obviously your results will change depending on different the two meshes are. But it works very well if you are making modeling changes or other things that might add history you don't want. Or in the case you have an updated version you can swap it out very quickly.

Of course it's all nodal in Maya. But - when it comes down to it (as far as my own humble experience goes) you don't, indeed can't define weights on a model before skinning it in Maya. This does have some advantages in LW as with basic character models you can work quickly and as Splinegod used to argue, in many instances you don't need weights at all if you create a few well placed hold bones.

I used weight "projection" as an analogy... Joints in Maya initially define the weights automatically according to parameters you set before hitting the Skin button - which can be very hit and miss depending on the complexity of the model (though big improvement in 2016 with the "geodesic voxel" tech). Then comes the manual weight painting / editing which can be painstaking, but is ultimately an effective system and does give very focused accurate control (you can edit individual points if you wish).

Hopefully a more unified future version of LW will allow weight painting directly in Layout. Going back and forth between Modeler and Layout to edit weights is certainly do-able but not the most elegant solution.

I don't agree copying and pasting weights is that straightforward in Maya when updating referenced character files. OK if the essential mesh is roughly the same but you may as well go back to weight painting from scratch if there are major edits.

Back to the original point... As a LW CA user I do agree with Rob that LW's default referencing system, on balance is a great strength, despite the frustrations with editing weights in Modeler. Although it's really time we had this facility in Layout.

Surrealist.
10-14-2015, 02:31 PM
so that is not a valid point???

not a valid point??

no valid point?


you know what! next time you go into attack mode like in that other thread, think twice



lol

No I stand by the things I said. Eric. I don't have to think twice. I know the things I say are true because I have experience with it. I know what I am talking about.

You are going all overt the place subject wise now. It is not up to me to correct everything you say.

Take a step back and do your own homework. And then you will not get into these situations where people will come after you. Sure I was in "attack mode" Sorry for that. That was a bit over the top. But you also have to take some responsibility for putting yourself in that position. It is a two way street.

And everything I said was true. You need to actually look into things yourself more closely. Arguing with me over it will not change anything.

Lets just leave this alone because it is getting too emotional and that is primarily my fault.

So accept my apology and move on.

Surrealist.
10-14-2015, 02:42 PM
Of course it's all nodal in Maya. But - when it comes down to it (as far as my own humble experience goes) you don't, indeed can't define weights on a model before skinning it in Maya. This does have some advantages in LW as with basic character models you can work quickly and as Splinegod used to argue, in many instances you don't need weights at all if you create a few hold bones.

I used weight "projection" as an analogy... Joints in Maya initially define the weights automatically according to parameters you set before hitting the Skin button - which can be very hit and miss depending on the complexity of the model (though big improvement in 2016 with the "geodesic voxel" tech). Then comes the manual weight painting / editing which can be painstaking, but is ultimately an effective system and does give very focused accurate control (you can edit individual points if you wish). Hopefully a more unified future version of LW will allow weight painting directly in Layout. Going back and forth between Modeler and Layout to edit weights is certainly do-able but not the most elegant solution.

I don't agree copying and pasting weights is that straightforward in Maya when updating referenced character files. OK if the essential mesh is roughly the same but you may as well go back to weight painting from scratch if there are major edits.

Back to the original point... As a LW CA user I do agree with Rob that LW's default referencing system, on balance is a great strength, despite the frustrations with editing weights in Modeler. Although it's really time we had this facility in Layout.

I don't use auto skinning really. I have found it best to use closest influence put the max influence to 1. And then I have clean wieghts mostly on the parts I need. Then I go back in and smooth between and tweak. And yeah it is tedious. But I accept it because I need to use weights. And I found this method works best.

When I am working in LightWave I really don't use weights anymore. I have Larry to thank for pushing me in that direction. And it is a very nice workflow that way and very flexible.

Copying weights in Maya you are right. But there is no real silver bullet for that anywhere I am aware of. But I do use it all the time when skinning in Maya. And it works under certain situations very well and saves me a lot of time.

Thing about weights though is that with a game pipeline there is no other option. And in my case using MotionBuilder it is also essential. So for me LightWave bone influence is not really an option - at least in my pipeline. It has to be weights which pretty much excludes LW from that end of it for me.

erikals
10-14-2015, 03:17 PM
You are going all overt the place subject wise now. It is not up to me to correct everything you say.
this is just BS

faulknermano
10-14-2015, 03:25 PM
Second. Referencing is a conscious workflow. If you use it, you use it for a reason. And you set up your workflow from the beginning to take advantage of it.

Referencing is a technical feature that's used in a conscious workflow, not the workflow itself. However, in LW's case of loading LWOs, it's a behaviour, and thus you have no choice.



So there is little to no difference between the two workflows. The difference is the technology in Maya gives you generally more advanced options than current LightWave.

I don't know what you mean by 'workflow', then. Technology modifies workflow. The more drastic your difference, the more drastically different the workflow can potentially get. The fact that Maya's referencing system is more advanced allows me to reference not only shaders, rigs, objects, etc, but anything that can be encapsulated in a Maya scene (with some inbuilt exceptions for certain flagged nodes). That's a design that is more holistic; LW's design is more broken down into chunks of types of data (eg Handlers).

Referencing, as a concept anyway, is simply being able to re-evaluate external data into the scene. Sometimes this data is 'live' (streamed from disk, eg MDDs, Maya cacheFile), or just read at certain times (eg LWOs, Maya reference scenes). That's the gist of it. So, I'm not sure where the idea that LW has no referencing comes up. In fact, reading MDDs is another example of referencing via the DisplacementHandler. I wrote tools to reference custom motion files via ItemMotionHandler. It's there, but it's different from a structure point of view. But the real difference lies in just what _practically_ you can do with it.




Similar to LightWave workflow, you create rigging scenes for characters that are separated for their own purpose. And you normally create separate object scenes for their own purpose. This workflow has also been discussed endlessly in other threads. I am not sure why it has to come up again.

The main difference is not that you have a separate scene, but that you can change the Maya rigging scene and it will be re-evaluated when the animation is loaded up; the animation scene applies its own set of data onto the reference it has (ie reference edits). Again, the glaring difference is just how advanced it is: when updating the rig, I'm not just updating motion envelopes (like LFS), but updating almost every possible aspect of the rig, whether it be an expression, a set-driven key, a connection, a new item, a removed item, etc. That's possible because the data that is being referenced as been generically (generally speaking) consolidated. So, off-the-shelf, it's not similar to LW's workflow in the least bit.

However, it is possible to create tools that will allow more areas of LW to be reference-able. shaderMeister touches a bit on this by separating the concept of shading from concept of mesh. Another tool -- I forgot the name -- updates rigs that have been animated already. However, I couldn't say if the tool was designed with referencing data in mind or simply a brute force way of making it appear that it has been referenced. This is in the same vein as Load From Scene's option of applying motion changes only. The problem with that sort of workflow is that it only addresses a narrow set of issues, instead of something that is more generic. So it's not a problem of the concept of referencing, but how it is implemented.


For more details consider actually studying these other apps more seriously. It will help you to understand LightWave better as well.

In case there is any ambiguity and a need for credentials to avoid seeing statements such as these echoed back at me, I've used (still using) both apps for 12 years, most of those years as a TD.



Correct me if I'm wrong (I would be very glad to be) but an advantage over Maya is that weights (if you need them) are actually embedded in the LWO file whereas in Maya they are essential and "projected" onto the mesh from the rig and so may need extensive editing following swapping out meshes. You can "save" weights as image files but I've had patchy success when updating files and also encountered some unpredictable results with updated referenced meshes not correctly binding.


Echoing Richard, transferring weights from one mesh to another is the most effective workflow; the idea is that once you've skinned your mesh, the skin data is dependent on the topology (ie point order). If you change it, it's usually better to transfer weights, as the tool itself is pretty good at doing its job. Note that when a referenced mesh (as in a 'mesh' shape node) is skinned, it duplicates the mesh so that the skinned version is not a referenced node; changing your original reference will not yield changes to the master scene. This is, in fact, a weird limitation, but there you go: I'd recommend not referencing meshes to be skinned, because it will turn out to be imported anyway; skinning it will lock the mesh to its current topology, and recovering the original reference mesh takes a few clicks if you know what you're doing. Anyway, I can go at lengths describing several kinds of workflows and the rationale for each of them, but that would be too Maya-centric.



no valid point?


Referring to embedded weights, I'm not sure if that's anything to do with referencing, per se, as it is how the referencing is being implemented. Because the architectures are so different, the workflows become different. Even the skinning method are totally different, so it makes complete sense why LWO's store the information in the object: where else?

Re Endomorphs, conceptually, Maya has the information in blendShape nodes. The main difference is how difficult it is to access that data without poring over the blendShape node's array structures and go into a bit of scripting. I did that myself, so I know. But again, referencing has nothing to with it. In fact, that _is_ referencing in its own way.

Btw, there are other examples of referencing; Rayek mentioned Blender, and I would like to point out Unity does a fair bit of that as well. Many ideas to choose from. But if I know LW/NT enough, they'll have to choose something that won't break people's current projects.

faulknermano
10-14-2015, 03:36 PM
Quote Originally Posted by lino.grandi
@ lightscape
Yes....and no.

In other packages replacing a mesh for a rigged character with another mesh is something not as immediate as it can be done in LightWave, where you have zero risk of introducing any dangerous variable in a production.

Of course we perfectly understand the importance of support for Scene Referencing. But we also think it should be something very easy to use and "risk free" for the final user. Needs to be approached carefully.

I understand what Lino says about 'bad surprises' and having it 'risk free'. However, his other glowing points about model referencing is preaching to the choir. It's not about removing model referencing, but having more sensible referencing. The positives of instant mesh replacement did not in the least bit dissuade me from dropping LW as an rigging/animation solution; what made me to was the lack of a holistic referencing system which limited the workflow options that I had. That said, I have to admit that LW had always been the kind of simple, go-to, no-frills prog; fancy potentially-complicated features were never its thing.

Surrealist.
10-14-2015, 03:40 PM
this is just BS

Eric. Let it go. I said I am sorry.

Now you are just angry trolling.

I know you to be basically a good and polite guy. And it was my fault that brought on the anger, I am giving you that. And I can take it. Its OK.

But don't push it and expect me to keep having angry quote wars with you just to prove who is right.

I really don't have anything to add to what I said.

But please, if you want to discuss. I am all ears.

Chris S. (Fez)
10-14-2015, 03:52 PM
It would be nice to see this thread take a more productive turn. Richard, how would you specifically revamp referencing in Lightwave? If you have already addressed this elsewhere, a link or cut-n-paste of your previous comments would be fine!

faulknermano
10-14-2015, 04:17 PM
I don't agree copying and pasting weights is that straightforward in Maya when updating referenced character files. OK if the essential mesh is roughly the same but you may as well go back to weight painting from scratch if there are major edits.


Copying weights in Maya you are right. But there is no real silver bullet for that anywhere I am aware of. But I do use it all the time when skinning in Maya. And it works under certain situations very well and saves me a lot of time.

Funny, but I disagree with you both. My experience of copying weights is pretty solid, unless the client changed the model from a horse to a giraffe or something. In that case of new topology, wouldn't you have to make sure LW weights were re-done after major edits (however loosely we define 'major')?

Surrealist.
10-14-2015, 04:26 PM
It would be nice to see this thread take a more productive turn. Richard, how would you specifically revamp referencing in Lightwave? If you have already addressed this elsewhere, a link or cut-n-paste of your previous comments would be fine!

LightWave does not have referencing. So there is nothing to revamp. But I am sure they have a plan to add it sometime post 2016 as I understand it. And I think they are holding the cards as to how it should best be done. They have a whole new system that we don't even know anything about. So it would be kind of shooting in the dark. Seems they have a handle on it though and will be able to come up with a good solution.

Robert did a real good job of explaining how it works in Maya currently anyway. The LightWave version would be different no doubt and take into consideration LightWave's new way of working, what ever that is. :)

Surrealist.
10-14-2015, 04:31 PM
Funny, but I disagree with you both. My experience of copying weights is pretty solid, unless the client changed the model from a horse to a giraffe or something. In that case of new topology, wouldn't you have to make sure LW weights were re-done after major edits (however loosely we define 'major')?

Exactly. If I am not mistaken I think all three of us are saying the same thing with varying degrees of eloquence. But I think you win on that one. Very well put. :)

Ztreem
10-14-2015, 06:20 PM
Thing about weights though is that with a game pipeline there is no other option. And in my case using MotionBuilder it is also essential. So for me LightWave bone influence is not really an option - at least in my pipeline. It has to be weights which pretty much excludes LW from that end of it for me.

I think that if you export the LW scene as an fbx file it will convert the bone influence into weightmaps. So the workflow actually works for a game pipeline if you want to.

Surrealist.
10-14-2015, 06:51 PM
Yeah that is a good point.

I have never tried it, so I don't know what glitches might be in store. But yeah in theory (as I have not done it before) it could be a decent workflow. Not necessary for me as there are a long laundry list of reasons I won't rig in LightWave unless I absolutely have to. But that is another story.

Thanks for the catch in any case. :)

probiner
10-15-2015, 07:56 AM
I like XSI Referencing. Haven't used Maya.

Not saying its the best and without problems, but made me pretty happy...
A referenced model has some restrictions of things you can change. But everything else you can change is stored into a Delta (they show up in the image on the left) . Which can be Exported and Imported.
And you can change between Local and Referenced, pretty easy...
If a model is not referenced it lives indeed inside the scene file only.
Models also work as a namespace. So everyting that has to do with references, parameteres per model lie onto this structure. For example the reference "this_model.cube" is a relative reference pointing to the cube mesh inside the same model of the object that uses it. There may exist other meshes named "cube" inside other models, but only one exculusive name per model or scene root.
This way you can have the same rig imported 5 times without messups. You can update the model file and all the 5 update, but will keep the changes you've made, due to the Delta.
I've heard the name space thing in Maya goes a bit further. In XSI it's only 1 level.

http://i.snag.gy/Gvuzp.jpg

Cheers

Surrealist.
10-15-2015, 12:09 PM
Lots to love about XSI. One of the things I like is the way it treats instancing with Models. Models - not mesh objects - but containers that can hold anything including mesh etc. They are like mini scenes. If you instance them, any changes you make to anything within the model is reflected in the instance. It is a very handy feature. You can do the same in Maya with groups. But XSI seems to handle it differently. And I like it in XSI a little better. For instance if you add something to the Model in XSI it will automatically update the instance. In Maya, unless there is a preference I am unaware of, you have to manually add or just duplicate the original again which is a pain.

bobakabob
10-15-2015, 01:05 PM
I like XSI Referencing. Haven't used Maya.

Not saying its the best and without problems, but made me pretty happy...
A referenced model has some restrictions of things you can change. But everything else you can change is stored into a Delta (they show up in the image on the left) . Which can be Exported and Imported.
And you can change between Local and Referenced, pretty easy...
If a model is not referenced it lives indeed inside the scene file only.
Models also work as a namespace. So everyting that has to do with references, parameteres per model lie onto this structure. For example the reference "this_model.cube" is a relative reference pointing to the cube mesh inside the same model of the object that uses it. There may exist other meshes named "cube" inside other models, but only one exculusive name per model or scene root.
This way you can have the same rig imported 5 times without messups. You can update the model file and all the 5 update, but will keep the changes you've made, due to the Delta.
I've heard the name space thing in Maya goes a bit further. In XSI it's only 1 level.

http://i.snag.gy/Gvuzp.jpg

Cheers

Nice summary there Probiner... Can you explain what happens to weight maps when a referenced model is updated on a rig?

Rayek
10-16-2015, 01:08 AM
Lots to love about XSI. One of the things I like is the way it treats instancing with Models. Models - not mesh objects - but containers that can hold anything including mesh etc. They are like mini scenes. If you instance them, any changes you make to anything within the model is reflected in the instance. It is a very handy feature. You can do the same in Maya with groups. But XSI seems to handle it differently. And I like it in XSI a little better. For instance if you add something to the Model in XSI it will automatically update the instance. In Maya, unless there is a preference I am unaware of, you have to manually add or just duplicate the original again which is a pain.

That sounds similar to how referenced groups work in Blender: change or amend the group with a new object, and the referenced instance(s) is(are) updated when switching back to the master file.

probiner
10-16-2015, 07:55 AM
Nice summary there Probiner... Can you explain what happens to weight maps when a referenced model is updated on a rig?

Updates too :) You can actually change the weights on the referenced model meshes and have the file update and keep those changes. thought they might not make sense anymore. Because since XSI works with operators the painting changes reside in different operators.
This is just to show the flexibility. For something practical I would just export the end reult of the changed weights in the referenced model, import them on the model file and update.


That sounds similar to how referenced groups work in Blender: change or amend the group with a new object, and the referenced instance(s) is(are) updated when switching back to the master file.

While I was prepping the XSI image I decide to open Blender and "Link" things from another scene. It even see down on several levels of linking from one scene to the other and the other. But I had to make proxies out of the linked stuff to be able to move them. Correct?


Cheers

Rayek
10-16-2015, 10:21 AM
While I was prepping the XSI image I decide to open Blender and "Link" things from another scene. It even see down on several levels of linking from one scene to the other and the other. But I had to make proxies out of the linked stuff to be able to move them. Correct?


Cheers

Yes, that is one approach. A better approach is to group the object(s) in the library file, and, when linking, reference that group. When linked, the group can be translated and transformed as a whole.

And do not forget to activate the "Edit Linked Library" add-on! In the relations tab of your tools (t) menu a handy "Edit Library" button allows for seamless switching back and forth between the master file and the library items.

Rayek
10-16-2015, 10:41 AM
Btw, I linked an animated character (1.1 million tris) of which I activated OpenSubDiv in the subdiv modifier. Realtime playback at 30fps now! Even with subd level 4 (4.5 million tris) I still get a healthy 15fps - on almost 8 year old hardware my 7970 card died on me half a year ago - now running the old 590 gtx).

Cageman
10-16-2015, 03:50 PM
Here is a walkthrough on what you can do with LW and "referencing".

https://www.youtube.com/watch?v=NEu4whF3aoI

This video was published by me almost 1 year ago, btw.

EDIT: Convoluted, yes... but once the groundwork was done... omg it saved a lot of time.

LW certanly needs proper referencing; if it is done similar to Maya or by "publishing" external files; I could not care less. But it should be easy to use (as Maya referencing is, in 98% of the cases).

probiner
10-16-2015, 04:44 PM
Yup, in a way you're just highlighting limitations, in the context of this thread, Cageman, eh!

bobakabob
10-17-2015, 02:32 AM
Referencing is a technical feature that's used in a conscious workflow, not the workflow itself. However, in LW's case of loading LWOs, it's a behaviour, and thus you have no choice.

Referencing, as a concept anyway, is simply being able to re-evaluate external data into the scene. Sometimes this data is 'live' (streamed from disk, eg MDDs, Maya cacheFile), or just read at certain times (eg LWOs, Maya reference scenes). That's the gist of it. So, I'm not sure where the idea that LW has no referencing comes up. In fact, reading MDDs is another example of referencing via the DisplacementHandler. I wrote tools to reference custom motion files via ItemMotionHandler. It's there, but it's different from a structure point of view. But the real difference lies in just what _practically_ you can do with it.

Echoing Richard, transferring weights from one mesh to another is the most effective workflow; the idea is that once you've skinned your mesh, the skin data is dependent on the topology (ie point order). If you change it, it's usually better to transfer weights, as the tool itself is pretty good at doing its job. Note that when a referenced mesh (as in a 'mesh' shape node) is skinned, it duplicates the mesh so that the skinned version is not a referenced node; changing your original reference will not yield changes to the master scene. This is, in fact, a weird limitation, but there you go: I'd recommend not referencing meshes to be skinned, because it will turn out to be imported anyway; skinning it will lock the mesh to its current topology, and recovering the original reference mesh takes a few clicks if you know what you're doing. Anyway, I can go at lengths describing several kinds of workflows and the rationale for each of them, but that would be too Maya-centric.


Very interesting reading these insights, faulknermano. I've been using Maya a couple of years with much to discover (working in a LW/ZB modelling - Maya animation - LW rendering pipeline). Referencing character meshes for skinning is recommended in the Advanced Skeleton auto rigging tutorials (great plugin btw) and at least a couple of AD training manuals I've read. I need to look further into transferring weights from one mesh to another. Along the way I've tested binding meshes without referencing to compare workflow and as expected the file sizes of the resulting scene are huge, turning from MB to GB. I suspect this is something to do with Maya blend shapes (which appear to duplicate the entire character mesh for each endomorph). Is there a way round this? Otherwise object referencing works fine (though at present animated obj referencing is broken in 2016!).

Surrealist.
10-17-2015, 07:08 AM
Once you create the Blend Shape you can delete the mesh. Think of it as similar to background to endomorph. Once it is stored in the mesh you can be done with the BG object - unless of course you want to use it to further refine the mesh. For this reason I will make sure and keep copies in .obj which is usually how I am doing it anyway since I like to sculpt my shapes in Mudbox. But once I get the Blendshape created in Maya I just delete it. Or the files are huge and I hate that.

Another option is to simply make two files. One that you use as a morph target set up file and one with the result - deleted objects and Blend Shape nodes. And you can always go back to the source file and make changes.

And this is where you can use the copy weights command to your advantage. I find the biggest hurdle to a rigging workflow is iteration. Sometimes it is hard to get rid of history before deformation, sometimes it is bugged and just does not work.

So the best solution is to simply copy the mesh, do a quick bind to the bones and then copy weights. Very fast. Less than a minute perhaps.

But this can also come into play in a situation where you are also changing up morphs. What do you do if you want to go back to the blenshape file when you have a rig on the character? Well you could simply re import the changed morph and create a new shape. Or even better you could import the new result scene, bind the mesh, copy weights, done. Works a treat if you have changed a lot of things.

Another situation is perhaps you have realized at any point along the line you want to change up the mesh in some way. Morphs are not working, deformations etc. Whatever the reason, you need to add points or polys or delete stuff, join parts of the mesh that were separate. Again, copy weights workflow is perfect.

Another thing is UV maps and textures. Obvioulsy you try to set up a logical workflow. But as we all know, it is never perfect. And at any time along the way you might realize things need to change. UV map was not done correctly or not working. There is also a transfer attributes function which can be useful. But I find it is much more straight forward to bind and then copy weights.

So for me it is not the larger character to character issues. Although this is nice to have. But I usually expect each character will have unique weights.

What I find is the time killer is iterations and changes within one character. These are more of the day to day things I seem to be up against.

So for me the LightWave workflow is fine, if I have to use it, I will. But since I have so many options for animation open to me with MotionBuilder and Maya, I find it is cleaner to do it there.

And also as a side note. I have done a lot of work bringing rigged characters from other places into Maya and then prepping it for use in MotionBuilder. The problem there is it is usually a hit and miss proposition with the rigs. There have been enough times where I realized deep into the production cycle the the underlying rig was not sound and I had to go back and build a new Mobu bone rig from scratch and paint again. So it is now my policy when I bring things in from outside sources I just trash the rig and do it from scratch. The only saving grace in this situation was that after this happened I could retarget to the new rig in MotionBuilder in a few clicks and not waste any of the animation.

Wow, that went on for a while. Hope it is useful info.

Cageman
10-17-2015, 01:22 PM
Yup, in a way you're just highlighting limitations, in the context of this thread, Cageman, eh!

Yep... and that was "eh" in what way? At least I am _trying_ to showcase some ways of making LW more flexible... despite the limitations.

jeric_synergy
10-17-2015, 01:46 PM
re: referencing: My glancing experience w/referencing was in Blender, and the ability to import an object with defined motions(+lights) that were INSULATED from the main scene seemed pretty useful to me. I could see how in a production setting w/multiple modelers & animators it would give a lot more control to management and prevent inadvertent revisions.

Essentially, each object has a little 'Scene' wrapped around it. Referenced objects are displayed in green and are non-mesh-editable in the calling scene. You have the option of importing the mesh and all its motions and dependencies, at which point it becomes disconnected from the reference file and becomes part of the calling Scene (or whatever Blender calls 'Scenes').

Historical Factoid: The origins of LW, Videoscape, DID have referenced Motion files, but that went away very early, b4 LW I think.

faulknermano
10-17-2015, 02:59 PM
Referencing character meshes for skinning is recommended in the Advanced Skeleton auto rigging tutorials (great plugin btw) and at least a couple of AD training manuals I've read. I need to look further into transferring weights from one mesh to another. Along the way I've tested binding meshes without referencing to compare workflow and as expected the file sizes of the resulting scene are huge, turning from MB to GB. I suspect this is something to do with Maya blend shapes (which appear to duplicate the entire character mesh for each endomorph). Is there a way round this? Otherwise object referencing works fine (though at present animated obj referencing is broken in 2016!).

Ah, a Maya to LW workflow. :) That's cool. I only use Maya to LW methods on personal projects, mainly because the team uses mental ray and V-Ray.

Richard has mentioned deleting blendShapes, which I think, if file sizes are your concern, is the solution. But find a 'blendShape recoverer': a script that will read the deltas on the blendShape node and recreate the shapes. This is the equivalent of LW's morph switching. :)

However, what you described about skinning a non-referenced mesh duplicates blendShapes doesn't sound right. Perhaps you are skinning (inadvertently) the blendshapes meshes, too? If you accidentally skin the blendshapes, not only will the deformations be 'doubled' (obviously), but that each blendshape mesh will be duplicated internally as a reference mesh for the skinCluster's deformation. But you shouldn't get duplicate of blendshapes as long as you skin only your main mesh.

I forced our company to buy AS despite the price, because the toolset is solid, and best of all, it's modifiable. :) But I disagree with Oyvind about reference character meshes, insofar as convincing me to use them, mostly because 1.) mesh changes do not carry over once skinned, and 2.) shape node is suffixed with 'Deformed' causing issues with our cache pipeline. These two reasons are good enough for me to drop referencing for skinned meshes. But different pipelines have their own reasons for using references meshes. My reasons are simply my experience and how I chose to overcome our problems for our particular job field (ie commercials).

In our workflow, the Rig file contains the non-ref model + rig. If the Rig file has become too heavy, too big, or otherwise uncomfortable, then that is dumbed down, and a high-res version is created to be used later. But for me, the Rig file is fine being big, as long as it loads, and as long as there's a way to speed up animation at the viewport (eg visibility, disabling constraints, proxy objects, etc).

We either go for a Caching workflow, or a direct Rig reference. A direct Rig reference is only used when the project is super simple, because the Rig will also contain shaders, so when referenced/imported into the Render scene, it is essentially ready to render.

When using the Caching workflow, which is usually the preferred method, we maintain a separate Model file, which is mesh+shading. This is the main model that will be rendered, and this model topologically matches the one found in the Rig file. If this Model file changes, the Rig must be updated to reflect that, too. This is where the Transfer Weights come in, among other things. If you really wanted to be anal about weight transfer, you can do so in a topologically-identical mesh, by blenshaping the original skinned mesh to the new mesh, then copy weights. This way, the original mesh has the same vertex positions. Also, it would be possible to write a script that uses component ids to transfer weights simply to how we transfer UVs using Transfer Attributes. I wonder if they should have put that in (or that if they have, I don't know about it)?

Anyway, the Rig is referenced into an Anim scene, then animated, then cached out. The Model imported (not referenced, for same reasons as skinning) into a Render scene, the cache is applied.

You may have noticed that I've only referenced once in this whole workflow, which is Rig > Anim. However, we use referencing in other ways: referencing Layout scenes, which contains cameras, referencing mesh models into the Render scene, referencing shaders (sometimes). I tend to keep data flow short, and not have too many nested dependencies.

Second, referencing in Maya doesn't always play well with things like render layers, thus the preference to import meshes rather than referencing them in the Render scene. This is the primary reason why the Cache workflow was better, because it was cleaner.

(Sorry if this is very Maya-centric).

probiner
10-17-2015, 03:02 PM
Yep... and that was "eh" in what way?
"funny attempt, smart arse" way. I've been practicing with "eh!" in the end of argumentative or edgy statements. Apparently it's working more than it should, eh! :D


At least I am _trying_ to showcase some ways of making LW more flexible... despite the limitations.
Indeed, and it's empowering info for users that will have to come up with solutions in LW anyway. I'll do the same soon. Though I have some notion of some aspects that would just make me look somewhere else for specific tasks and workflows. But the positive effect for others remain.

faulknermano
10-17-2015, 03:07 PM
And this is where you can use the copy weights command to your advantage. I find the biggest hurdle to a rigging workflow is iteration. Sometimes it is hard to get rid of history before deformation, sometimes it is bugged and just does not work.

I tend to use Hypershade for things like this; I rarely use Maya's delete history before deformations for the reason you cite above. I tend to go in to the graph, select the node whose deformation I want to delete, un-intermediateObject it, delete its history. Takes a few clicks longer, but it is consistent, and I can keep track of what Maya is actually doing.


Another thing is UV maps and textures. Obvioulsy you try to set up a logical workflow. But as we all know, it is never perfect. And at any time along the way you might realize things need to change. UV map was not done correctly or not working. There is also a transfer attributes function which can be useful. But I find it is much more straight forward to bind and then copy weights.

For me, Transfer Attributes (Tao) when it comes to UVs can be inconsistent is external files were thrown in the mix (eg .lwo converted to .obj, or .obj from other apps): point order issues and resulting wrong UV seams. We overcome that inconsistency by not assuming that the Rig has correct UVs, and that Model file contains that. The only thing that connects the Rig to the Model is the cache (if using a cache workflow).



What I find is the time killer is iterations and changes within one character. These are more of the day to day things I seem to be up against.

Out of curiosity, what is the scope of your iterations?

probiner
10-17-2015, 03:10 PM
Anyway, the Rig is referenced into an Anim scene, then animated, then cached out. The Model imported (not referenced, for same reasons as skinning) into a Render scene, the cache is applied.

You may have noticed that I've only referenced once in this whole workflow, which is Rig > Anim. However, we use referencing in other ways: referencing Layout scenes, which contains cameras, referencing mesh models into the Render scene, referencing shaders (sometimes). I tend

Second, referencing in Maya doesn't always play well with things like render layers, thus the preference to import meshes rather than referencing them in the Render scene. This is the primary reason why the Cache workflow was better, because it was cleaner.

(Sorry if this is very Maya-centric).

I don't recall if this is a problem in XSI with referenced models and partitions (passes). Never done much rendering there, but in terms of management I think render meshes only recieved point caches so all the material work never crossed with the animation work. So I guess it's very similar way you describe in Maya.

faulknermano
10-17-2015, 03:43 PM
So I guess it's very similar way you describe in Maya.

Well, it's similar insofar as it was the workflow we've chosen. But Maya itself will reference complete rigs, or scenes that contains animated referenced rigs. Our cache workflow was intentionally designed, not handed to us by Maya as a default. And I think, to go back to the point of the thread, that's what Maya referencing is about: reference-able containers for (almost) everything, not just a particular type of data so you can pick and choose how you want your data stored/referenced.

To be fair, Maya's render layer is supposed to work with referenced scenes; it's just that there are lots of associated issues when reference edits are combined with render layers (eg shader overrides). So again, I specifically chose to bypass this method for that workflow.

Surrealist.
10-17-2015, 04:29 PM
I tend to use Hypershade for things like this; I rarely use Maya's delete history before deformations for the reason you cite above. I tend to go in to the graph, select the node whose deformation I want to delete, un-intermediateObject it, delete its history. Takes a few clicks longer, but it is consistent, and I can keep track of what Maya is actually doing.

Out of curiosity, what is the scope of your iterations?

Yeah underlying nodes is my weakness in Maya and every time I learn something it is an eye opener. Thanks for the tip. So many things yet to learn... ;) I have a tendency in the heat of production to go with what I know will work absolutely which can be rather brash at times, but it works. I love learning the surgical stuff though.

Iterations, I just mean stuff you find you have to fix that is not working, I mean it is a long list of various things I may have to adjust along the way. On the next character I won't make the same mistakes. But it is part of the process. And the more you can get away with not redoing things the better. Just a general comment about copy weights as a key component to not losing work after having to go back and change something that might interfere with what you have done up to that point.

And it was commented a while ago about rigging in LightWave with hold bones.

That is a LightWave specific thing. I would consider it the most flexible way - in LightWave - to weigh bones currently. I would not call it better. And definitely hands down if there was weight painting in Layout, I would chose that over hold bones any day of the week. Some people hate weights. But I love working with them in Maya. And with a tablet you can keep one setting and just paint away using pressure, shift and ctl to pretty much dial a rig right in.

If the job requires it I will work in LightWave layout to animate or rig. But very often these days I wind up eventually "selling my client up" so to speak and get them to agree to let me work in other apps for rigging and animation.

Seriously, LightWave needs some very drastic changes with regard to rigging and animating.

This new unified geo engine is right on time. Will be interesting to see what they do with it on this side of things.

Cageman
10-17-2015, 04:57 PM
"funny attempt, smart arse" way. I've been practicing with "eh!" in the end of argumentative or edgy statements. Apparently it's working more than it should, eh! :D

Not sure in what way my post was "edgy" or "argumentative". The clear cut is that Maya referencing is leaps and bounds more powerful than LW.

_BUT_

There are ways in LW to make things a little easier...

And not just LW...

We used MOT/ENV files to create a pipeline between Maya/LW/MAX, so that the motion referencing was propagated between these three apps. Change a camera in LW, publish the files; instant (well... on scene reload) update in not just LW, but Max and Maya as well. :)

Change the camera in Maya; publish the files... propagated update in LW/Max as well...

Oh well. :)

probiner
10-17-2015, 05:26 PM
Not sure in what way my post was "edgy" or "argumentative".
Mine, not yours, eh! :D



We used MOT/ENV files to create a pipeline between Maya/LW/MAX, so that the motion referencing was propagated between these three apps. Change a camera in LW, publish the files; instant (well... on scene reload) update in not just LW, but Max and Maya as well. :)

Change the camera in Maya; publish the files... propagated update in LW/Max as well...

Oh well. :)

Yeah but those are in house solutions from people that meddle with a lot of softwares, not the standard :) Like whole workflows revolving around editing the .lws file. Possible of course, but shows the issues with normal handling.

Cheers

faulknermano
10-17-2015, 05:49 PM
That is a LightWave specific thing. I would consider it the most flexible way - in LightWave - to weigh bones currently. I would not call it better. And definitely hands down if there was weight painting in Layout, I would chose that over hold bones any day of the week. Some people hate weights. But I love working with them in Maya. And with a tablet you can keep one setting and just paint away using pressure, shift and ctl to pretty much dial a rig right in.


I see. Coincidentally, I do like the principle of hold bones as a way to minimise weight painting; I use hold joints in Maya. However, that said, more often than not, some weight painting is still needed.

The reason hold bones hold weight (pun intended) for me is due to its procedural-like workflow; when I do a default skin bind (with particular bind settings that I know should work well for the character) I can be reasonably sure that the weighting will be the same as the last time I bound it.

(There are definitely more technically savvy ways of dealing with the issue: I'm fairly certain that it's possible to save skin weights on a vertex id context via scripting, making it much closer to a procedural workflow)

Maya's weight painting has much improved over the past five iterations, so it's a much better system. However, I try to avoid too much detail painting when possible, or when I know the models are still in the state of flux.



Seriously, LightWave needs some very drastic changes with regard to rigging and animating

Yes. That's putting it concisely enough. :D

Surrealist.
10-17-2015, 06:17 PM
Interesting, we have gone in slightly different directions. I am starting to see weigh painting as an art in itself as far as deformation. I see that at one level you can get weights, "correct". No strange odd things happening in the usual places. Then you can go further and get it smoother. And then you can start to play with the painting and say, OK, now that it is working, how about a very slight brush of influence of this bone over this area to simulate skin stretching. And I am sure I am just scratching the surface here. But I guess for me, painting is the most intuitive way to take it to these other levels.

Cageman
10-17-2015, 06:20 PM
Why shouldn't such a thing become a standard? Alembic, PointOven and FBX tries to make things a standard between apps. FBX, being owned by AD though, has become a shity "standard" because with each release, any plugin you wrote for, lets say, outputing MDDs directly from Motionbuilder, has to be recompiled.

There is a huge reason why companies, both in gamedevelopement and film, stick to a certain version of all apps, until it is safe to update; and then all apps need to be updated.

This frenzy is driven by a single company; AD... and it is _insane_.

FBX is a good example:

I can export a camera from LW to Maya; it works nice... pixel perfect.
Same camera exported to Max; 50% chance it doesn't do the same thing.
Export the camera from Maya; works better, but still not exact.
In some rare cases, a camera export from Maya to LW does the same thing... but not as often compared between ADs own products... and they _own_ the FBX format.

I will not even describe the camera workflow from Maya to Modo using FBX....

These are, of course, fringe cases. Funny thing is, our MOT/ENV pipeline solves this, as well as using Point Oven (have not tried Alembic in these fringe cases though).

But, again, Alembic is not AD, and Alembic solves A LOT of problems.

ASCII is a format, and it solves a lot of problems; wether it is hacking the resulting ASCII files or if the software outputs them correctly.

Compared to binary formats, ASCII is quite safe, even if they are slower.

Recently I did something in Maya 2015.... saved the file as a binary .mb file.

This file needed to be opened int Maya 2014, since our tools are centered around that version.

There used to be a checkbox in Maya were you could set "Ignore Version" and you could load older/newer materaial into it. It just "tried" to open a scene, and if no new stuff was in it, it worked.

This checkbox does no longer exist. And... to compare with LW (which offer you to save in an older format), there is no such thing in Maya.

The workaround to solve this was to save the file in Maya.ma (ASCII) then load it into a regular text editor and change the "Required Maya version" to 2014.

Maya 2014 then loaded the file in, as if nothing was a problem, with everything intact (weights was the big thing).

*sigh*

:)

faulknermano
10-17-2015, 08:01 PM
Interesting, we have gone in slightly different directions. I am starting to see weigh painting as an art in itself as far as deformation. I see that at one level you can get weights, "correct". No strange odd things happening in the usual places. Then you can go further and get it smoother. And then you can start to play with the painting and say, OK, now that it is working, how about a very slight brush of influence of this bone over this area to simulate skin stretching. And I am sure I am just scratching the surface here. But I guess for me, painting is the most intuitive way to take it to these other levels.

Definitely agree with that. I'm concerned primarily with proceduralism in rigging, which specifically means the process in which I can get a reliable result every step of the way. In the case of weight painting, I see that as a not-so-procedural method, but that doesn't mean it doesn't have a part in the process; it's just that I prefer to put it at the near-end of the process, something like a 'finishing touch'.

In fact, the thing is more complicated because one has to consider how to deal with other rigging tools. For example: corrective morphs, or perhaps even corrective displacements. How much weight painting do we do before we can decide a corrective morph will do a better job from here on out? Otoh, a corrective morph is associated with blendShapes, and if brought on top of existing blends (eg facial expressions), does that complicate our revision/iteration for the rig? Moreover, a corrective morph will be referencing a target mesh that has been skinned with 'user' weights; how are morphs revised if weights are changed?

Sounds like I'm paranoid, but in practice, however, most things worked out. But when they didn't, was hell. :D

faulknermano
10-17-2015, 08:05 PM
FBX is a good example:


FBX is so messy in and out of any package, I can't use it other than an intermediate; ready to ditch the FBX once I get the data I'm after. Funny, but I haven't actually tried exporting transforms from Maya 2015 using abc. Does that even work, I wonder?

bobakabob
10-18-2015, 03:06 AM
Ah, a Maya to LW workflow. :) That's cool. I only use Maya to LW methods on personal projects, mainly because the team uses mental ray and V-Ray.

Richard has mentioned deleting blendShapes, which I think, if file sizes are your concern, is the solution. But find a 'blendShape recoverer': a script that will read the deltas on the blendShape node and recreate the shapes. This is the equivalent of LW's morph switching. :)

I forced our company to buy AS despite the price, because the toolset is solid, and best of all, it's modifiable. :) But I disagree with Oyvind about reference character meshes, insofar as convincing me to use them, mostly because 1.) mesh changes do not carry over once skinned, and 2.) shape node is suffixed with 'Deformed' causing issues with our cache pipeline. These two reasons are good enough for me to drop referencing for skinned meshes. But different pipelines have their own reasons for using references meshes. My reasons are simply my experience and how I chose to overcome our problems for our particular job field (ie commercials).

In our workflow, the Rig file contains the non-ref model + rig. If the Rig file has become too heavy, too big, or otherwise uncomfortable, then that is dumbed down, and a high-res version is created to be used later. But for me, the Rig file is fine being big, as long as it loads, and as long as there's a way to speed up animation at the viewport (eg visibility, disabling constraints, proxy objects, etc).

We either go for a Caching workflow, or a direct Rig reference. A direct Rig reference is only used when the project is super simple, because the Rig will also contain shaders, so when referenced/imported into the Render scene, it is essentially ready to render.

When using the Caching workflow, which is usually the preferred method, we maintain a separate Model file, which is mesh+shading. This is the main model that will be rendered, and this model topologically matches the one found in the Rig file. If this Model file changes, the Rig must be updated to reflect that, too. This is where the Transfer Weights come in, among other things. If you really wanted to be anal about weight transfer, you can do so in a topologically-identical mesh, by blenshaping the original skinned mesh to the new mesh, then copy weights. This way, the original mesh has the same vertex positions. Also, it would be possible to write a script that uses component ids to transfer weights simply to how we transfer UVs using Transfer Attributes. I wonder if they should have put that in (or that if they have, I don't know about it)?

Anyway, the Rig is referenced into an Anim scene, then animated, then cached out. The Model imported (not referenced, for same reasons as skinning) into a Render scene, the cache is applied.

You may have noticed that I've only referenced once in this whole workflow, which is Rig > Anim. However, we use referencing in other ways: referencing Layout scenes, which contains cameras, referencing mesh models into the Render scene, referencing shaders (sometimes). I tend to keep data flow short, and not have too many nested dependencies.

Second, referencing in Maya doesn't always play well with things like render layers, thus the preference to import meshes rather than referencing them in the Render scene. This is the primary reason why the Cache workflow was better, because it was cleaner.

(Sorry if this is very Maya-centric).

Faulknermano, Surrealist, many thanks for these helpful detailed insights regarding production workflow... The AD forum is nowhere near as good as this one! I'm glad Lino is fine about constructive discussions relating to workflow and what we can learn from other apps.

Regarding referencing models for CA, I'll try out some different approaches as this workflow is broken in Maya 2016 and unfortunately still not fixed with SP4. I'm finding Maya 2014 much more stable.

Faulknermano, good to hear from an Advanced Skeleton user. Richard, if you've not tried it, you really should give it a go. The rigs are robust and flexible and it's very fast to set up. It has especially good hand and finger controls. The facial animation setup defeats me though, (glad I'm not alone on the AS forum) so am just sticking to endomorphs created in Lightwave Modeler before FBX export using the brilliant 3rd Powers LW Brush. Maya 2016 seems to be catching up with a LW-Brush toolset (are they keeping an eye on LW these days?) which appears imported from Mudbox enabling you to sculpt morphs in a more immediate way directly onto the mesh (without going round the houses having to make multiple copies of your character).

Richard, interesting what you say about weight painting and I really hope we have this facility in Layout eventually. I've grown from being terrified of it, to hating it to now enjoying the process and as you say, perceiving it as an art form in itself. By manipulating the rig and testing the deformations whilst painting there's a level of interactivity and immediacy. Also you can be precision perfect and access individual points if you need to.

In my latest project I've also rigged the same model in LW for specific scenes with RHiggit which has made CA in LW enjoyable and intuitive (yet to try Genoma 2 which looks like a big step forward). In Maya playback enables you to edit in realtime and Playblast is very fast but LW 2015 is certainly a sound environment for CA these days and there's immediate access to VPR which you don't get in Maya.

In my workflow I'm mostly exporting the Maya character animation into LW by combining meshes and then geocaching the sequence. It works well and I've found I can apply the cache files onto the original models in LW before they were exported as FBX... Seems point order is perfectly preserved. Glad to say I've not had problems with FBX and geocaching... Maya has all the legacy presets to maintain compatibility. Only once have I tried swapping rigs between apps and, yes "messy" is the right word for it... Never again.

Surrealist.
10-18-2015, 10:55 AM
Thanks for the feedback. Actually I looked at Advanced Skeleton. It has been a while. I am not a bad hand animator. I would say average. I can do it, but I have found that, along with rigging, not to be a great deal of interest to me. So when I do hand animate I prefer an auto rig set up. But presently anyway I don't have a need for such a rig. I use the HIK rig in MotionBuilder which only requires I create a simple deform rig. And the HIK is then just an advanced auto rig with special features. It is not the best thing for stylized animations but for what I do mostly it is perfect.

Then I like the idea of using mocap data as a base for then tweaking with layers and various other editing tricks in MotionBuilder. I kind of look at it like using audio loops to compose music. Grab bits and pieces from here and there and join them together seamlessly and then animate on top. MotionBuilder is designed well for this.

And I find my clients enjoy the fast turnaround and flexibility. There are tons of mocap files available free and for purhcase. And it can take me a few hours to animate a forward motion walk cycle. But unless I am doing real stylized cartoon animation, there is no real need to do this in most cases. Plop a mocap into the scene, retarget, done.

It was mainly the MotionBuilder Maya combo for which I purchased my AD Suite. Coming from XSI, I finally determined I was not going to be doing much hand animation or rigging. And the dynamics tools for characters in Maya were much better than those in XSI - in my opinion. nHair and nCloth have great built in controls for character situations.

So the switch was conscious long before XSI went down for the count.

And even though I do respect it as a monster app, it has dropped away in use for me lately. I have been looking more and more at Houdini Indie.

And of course waiting to see what LightWave has in store.