Chan file camera animation importer and exporter. #28368

New Issue

Michael Krupa · 2011-08-25T17:34:06+02:00

Michael Krupa commented

2011-08-25 17:34:06 +02:00

Project: Blender Extensions
Tracker: Py Scripts Release
Blender: 2.64
Python: 3.2
Script name: Chan camera import/export
Wiki page: to do
Author(s): Michal Krupa
Category: Import Export
SVN Download: https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/io_anim_nuke_chan/
Status: Open

%%%The scripts can parse or create the *.chan files, commonly used to transfer camera animation between softwares.

To make it work select the camera (or any other object that you want to export and select the menu item (file->export ->Nuke(.chan) ).

A couple of things to be remembered:

mind the rotation order. If you're exporting chan from nuke with the rotation order ZXY, while importing it you have to keep it exactly the sam in Blender
the render resolution in blender must be the same as the resolution of tracked image or scene settings in nuke (only then you'll get the proper lens on camera).
%%%

**Project**: Blender Extensions **Tracker**: Py Scripts Release **Blender**: 2.64 **Python**: 3.2 **Script name**: Chan camera import/export **Wiki page**: to do **Author(s)**: Michal Krupa **Category**: Import Export **SVN Download**: https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/io_anim_nuke_chan/ **Status**: Open %%%The scripts can parse or create the *.chan files, commonly used to transfer camera animation between softwares. To make it work select the camera (or any other object that you want to export and select the menu item (file->export ->Nuke(.chan) ). A couple of things to be remembered: - mind the rotation order. If you're exporting chan from nuke with the rotation order ZXY, while importing it you have to keep it exactly the sam in Blender - the render resolution in blender must be the same as the resolution of tracked image or scene settings in nuke (only then you'll get the proper lens on camera). %%%

Michael Krupa commented

2011-08-25 17:34:06 +02:00

Changed status to: 'Open'

Nobody commented

2011-08-25 17:34:06 +02:00

This task was automatically closed as archived as part of migration, because it was determined to be no longer active.

The authoritative list of addons is on the wiki, we no longer have a report for each addon to track bugs and updates. Bugs can be reported individually and assigned to the addon developers. See the #Addons project page for more information on the workflow.

This task was automatically closed as archived as part of migration, because it was determined to be no longer active. The authoritative list of addons is on the wiki, we no longer have a report for each addon to track bugs and updates. Bugs can be reported individually and assigned to the addon developers. See the #Addons project page for more information on the workflow.

Nobody commented

2011-08-25 17:34:06 +02:00

Changed status from 'Open' to: 'Archived'

Nobody closed this issue

2011-08-25 17:34:06 +02:00

Brendon Murphy commented

2011-09-06 01:06:34 +02:00

%%%Hi,
Just a Reminder for people to Join the Mail List.
If you have not already, please visit this page:
http://lists.blender.org/mailman/listinfo/bf-extensions-cvs
& join the list.%%%

%%%Hi, Just a Reminder for people to Join the Mail List. If you have not already, please visit this page: http://lists.blender.org/mailman/listinfo/bf-extensions-cvs & join the list.%%%

Michael Fox commented

2011-09-22 03:30:09 +02:00

%%%This is an extreamly usful script and is an absolute must have for the vfx pipline, will test then give my absolute approval%%%

Brendon Murphy commented

2011-09-22 10:48:57 +02:00

%%%tagged for sontrib, assingned to michael fox until script reashes contrib, or trunk.%%%

Bartek Skorupa commented

2011-10-26 14:12:58 +02:00

%%%This kind of scripts open Blender to professional post-production pipeline.
I have unfortunately no way to test it in action, as I don't have Nuke, but I'd like to draw everybody's attention to every contribution that makes the communication between Blender and big compositing players like Nuke possible.
The code itself needs clean up in my opinion, but I can see a very big potential here.
Creating a wiki page would certainly help this add on to become official.
I think we should do our best to help the author, as he started to create a tool that may certainly make Blender be perceived as THE PRO app.%%%

%%%This kind of scripts open Blender to professional post-production pipeline. I have unfortunately no way to test it in action, as I don't have Nuke, but I'd like to draw everybody's attention to every contribution that makes the communication between Blender and big compositing players like Nuke possible. The code itself needs clean up in my opinion, but I can see a very big potential here. Creating a wiki page would certainly help this add on to become official. I think we should do our best to help the author, as he started to create a tool that may certainly make Blender be perceived as THE PRO app.%%%

Michael Krupa commented

2011-11-07 12:37:06 +01:00

%%%Well according to your wish - the wiki page is up :)
http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/Import-Export/Nuke

(I just hope I've made it right)
%%%

%%%Well according to your wish - the wiki page is up :) http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/Import-Export/Nuke (I just hope I've made it right) %%%

Michael Krupa commented

2011-11-17 10:57:29 +01:00

%%%Ok. I've made some code-cleaning etc (it's pep8 compilant now)%%%

Campbell Barton commented

2011-11-30 00:06:01 +01:00

%%%Hi Michael, nice script, reviewed and suggested some changes.

here:
http://projects.blender.org/tracker/?func=detail&aid=28368&group_id=153&atid=467

Overall though I think this is fine to be committed, I've granted you extension write access which uses the same name and password as here.

Also mailed you an invite to our committer mailing list.

Could you add your addon to this path please:
https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons

This will then be included as a testing script with graphicall builds, and we can check its ok to be bundled for release.
%%%

%%%Hi Michael, nice script, reviewed and suggested some changes. here: http://projects.blender.org/tracker/?func=detail&aid=28368&group_id=153&atid=467 Overall though I think this is fine to be committed, I've granted you extension write access which uses the same name and password as here. Also mailed you an invite to our committer mailing list. Could you add your addon to this path please: https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons This will then be included as a testing script with graphicall builds, and we can check its ok to be bundled for release. %%%

Ejner Fergo commented

2011-12-06 16:13:55 +01:00

%%%Thanks to Michael Krupa for submitting this script, since I never got around to do it with my own version.

I see that this have been added to the official addons, great! Except has anybody tested it? I just did, and it still doesn't export/import the camera correctly (focal length). The method of using the resolution is a bad one, since we now have 'angle_y' directly. The reason I have pushed for the updates to the camera is exactly because of this. Checking for 'sensor_fit' is also not needed.

I made the necessary changes to the script, and have tested both export/import in Nuke and it works correctly. I have also added a way to input sensor dimensions in the import dialog, but have not figured out how to use the camera presets here yet. I am also willing to edit the wiki (including steps to do in Nuke) as soon as I get a "Go".%%%

%%%Thanks to Michael Krupa for submitting this script, since I never got around to do it with my own version. I see that this have been added to the official addons, great! Except has anybody tested it? I just did, and it still doesn't export/import the camera correctly (focal length). The method of using the resolution is a bad one, since we now have 'angle_y' directly. The reason I have pushed for the updates to the camera is exactly because of this. Checking for 'sensor_fit' is also not needed. I made the necessary changes to the script, and have tested both export/import in Nuke and it works correctly. I have also added a way to input sensor dimensions in the import dialog, but have not figured out how to use the camera presets here yet. I am also willing to edit the wiki (including steps to do in Nuke) as soon as I get a "Go".%%%

Michael Krupa commented

2011-12-06 16:37:46 +01:00

%%%I guess we've had the same idea in the same time. I was making this tool with 2.6 at first, now it's updated to use the camera sensor size but I've found that it still has some issues. If your solution is tested then I'll be happy to see it working properly :)%%%

Ejner Fergo commented

2011-12-06 17:26:20 +01:00

%%%Hi Michael,

Yeah I was a little lazy submitting my patch, since I made it around 2.56 (needed the sensor patch) and the camera is only officially updated in 2.61. Though primitive (still a python noob) my script worked and I used it in production, but technically your script is better IMO.

I hope you get a chance to test my changes, but I can verify that it works. You need to set the aperture sizes in Nuke before importing a chan (as always) to get the correct focal length. That's also why i added the sensor sizes to the import dialog in Blender, so the correct focal length is set.%%%

%%%Hi Michael, Yeah I was a little lazy submitting my patch, since I made it around 2.56 (needed the sensor patch) and the camera is only officially updated in 2.61. Though primitive (still a python noob) my script worked and I used it in production, but technically your script is better IMO. I hope you get a chance to test my changes, but I can verify that it works. You need to set the aperture sizes in Nuke before importing a chan (as always) to get the correct focal length. That's also why i added the sensor sizes to the import dialog in Blender, so the correct focal length is set.%%%

Michael Krupa commented

2011-12-07 15:09:12 +01:00

%%%Hi - I've made some tweaking with the code and I've found the source of all evil in my script. I must confess that I've used it for camera transfer from nuke once or twice, I'm using chan files mainly to transfer animations to and from Houdini, which just like Blender before 2.61 uses only the vertical fit of camera, so the lens calculation method based on a resolution ratio will work good there (tested here: http://vimeo.com/25025328 <- I've made previz for this project in Blender, moved camera and some basic animations to Houdini and continued the project there).
Enjer - could you double check the current version? I've tried importing the tracked camera from Nuke to Blender, export camera from Blender and import it to Nuke, export from and import to Blender, all worked well as long as I've pasted the proper sensor sizes.
%%%

%%%Hi - I've made some tweaking with the code and I've found the source of all evil in my script. I must confess that I've used it for camera transfer from nuke once or twice, I'm using chan files mainly to transfer animations to and from Houdini, which just like Blender before 2.61 uses only the vertical fit of camera, so the lens calculation method based on a resolution ratio will work good there (tested here: http://vimeo.com/25025328 <- I've made previz for this project in Blender, moved camera and some basic animations to Houdini and continued the project there). Enjer - could you double check the current version? I've tried importing the tracked camera from Nuke to Blender, export camera from Blender and import it to Nuke, export from and import to Blender, all worked well as long as I've pasted the proper sensor sizes. %%%

Ejner Fergo commented

2011-12-08 05:58:16 +01:00

%%%Hi again,
Have you looked at my attached files? Why do you calculate the vfov on export, and the lens on import? We have the necessary data now (data.angle_y) so these calculations are not needed.
%%%

%%%Hi again, Have you looked at my attached files? Why do you calculate the vfov on export, and the lens on import? We have the necessary data now (data.angle_y) so these calculations are not needed. %%%

Ejner Fergo commented

2011-12-08 06:49:39 +01:00

%%%Added nuke_cam.diff

very small fixes that simplifies the scripts

On export I found that frame range missed the last frame, added that back. 10 lines removed from "if camera:"
On import/export we don't need calculations%%%

%%%Added nuke_cam.diff - very small fixes that simplifies the scripts On export I found that frame range missed the last frame, added that back. 10 lines removed from "if camera:" On import/export we don't need calculations%%%

Ejner Fergo commented

2011-12-08 22:25:50 +01:00

%%%Sorry for posting so much, but honestly I'm a little perplexed. I get that you want to retain ownership of the script, possibly by figuring stuff out on your own, but I'm trying to help. The diff I attached (and the scripts before it) has all the changes, however few, for the script to work and make sense, but yet it seems you ignored parts of it? If you applied the diff you wouldn't get the "radiansfloat" thing Campbell complaints about...

Also:

Export still misses last frame
Export doesn't need sensor_x/sensor_y
The comment "if we have the camera, add the focal length" is wrong, which is too bad when the rest of the functions are so nicely commented.

Other than that export works except missing last frame and import is broken, but will work when fixed. Cameras and lamps is tested and works in Nuke. Applying a chan on an imported obj in Nuke is wonky. Strangely the rotation works differently than on cameras/lamps, and the imported obj, even if placed correctly in world space, has a translation of 0,0,0 (I talked to a representative from The Foundry and he will look at it). I don't work in Houdini but have the Apprentice edition, so can't comment too much on that (still need to learn CHOP etc...) but the missing frame is also an issue here.%%%

%%%Sorry for posting so much, but honestly I'm a little perplexed. I get that you want to retain ownership of the script, possibly by figuring stuff out on your own, but I'm trying to help. The diff I attached (and the scripts before it) has all the changes, however few, for the script to work and make sense, but yet it seems you ignored parts of it? If you applied the diff you wouldn't get the "radiansfloat" thing Campbell complaints about... Also: - Export still misses last frame - Export doesn't need sensor_x/sensor_y - The comment "if we have the camera, add the focal length" is wrong, which is too bad when the rest of the functions are so nicely commented. Other than that export works except missing last frame and import is broken, but will work when fixed. Cameras and lamps is tested and works in Nuke. Applying a chan on an imported obj in Nuke is wonky. Strangely the rotation works differently than on cameras/lamps, and the imported obj, even if placed correctly in world space, has a translation of 0,0,0 (I talked to a representative from The Foundry and he will look at it). I don't work in Houdini but have the Apprentice edition, so can't comment too much on that (still need to learn CHOP etc...) but the missing frame is also an issue here.%%%

Michael Krupa commented

2011-12-09 14:27:12 +01:00

%%%Sorry Enjer for not applying your diff, I've simply overlooked it :/ and on the other hand thank you for watching so closely to what I'm doing, really appreciate it.
I hope that's all the bugs in this tool (no wonder I'm an animator, not a programmer, I guess I would fail the first exam).

I've been testing the chan import on objects in Nuke and it works well, can you describe a little more about what's wrong?%%%

%%%Sorry Enjer for not applying your diff, I've simply overlooked it :/ and on the other hand thank you for watching so closely to what I'm doing, really appreciate it. I hope that's all the bugs in this tool (no wonder I'm an animator, not a programmer, I guess I would fail the first exam). I've been testing the chan import on objects in Nuke and it works well, can you describe a little more about what's wrong?%%%

Ejner Fergo commented

2011-12-09 16:13:19 +01:00

%%%Micheal, you overlooked all my attachments. My changes was exactly how the scripts are now, 3 days ago. Just makes me think how you will react if I, or someone else, makes changes to the script in the future.
The reason I'm watching closely, is like I wrote before, because the Blender/Nuke chan connection is exactly why I spend over a year pushing for sensor sizes and vfov in Blender, so it's pretty dear to me (I'm not a programmer either, btw). I'm very happy to finally see it become reality in 2.61 :)

About chan on objects in Nuke:

An object exported as obj and loaded into Nuke is fine, but when applying the chan file the object rotates -90 degrees on X.
If the object is rotated 90 degrees around X in Blender (e.g. Suzanne) and then exported as obj, everything works in Nuke. But apply rotation in Blender and export, and the rotation in Nuke is wrong again (-90 degrees) when using the chan.
The issue I brought up with The Foundry has nothing to do with the script, but how Nuke reads the obj. No matter where the object was in global space when exported, in Nuke it loads the obj with the correct placement in global space, but with an object center of 0,0,0 which messes up the translation/rotation from the chan file.
%%%

%%%Micheal, you overlooked all my attachments. My changes was exactly how the scripts are now, 3 days ago. Just makes me think how you will react if I, or someone else, makes changes to the script in the future. The reason I'm watching closely, is like I wrote before, because the Blender/Nuke chan connection is exactly why I spend over a year pushing for sensor sizes and vfov in Blender, so it's pretty dear to me (I'm not a programmer either, btw). I'm very happy to finally see it become reality in 2.61 :) About chan on objects in Nuke: - An object exported as obj and loaded into Nuke is fine, but when applying the chan file the object rotates -90 degrees on X. - If the object is rotated 90 degrees around X in Blender (e.g. Suzanne) and then exported as obj, everything works in Nuke. But apply rotation in Blender and export, and the rotation in Nuke is wrong again (-90 degrees) when using the chan. - The issue I brought up with The Foundry has nothing to do with the script, but how Nuke reads the obj. No matter where the object was in global space when exported, in Nuke it loads the obj with the correct placement in global space, but with an object center of 0,0,0 which messes up the translation/rotation from the chan file. %%%

Michael Krupa commented

2011-12-09 18:12:05 +01:00

%%%Lets begin from the end:
Issue nr 3 - it's not the problem of the Nukes way of reading obj files, but the matter of the Blenders export of obj geometry. Every time you export .obj you're saving the positions of the vertices it in the world space, not the local space. That's why you have to clear the location and rotation and place the object in the center of the scene before exporting it. It's because you have no way to export the local transformations for objects inside obj's, it's basicly a sequence of vertex locations, faces and UVs.
There could be a switch in the importer allowing to export every objects vertices in it's local space but then if you select more then one object you'll end up with a bunch of geometry in the middle of the scene overlapping each other.

Both issues 1 and 2 comes from the difference between Blenders coordinate system and Nukes, Maya, XSI etc... In Blender the Z-axis is "up" axis, everywhere else it's Y-axis. So - in fact everything you do in Blender is like rotated 90 degrees along the X axis against the other softwares, including the viewport so you don't notice it unless you move to other coordinate system.
To avoid the confusion of this weird conflict of spaces I multiply the transformation matrix of the exported object -90 degrees, so it's "up axis" points along the Y-axis of the scene, and then extract the transformations, instead of simply ripping the translation/rotation properties of the objects.
Unfortunetly the obj exporter is doing exactly the same thing, so we get the double transformation. To get the proper placement of the objects in Nuke you have to either:

Export geometry from Blender to .obj with default settings and then load it to Nuke, rotate it 90 degrees X, create TransformGeo node, apply the chan to the TransformGeo node, and parent your geometry to that TransformGeo node.
Export geometry from Blender with the settings: Z-up Y-forward. On import it'll be rotated 90 degrees but after loading the chan on it'll jump into it's place.

If you switch off the "Make Y up" properties during export for all objects/cameras you're exporting from Blender and load them to Nuke. Then you'll find that they're all correct against to each other but the whole scene is being rotated (I guess you still have to export geometry with Z-up Y-forward). This is exactly the scenario where the Locations X,Y,Z and Rotations X,Y,Z are being saved almost directly ("almost" means that the rotations are being taken from the rotation matrix created from non-pretransformed objects transform matrix based on the rotation order pointed in the export file selector. If this rotation order matches the rotation order of the object then the values stored in the chan file will be actually the same as in object Rotation X,Y,Z.)

Already updated the wiki with the simple explanation how to export the geometry, however the chan format is a little bit tricky without understanding the transformation math (world/local spaces, matrix math, rotation orders etc.).

It's a pitty that I've decided to contribute this tools so late. It spent in the contrib branch just a couple of days before moving to trunk so it's missing some heavey testing outside of my pipeline where I've got it all well integrated and covered from all sides, but just for my own production needs (i.e. I've made the file selector when I've decided that it would be nice to publish it, before that running it from text editor was perfect :).%%%

%%%Lets begin from the end: Issue nr 3 - it's not the problem of the Nukes way of reading obj files, but the matter of the Blenders export of obj geometry. Every time you export .obj you're saving the positions of the vertices it in the world space, not the local space. That's why you have to clear the location and rotation and place the object in the center of the scene before exporting it. It's because you have no way to export the local transformations for objects inside obj's, it's basicly a sequence of vertex locations, faces and UVs. There could be a switch in the importer allowing to export every objects vertices in it's local space but then if you select more then one object you'll end up with a bunch of geometry in the middle of the scene overlapping each other. Both issues 1 and 2 comes from the difference between Blenders coordinate system and Nukes, Maya, XSI etc... In Blender the Z-axis is "up" axis, everywhere else it's Y-axis. So - in fact everything you do in Blender is like rotated 90 degrees along the X axis against the other softwares, including the viewport so you don't notice it unless you move to other coordinate system. To avoid the confusion of this weird conflict of spaces I multiply the transformation matrix of the exported object -90 degrees, so it's "up axis" points along the Y-axis of the scene, and then extract the transformations, instead of simply ripping the translation/rotation properties of the objects. Unfortunetly the obj exporter is doing exactly the same thing, so we get the double transformation. To get the proper placement of the objects in Nuke you have to either: - Export geometry from Blender to .obj with default settings and then load it to Nuke, rotate it 90 degrees X, create TransformGeo node, apply the chan to the TransformGeo node, and parent your geometry to that TransformGeo node. - Export geometry from Blender with the settings: Z-up Y-forward. On import it'll be rotated 90 degrees but after loading the chan on it'll jump into it's place. If you switch off the "Make Y up" properties during export for all objects/cameras you're exporting from Blender and load them to Nuke. Then you'll find that they're all correct against to each other but the whole scene is being rotated (I guess you still have to export geometry with Z-up Y-forward). This is exactly the scenario where the Locations X,Y,Z and Rotations X,Y,Z are being saved almost directly ("almost" means that the rotations are being taken from the rotation matrix created from non-pretransformed objects transform matrix based on the rotation order pointed in the export file selector. If this rotation order matches the rotation order of the object then the values stored in the chan file will be actually the same as in object Rotation X,Y,Z.) Already updated the wiki with the simple explanation how to export the geometry, however the chan format is a little bit tricky without understanding the transformation math (world/local spaces, matrix math, rotation orders etc.). It's a pitty that I've decided to contribute this tools so late. It spent in the contrib branch just a couple of days before moving to trunk so it's missing some heavey testing outside of my pipeline where I've got it all well integrated and covered from all sides, but just for my own production needs (i.e. I've made the file selector when I've decided that it would be nice to publish it, before that running it from text editor was perfect :).%%%

Ejner Fergo commented

2011-12-09 19:02:28 +01:00

%%%Thanks for the explanations!

I knew about the Blender Z-up issue, but not that the obj exporter also applied the rotation. Makes sense now.
About obj saving vertex positions in world space also makes sense, since Maya also export obj that way, I was just thrown off by it. In my talk with the Foundry guy, we thought a button that sets "origin to geometry" in the ReadGeo node could be an idea, but lets see whats happens. Your solutions are very helpful.

Personally my primary use of this exporter/importer will be for cameras, and that works out of the box now :)%%%

%%%Thanks for the explanations! I knew about the Blender Z-up issue, but not that the obj exporter also applied the rotation. Makes sense now. About obj saving vertex positions in world space also makes sense, since Maya also export obj that way, I was just thrown off by it. In my talk with the Foundry guy, we thought a button that sets "origin to geometry" in the ReadGeo node could be an idea, but lets see whats happens. Your solutions are very helpful. Personally my primary use of this exporter/importer will be for cameras, and that works out of the box now :)%%%

Brendon Murphy commented

2012-02-21 22:25:54 +01:00

%%%Hi,
Due to changes to the api including the merging of bmesh, several addons are outdated.
Please, if you are the author of an addon check your script with blender revision 44256 or newer.
That is builds made After blender 2.62 official release.
I would ask that updates be made to your addon before the Blender 2.63 release.
6-8 weeks away.
This allows time for the api to become more exposed & bmesh to stablize furthur.
If you need help, drop into irc freenode #blenderpython or #blendercoders & feel welcome to ask questions.
At the time of 2.63 release, scripts that are not repaired or in active developement will have their tracker page marked "Closed"
this will not affect your links to the tracker, similar to closing scripts in 2.49b, the page will be still availible & can be re-opened.

Thanks for your understanding & patience during these Exciting Times.
Brendon.%%%

%%%Hi, Due to changes to the api including the merging of bmesh, several addons are outdated. Please, if you are the author of an addon check your script with blender revision 44256 or newer. That is builds made After blender 2.62 official release. I would ask that updates be made to your addon before the Blender 2.63 release. 6-8 weeks away. This allows time for the api to become more exposed & bmesh to stablize furthur. If you need help, drop into irc freenode #blenderpython or #blendercoders & feel welcome to ask questions. At the time of 2.63 release, scripts that are not repaired or in active developement will have their tracker page marked "Closed" this will not affect your links to the tracker, similar to closing scripts in 2.49b, the page will be still availible & can be re-opened. Thanks for your understanding & patience during these Exciting Times. Brendon.%%%

Brendon Murphy commented

2012-04-16 14:30:13 +02:00

%%%Moved from Py Scripts Upload to Py Scripts Release%%%