OK so import anime file is great, I use it all the time, and it's good how you then get a window to select the layer/group you want to import, and get a visual preview of that layer.
But I'm just not that smart and organised, I update my character rigs and so on constantly throughout production, import rigs at various stages of completion, drop keys willy-nilly and then, days before the deadline, find things like the blink action on this character is empty.
What if we could import a reference of an anime file? (It wouldn't have to be a layer, if that makes it any easier?)
So the imported file can be updated externally, I can have the one character file referenced throughout, in every shot or scene file, and can happily add actions to the character which will then be available in every situation.
Is this doable?
Insert Reference
Moderators: Víctor Paredes, Belgarath, slowtiger
Yeah, I'd vote for this feature.
Right now I make sure that all my characters are updated before I begin each show, exactly *because* of this problem. You're absolutely right, it's a big PITA to have to go into a scene and tweak it just because you've updated a character.
This could actually be part of a greater wish list -- some sort of library functionality. Then a scene could simply update from whatever library components are used -- I'd much prefer such a library than even the easy way you can load elements now from anime files.
Right now I make sure that all my characters are updated before I begin each show, exactly *because* of this problem. You're absolutely right, it's a big PITA to have to go into a scene and tweak it just because you've updated a character.
This could actually be part of a greater wish list -- some sort of library functionality. Then a scene could simply update from whatever library components are used -- I'd much prefer such a library than even the easy way you can load elements now from anime files.
Yep absolutely mkelly.
"insert reference" would give you that library functionality,
assuming you could insert a heap of references.
I don't imagine it would be horribly difficult?
It's basically recording an anme file import,
and checking that import, updating it if necessary.
Which makes me wonder - is that achievable currently
with scripting? I'm guessing probably not, as when you
overwrite a refernce in your scene, you'll lose any keys
you put on the reference?
"insert reference" would give you that library functionality,
assuming you could insert a heap of references.
I don't imagine it would be horribly difficult?
It's basically recording an anme file import,
and checking that import, updating it if necessary.
Which makes me wonder - is that achievable currently
with scripting? I'm guessing probably not, as when you
overwrite a refernce in your scene, you'll lose any keys
you put on the reference?
Personally I think creating a linked library system is ALMOST possible with scripting as it is now. All the components are there except for the "open" and "import" feature within the script interface. If those two things can be done via scripting everything else is already in place (Not "easy" but there).
For example, imagine you created keys on a "linked" layer. Now you realize its the "wrong version" of that layer and you want to import a different version but keep the keys. A script could copy all the key values from the current "linked" layer or layers and then import a new one transfer the keys and delete the old one. Those aspects have been done already in scripts. Now of course point motion keys would be a different story. If you keyed points and wanted to replace that with another file and the points are different even in a small tiny way this won't work. Changed vectors and shapes that aren't animated would come in fine... but the animation should be limited to bones and layers. I just don't see how it could ever be possible to update files when the points have changed (deleted or added. Moved is no problem.)
It wouldn't be the kind of script written overnight or even a few days when you are bored... but it could still be done. Without the ability to "import" or "open" an AS file via the script interface it would be very very hard to do... not impossible... but really really hard.
It could be done without the "import" feature in the script interface by opening the "linked" AS file as a "text" file. Then doing whatever needs to be done to the "text" of this file (very difficult) to update that file with new keys from the existing layer etc etc... and then Inserting that new layer text into the right spot in the currently open file text format and saving a new AS file in a new location. You would then have to open the new file... pain in the arse.
By adding in "open AS file" and "Import AS object" into the script interface most of that nightmare could be eliminated... unless of course you want the key frame interpolations... which is not accessible without reading the file format <sigh>.
-vern
For example, imagine you created keys on a "linked" layer. Now you realize its the "wrong version" of that layer and you want to import a different version but keep the keys. A script could copy all the key values from the current "linked" layer or layers and then import a new one transfer the keys and delete the old one. Those aspects have been done already in scripts. Now of course point motion keys would be a different story. If you keyed points and wanted to replace that with another file and the points are different even in a small tiny way this won't work. Changed vectors and shapes that aren't animated would come in fine... but the animation should be limited to bones and layers. I just don't see how it could ever be possible to update files when the points have changed (deleted or added. Moved is no problem.)
It wouldn't be the kind of script written overnight or even a few days when you are bored... but it could still be done. Without the ability to "import" or "open" an AS file via the script interface it would be very very hard to do... not impossible... but really really hard.
It could be done without the "import" feature in the script interface by opening the "linked" AS file as a "text" file. Then doing whatever needs to be done to the "text" of this file (very difficult) to update that file with new keys from the existing layer etc etc... and then Inserting that new layer text into the right spot in the currently open file text format and saving a new AS file in a new location. You would then have to open the new file... pain in the arse.
By adding in "open AS file" and "Import AS object" into the script interface most of that nightmare could be eliminated... unless of course you want the key frame interpolations... which is not accessible without reading the file format <sigh>.
-vern
Hmmmmmm.... pop!
I think I just had an embolism.
Thanks Vern
good to know what the limitations are,
even if they are unfortunate.
I wonder - what if you insert a reference
and AS keeps that as an external file somehow.
Could you update that external text file
as it is altered in the scene file you have open?
So when you close your scene file, the referenced
file has been updated already.
(Intermittently, perhaps as any changes are made to it.)
I think I just had an embolism.
Thanks Vern
good to know what the limitations are,
even if they are unfortunate.
I wonder - what if you insert a reference
and AS keeps that as an external file somehow.
Could you update that external text file
as it is altered in the scene file you have open?
So when you close your scene file, the referenced
file has been updated already.
(Intermittently, perhaps as any changes are made to it.)
Yes, exactly. I have the whole process in my head. The only trouble is that AS needs a way to store "linked file" info inside the file format. Without that it would be a real pain. Linked file info would need to be stored in some kind of text file the way it is now. Plus there is no "open file" or "import layer" script access so... ick... have to parse the actual file format.madrobot wrote:I wonder - what if you insert a reference
and AS keeps that as an external file somehow.
Could you update that external text file
as it is altered in the scene file you have open?
So when you close your scene file, the referenced
file has been updated already.
The way I see it working is quite "simple" in relative terms.
The linked file is a layer or group layers etc. That layer in the file that uses it would have a path to the linked file. Each time the file is opened it just reads in that layer and replaces the old one in the file.
If the layer that is linked is edited in the file with a reference to it then when the file is saved it just saves out that layer as a file and replaces the linked file. The "linked" file would not to have any info stored in it although that could be an option I suppose. You could check to see a list of files it is linked to... no really it makes sense... in my head.
-vern
Hey guys! Before start to write any code line consider this potential troubles:
1) Files with different frame rates.
2) If you are able to edit a referenced external file and pretend that the changes were saved into the referenced file it can cause problems if someone else is editing the file at the same time. Referenced files should be edited in its own context.
3) Camera issue. A file defines a camera (a 3D camera maybe). How would you dare with a referenced file with a different camera settings that the importer one?
I think that the real feature should be reference libraries (layers) independent of document definition (frame rate, camera, render size, etc, etc.).
Even referencing only layers there should be a way of adjust the reference system of the layer to the importer document without modifying the imported file. That needs some sort of store data: origin, rotation, scale, etc. of the referenced objects.
Also what it would be awesome is a way to reference styles. Some sort of independent Style definition that can be referenced by any external file. Change the style and all the files that references it, changes.
-G
1) Files with different frame rates.
2) If you are able to edit a referenced external file and pretend that the changes were saved into the referenced file it can cause problems if someone else is editing the file at the same time. Referenced files should be edited in its own context.
3) Camera issue. A file defines a camera (a 3D camera maybe). How would you dare with a referenced file with a different camera settings that the importer one?
I think that the real feature should be reference libraries (layers) independent of document definition (frame rate, camera, render size, etc, etc.).
Even referencing only layers there should be a way of adjust the reference system of the layer to the importer document without modifying the imported file. That needs some sort of store data: origin, rotation, scale, etc. of the referenced objects.
Also what it would be awesome is a way to reference styles. Some sort of independent Style definition that can be referenced by any external file. Change the style and all the files that references it, changes.
-G
Yes, I agree with most of what Genete brought up. That is how I saw it working actually. The "library" files would be "stand alone" files. They would just be "layers". You are right about updating linked files. That could be problematic with multiple uses of the same source file.
The best bet would be using my save bone animation scripts for that. You could have the linked files with just the vector layers etc. Any animation for that linked file would be saved out in another file.
As for camera movements... hmm... I don't see the problem unless you are doing some funky rotations of the camera. If so then the whole project has to be planned ahead of time to use the same camera setup. You can only have "one" camera set up per file anyway.
Or are you talking about the project resolution? Yes, that would be an issue due to stroke widths changing size etc. My thought would be to "scale" those things to match the destination file.
Scaling to match the destination file could work the same with frame rates as well. If you brought it in a source file with a different frame rate it would be possible to scale the keys or animation to match the frame rate very easily (remember we would have to parse the file format to get interpolation types so "scaling" the key frame locations is a piece of cake.)
I've done this before using a text editor and a special mathematical regex search and replace to "scale" the FPS of keys on Papagayo files. This same formula can be applied to the import script for linked assets. If the frame rate of the imported linked file is different from the destination just scale it to match. It's only math after all.
-vern
The best bet would be using my save bone animation scripts for that. You could have the linked files with just the vector layers etc. Any animation for that linked file would be saved out in another file.
As for camera movements... hmm... I don't see the problem unless you are doing some funky rotations of the camera. If so then the whole project has to be planned ahead of time to use the same camera setup. You can only have "one" camera set up per file anyway.
Or are you talking about the project resolution? Yes, that would be an issue due to stroke widths changing size etc. My thought would be to "scale" those things to match the destination file.
Scaling to match the destination file could work the same with frame rates as well. If you brought it in a source file with a different frame rate it would be possible to scale the keys or animation to match the frame rate very easily (remember we would have to parse the file format to get interpolation types so "scaling" the key frame locations is a piece of cake.)
I've done this before using a text editor and a special mathematical regex search and replace to "scale" the FPS of keys on Papagayo files. This same formula can be applied to the import script for linked assets. If the frame rate of the imported linked file is different from the destination just scale it to match. It's only math after all.
-vern
OK, but remember that you only can rescale properly between compatible fps values: ie from 12 tp 24 fps or from 15 to 30. But if the main document is at 25 fps and the referenced file is at 24 fps, uhg! you're in troubles!I've done this before using a text editor and a special mathematical regex search and replace to "scale" the FPS of keys on Papagayo files. This same formula can be applied to the import script for linked assets. If the frame rate of the imported linked file is different from the destination just scale it to match. It's only math after all.
-G
Hmm... that's only about a 1% difference. You could still scale it up but leaving it as is would barely be a noticeable difference. Besides why would you have a linked asset with keys different from the main project? Unless these are "open" library action files.Genete wrote: But if the main document is at 25 fps and the referenced file is at 24 fps, uhg! you're in troubles!
-G
Beyond frame 24 the scale value is more than a whole frame. The trick then would be to decide when and where to move the keys ahead one frame. I don't see this as a problem unless you have keys on every single frame.
For example going from 24 fps to 25 fps a key on frame 5 would be frame "5.2". I don't think leaving it at frame 5 would make much visual difference.
It is a shame that AS doesn't have "sub frame" key values. Like "frame 5.2" or whatever. It might actually be possible to scale the key VALUE for fractional frames like that. If the key needs to move forward 0.2 then scale the value of the key by that amount and leave it where it is... kind of scary though.
-vern