Hey guys,
I’m writing a facial expression management script that uses a bone setup, and allows you to store expressions and creates sliders so you can use them just like morph targets.
I’m currently storing expression data (positions of ctrl’s) in ini files, looking like this:
[Smile]
Mouth-01=[0,0,10.9886]
Mouth-02=[0,0,0]
Mouth-03=[0,0,2.70022]
Mouth-04=[0,0,4.69391]
Mouth-05=[0,0,3.17475]
Mouth-06=[0,0,0]
Mouth-07=[0,0,5.02291]
Mouth-08=[0,0,13.2973]
what’s the best way to store this kind of stuff within a scenefile?
Well, “best” is difficult to define
Here are some of the possible ways to store data, pick the one that suits you best:
*You can create a stand-in node in the scene or use the one that has the morpher applied to it and store the data in its User Properties
*You can create a stand-in object in the scene or use ANY existing object, including the scene node or even the Morpher modifier itself to store the data as AppData.
In both cases, merging the objects containing the data between files would move the data into the target scene.
*Persistent globals – these are tricky and usually difficult to handle, but I admit I am using them alot. The trouble is that there is not much control over persistent globals, and they tend to stick after a new scene has been loaded, I think they even come over if you try using the file>merge…
Overall a bad idea compared to the other methods.
A nice mixture would be to store the data in INI files locally or on the network (so multiple people can access it) and store just a pointer to that file in one of the above methods. This makes the data external (and other people can fix/change/enhance it) but the MAX scene “knows” where to search for it and loads the content when needed…
It really depends on whether you are developing a studio-wide tool or an application only you will use, whether you want to move data between files and so on. All methods have their drawbacks, for example if you would write AppData to the Morpher and then deleted the modifier, the data would be gone, whereas if the data was in a special “data container” scene node, the data would persist even after the modifier is deleted and adding a new morpher modifier would be able to access the existing settings…
Don’t expect me to pick the best for you, I cannot
Yoho Bobo.
Do you have any tips on how to save data in a scene that can handle undo?
So that the undo will go back to the old state of a variable.
Example:
a ball is created
variable_ball=ball_is_created
then Undo so there is no ball anymore
variable_ball is now reset to the old value?
I’be been thinking about perhaps saving the data in geometry, even materials in some way so that I can access the old ones if undo has been done. It could also be possible to do some history and with an undo even check the old values, but this sound limiting.
/Andreas
I can add a couple more ways that I’ve gotten from a couple other pros in the industry.
From Paul Neale: Use a string parameter within a scripted custom attribute to store an array of poses. And then get them back using the ‘execute’ command. Check out his attribute holder script for an example of this. http://paulneale.com/
I’ve been using this myself and it works really good. I can use the same data to save an arm pose, for example, on one side of the character and then mirror paste it to the other side.
From Chris Harvey: Chris is big on using multiple position and rotation controllers to store poses. Collections of poses can be stored within individual list controllers. You change poses by changing the weighting of the controller. The upside to this is that you can easily blend poses together by having multiple controllers with weighting greater than zero. Check out this thread: http://www.cgtalk.com/showthread.php?t=170634&page=1&pp=15
This method is interesting, but I haven’t tried it myself.
The upside to both of these is, like Bobo pointed out in one of his method’s, the data travels with the rig since all the info is embedded either in one the bones themselves, using Chris’ method, or one of the main helper object’s on the rig, using Paul’s method.
Personally, I don’t like to use .ini files because it’s an extra file to keep track of. I like to keep things as clean and simple as possilbe. But I can see the benefit to a team as Bobo pointed out. Although, you should also be able to script some kind of merge pose function to grab poses from another scene using any of these methods that keep the info inside the scene file. In fact, I think I’ll try adding that function to the scripted character rig creator I’m working on for Gas Powered Games. Thanks for the idea!