View Full Version : New RIG file features not here yet.

03-14-2019, 02:48 AM
According to the docs, saving a RIG with it's motion modifiers is coming soon.
Wonder when. Wish it was in 2019.
I've tried using replace item with... in order to save all the tasks already completed in designing a rig when a model has been modified.
But then the references in motion options are all lost. Even if the model has the same name.
So it's neccesary to do the mods on the same model that's being rigged.
Just save a backup in case the model gets messed up.
Rigging is so tedious it would really be great to be able to save every aspect of it.
At least 2019 supports all the legacy rigging tools.
Wouldn't want to loose all my current toys for any kind of new features imaginable.
Been working on this model in 2015. Getting the front suspension to work right took many hours.
Fun, but I wouldn't want to have to do it again.



03-14-2019, 08:22 AM
While you can get at target/pole, Same as Item Translation/Rotation/Scale, IK settings, and (i believe) expressions via scripting, some of the other motion modifiers (follower, Simple Constraints, Effectors, etc.) are actual plugins whose interfaces may not be accessible via scripting or the SDK. It's why RHiggit2 has to load things in from a file that has certain things already connected, like the simple position and orient constraints, which have no programmatic interface.

A suggestion would be to replace the model with a null called "Replace with mesh", and save the rig as a scene. With a new model, load your old rig from that scene, and edit it as needed on the new model. At the very least, you connections are preserved.

03-14-2019, 08:32 AM
But then the references in motion options are all lost. Even if the model has the same name.

Shouldn't be, unless you mean in motion plugins and the like.

Either way... I'm guessing that what you've done is to have separate modelled bits, which you are rigging directly. That's a mistake... use bones and weight (or parent) the mesh parts to them.

03-14-2019, 10:36 AM
I haven't been using scripting to create or preserve the motions.
Just putting expressions in the expression editor from the motion options panel.
In there I'm using 'bracket' expressions to refer to the bones.
Like sin(rad([E_Rail.LR_SwingArm.Rotation.P]) * 0.5125) for example to get the Z Scale
value for the suspension spring.
This works great. But, of course, if I make a mod on the E_Rail and use replace item
the expressions are still there, but don't work.
That's the mistake. If I just let the scene load the object that it has already referenced its all OK.

Don't remember exactly why I tried that. I was trying avoid loosing the model prior to changes.

It's all weight mapped, and anything I need to add to the control of some bone, I just add to that bone's weight map.
No problem. There are just a lot of expressions with calculations needed to synchronise the upper and lower suspension arms,
and the drive sections as well as the angles on the shock absorbers and length of the springs.

The front wheels are steered by the steering wheel as well so it needs to be done with expressions.
You can only have one bone referenced for Same as Item, and the front drive sections need to reference two.

None of that can be saved with a RIG file so the current function of those files is insufficient.
Susposed to be upgraded but hasn't been in 2019 so far. Disappointing.

So what I do is just save my expressions on a notepad page and plug them back in when re-using the RIG.

Next I will add steering linkage parts. It's going to have electric power steering.
Bones will be added, weight maps will be added along with the geometry.
Been through this all before.

This Nuclear/Steam powered motorcycle was developed that way.
You don't see them in these sample renders, but it has guns.
A turret gun on the back, and barbette guns in the tank section.
All rigged. Everything works.


03-14-2019, 11:18 AM
In which case just add a null that all bones belong to, and use "use bones from" on the mesh... that way the parent object of the bones never needs to change.

03-16-2019, 09:22 AM
Well, that sounded good so I gave it a try.
Add the null, reparent the root of the bone heirarchy (Frame) to the null and clear the model.
Change the name of the model in the expressions to the name of the null.
Like [E-Rail.LFSuspUpper.Rotation.P] to [RailSubNull.LFSuspUpper.Rotation.P]
Test the expression. Tests Good
Load an alternative model and set 'use bones from' to RailSubNull.
Alternative model has all the same weight maps.
Everything is still there, unlike importing a RIG (which doesn't even save position and scale limits).
But just like before (using Replace with) the expressions don't work.
Test OK, just don't work. Weird...

But all that is a senseless exercise.
I should just do the right thing and use a Scene as a rigged model.
Need the model other scenes, load from scene 'E-Rail_Rigged.lws'
Never found another way that will fully work.

The only major option I would want for this model is big fat beach tires.
It has trail tires on it now. But that can be an endomorph.
Only need to make the wheels wider and shuffle around the tread some so it's paddle like.
Can do that with all the same points.

03-16-2019, 09:32 AM
You're still replacing the actual bone parent though... dont. Just have the bones under a null that you never change, and you can replace the mesh(es) linked to the bones anywhich way you want.

03-16-2019, 10:08 AM
That's just what I did. And just what I said.
Leave the root of the rig parented to the model, clear the model from the scene, bye bye bones!
Of course the rig has to be parented to the null. How else can it be 'under'. Place the null Y:1 m above the rig? Change the parent of 'Frame' to none?
Then say 'Use bones from 'NONE' ?? That would work??
So the null 'ERailSubNull' is a holder for the rig, and that works just fine, EXCEPT THAT the expressions some how fail. Anyway I've tried it.

03-16-2019, 11:41 AM
Well then I have no idea what you're not getting, but if you dont replace the item referenced in the expression... it wont mess with the expression.

03-16-2019, 12:35 PM
Well there you go. That's why the rig shouldn't be used with any other item.
Be it a model or a null, when there are plug-ins used as motion modifiers.

Haven't you noticed the warning Layout gives when you change the parent of the root node of the rig?

If it were the very basic kind of character rig you are used to, exporting and importing a RIG file would do the trick.

Anyway, it actually IS possible to save a rig with script.
Everything needed is available in the SDK so it's surprising that someone hasn't made a plug-in.
I think I might write a script if this comes up again.
Probably build an XML file with all the rig info.
Only I think the motion modifiers will have to be added manually.
Don't see a command for adding those, but that's what is supposed to be coming soon.

03-16-2019, 12:50 PM
it actually IS possible to save a rig with script... it's surprising that someone hasn't made a plug-in.

Because there's no point... if you want a whole ready made rig with all expressions, motion modifiers and everything else... that's basically just a scene file.

03-16-2019, 04:30 PM
Because there's no point... if you want a whole ready made rig with all expressions, motion modifiers and everything else... that's basically just a scene file.

What if you need to bring in more than one?

03-16-2019, 04:44 PM
Rename things.

03-17-2019, 04:50 PM
Well, I've been playing with this more and think I have an idea what's happening.
Could be the expressions get interpreted and saved that way.
So they then have the ID's of the objects saved (instead of the names) and don't want to give that up, even if the expression is changed.
This would be good for performance because the expression would not have to be reinterpreted every time the object moves, or every frame, or whatever.

'Cause if I just remove the expressions, save the scene, then open it again and put in new expressions, at last they work.

And kudos to the electron wrangler.
Why? Here's an example:
Take the Hydra motorcycle. Suppose I make another design with a different engine and no guns.
Then all the geometry and weight maps for the guns is gone and those bones might not exist.
Anyway if that's where I started, they wouldn't exist.
Then I would have this nice XML file that only describes a rig without the weaponry.
(BTW XML is ideal because it has a heirarchal structure just like rigs do. Plus there are lots of XML parsing functions available.)

So, then I have other models with maybe different engines and now some guns so there are additional weight maps, geometry and more bones needed.
I can then make more XML files that describe more bones and those can be added to these more complex models.

No problem. It's OK to add bones to a rig any time you need them.

And yet, once fully rigged and tested, a Scene file is the LW way of saving a rigged object.
And that's what I do.

What I wonder about is when you add many rigged objects by using 'Load from Scene' which, of course is what you have to do.
Then because those objects were the only thing in each of the Scenes, they would have ID's unique to each Scene.
So when they all appear in the same Scene, couldn't there be a conflict of ID's, and how does Layout resolve this?
Are the expressions, once again, going to be broken?
There's another thing I've got to test.

03-31-2019, 12:29 PM
Well I found the solution to this problem.
Use the Graph Editor to apply expressions instead of the motion modifier plug-in.
When loading the rigged object from a scene the Graph Editor expressions remain with the object.
Not what I expected.
And even in the new scene, when using 'replace with' to change the object to one that has been modified, the expressions continue to work, unless the bone is no longer in the model.
When making new midi files to use with my Player Piano some functions using expressions in the Graph Editor continued to work when the Piano was loaded from the original scene.
I did this because I wanted to save the scene with the new song and continue development of an animation that way.
The piano has the string dampers all rigged so that each one rises with each associated key, and they all rise when the sustain pedal is pressed.
It was a revelation that all those expressions remained with the piano.
I had saved them all in a .exp file expecting to need to reload them.
So with this happy news, I went back and moved all the expressions in the E-Rail model to the Graph Editor.
Goodbye plug-in.
And a relief because the E-Rail steering geometry had been added and set up with 4 new skelegons to add to the original rig. (all old skelegons were removed after saving to their own .lwo file)
Copy and paste expressions from the plug-in to the Graph editor.
Apply where needed and remove the motion modifier expression plug-ins.
Save to scene.
New scene, load from scene, and replace with new model.
Everything still works. YEAY!
Convert skelegons, set-up limits and motions and add new expressions to the graph editor.

04-17-2019, 08:42 AM
It's been well worth testing possible issues with rigged objects, and loading multiple items 'from scene'.
One thing that might seem reasonable to do is not.
That is, loading more than one of any object.
The documentation says to duplicate the objects with different names to use more than one in a scene.
Makes sense when you think about it because objects are included by reference.
Instancing can work for some purposes, but if items are going to be animated independantly they must be seperate items.
And loading several items from other scenes can result in conflicts.
In testing, it's been possible to crash Layout with as few as 7 seperate items.
Other problems have turned up.
Using the transforms in 'Same As' controllers is not reliable.
And the functions of 'x' and '+' are too limited for many relationships.
As stated before, expressions are particularly vulnerable.
But they make it possible to define relationships that can't be done any other way.
And, it's safest to write them in the graph editor, from where a complete set for any object can be saved in a library.
But reloading the library does not re-establish the assignments to channels.
So to address all these issues, for one, I have adapted my setup methods to avoid the problems.
And also, written scripts to perserve the rig setup in an xml file, restore the setups to an object loaded from file, and reconnect the expressions to the channels.
I'll discuss this further in the Python development thread and upload examples of the scripts.

04-17-2019, 09:09 AM
Wouldn't it be better for Layout to treat each classic scene as a .RIG and define a new level for .LWS scenes in order to combine externally defined rigs? It might solve a lot of issues.

04-17-2019, 07:32 PM
lw should use a system like unity


04-18-2019, 06:50 AM
Wouldn't it be better for Layout to treat each classic scene as a .RIG and define a new level for .LWS scenes in order to combine externally defined rigs? It might solve a lot of issues.

I smell a feature request...

We would do well with an option to import a rig from an external LWS with a more evolved "load from scene" operation.

04-18-2019, 02:54 PM
It seems to me like it should be possible to complete a rig in modeler.
Modeler goes part of the way but stops short of a complete setup.
There is a strange division happening.
Don't know exactly how to say it.
Of course rigging is closely connected to animation but it seems in LW that it is bound in the wrong place.
For an object to be complete in itself and independent, so that it can be used anywhere, and any way, it makes no sense for it to retain any kind of reference to other animation components of a scene.
It's great that there are so many tools to apply to a rigged object, so that it interacts with all possible aspects of animation.
But those tools establish relationships unique to a particular scene.
I can't see having such assets as part of the object itself.
And if classics scenes are all redefined as rigs, what happens to countless animations that had been made, prior to the redefinition.
Maybe that is just confusing me. The perspective there is hard to see.
There is not a big step from where modeler takes rigging, to where a finalized setup goes.
What is needed?
The ability to set rest position and pivot transform/rest.
The ability to be able to parent in place.
The ability to set limits.
The ability to establish motion relationships between internal components (bones).

Well, it is what it is.
I've been using Modeler/Layout since 9.2 and don't expect much in the way of change.
It's been, what, 9 or 10 years? Not waiting in vain.
I've worked it out. Gotten rid of the tedium that ruins my creative spirit during animation.
Scripting is fun too, in the right state of mind. And solving problems is gratifying.
It's just a part of the LW environment. Python is cool, it's easy to get into.
Worth the effort so that the more artistic part of the process flows well.

04-25-2019, 09:56 AM
This set of objects was created in Modeler, a long time ago.
They were never rigged for Layout because they were used elsewhere.
Using my new tools made this a breeze.
Four of the items are cymbals on stands.
The rigging is identical for all four of them, the only difference in the geometry is the cymbals.
Stands are all the same.
If you have never set up a drum kit, figuring out how to set up a rig for cymbal stands could be perplexing.
Just deciding how each part should work, even with experience, isn't easy.
And, as usual, it's tedious.
Repeating the task four times would be daunting.
Finally, each part of the kit gets it's own Scene, to perserve the rig.
There are plenty of parts for this kit so using multiples is unlikely, but that would also be simple.

04-29-2019, 12:49 PM
I smell a feature request...

We would do well with an option to import a rig from an external LWS with a more evolved "load from scene" operation.
How about a live link that updates the rig as soon as the .RIG file is updated?