利用者:Phabtar/Full COLLADA Animation Support for Blender/Diary and Notes

Diary and Notes

20:14, 26 April 2011 (CEST)

Set up Basic Wiki pages for the project. A link to a page for the whole project is appended in to the User page. A new wiki page for the project was made and linked in the user page. This page will basically include all information about the project, which is currently very little.

19:49, 18 May 2011 (CEST)

Admittedly work has been a bit slow. But during the past weeks I've done somethings which are necessary for the project. Set up a clone repository in Gitorious.org of the blenderprojects/blender repository. I didn't have awful lot of experience with using git. So setting up a clone in gitorious was, I thought, safe. :). I can say I'm kind of familiar with using git now. But still I'd prefer SVN all the way :S. Who knows it might change in a couple o' weeks. ;). Still has to share the development branch with aligorith who is doing another related GSoC project this year. Mental note ( actually a slightly more literal one in the desktop ) to look in to it later. Definitely before development commences.

Also had a thorough look into the animation related schema concepts and COLLADA specs. Specifically in Curve interpolation section and animation (core) section. Have to look in to more examples on usage and better understanding.

21:46, 29 May 2011 (CEST)

Busy days! Should've updated daily. Past week switched the working copy I had of Blender to the GSoC 2011 pepper branch. Made some commits. Actually Feels good to be a committer :). Had a very thorough look at the existing source code in Animation exporter. refactored Animations Exporter class in DocumentExporter files in to seperate files. which should make coding easier. Done some cleanup of code here n there. Also applied and modified the patch submitted by ccliffe which adds support for exporting of BEZIER and STEP interpolated f-curves. Committed the changes. Updated the wiki page and compiled a TO DO list which will be a guide line in the days to come. BTW got the payment card today :D

22:16, 31 May 2011 (CEST)

Made a basic scene with one armature with euler and quaternion rotations on the mix, plus a rotation mode animation. Tested the current system. What's discovered was :

• euler rotation data is never exported. The current system derives the output values by the rotation matrix derived from the pose matrix, which holds only quaternion rotation data.
• Sometimes the timeframes are not identified. As I experienced this occurs when exporting while the euler rotation f-curve is selected. Gotta check.

Also noticed that there is a possibility of using posechannel-> [rotation matrices] directly instead of using the pose matrix, to export rotations. Then euler rotations and axis angle rotations can be exported as well.

Tried completely removing the armature animation export path. then the armature objects animation data will be exported as f-curve exporting procedure. At least that's what was expected. But this didn't happen because the transform name had to be derived from the f-curve-> rna_path. (this is not done for the other object types, the rna_path is straightaway taken to check. CHECK!). By Debugging discovered that Although the current scene has a mix of euler and quaternion, ob->rotmode is set to euler. Need to test with isolated rotation systems instead of a mix to clarify. Possible reason is rotation mode animations. maybe remove ob->rotmode checking too. Too much constraints. :D

07:55, 2 June 2011 (CEST)

One issue I encountered is the anim_id for armature objects is not valid in the COLLADA specs. So made a function which makes a valid anim_id with given object and f-curve. The object name is appended with the bone name derived form the f-curve's rna path. Initial tests proved the naming works as expected. Must further test for more complicated scenarios. Now quaternion and euler rotation animations of armature objects gets exported correctly. Must further test. For now, the write_bone_animation path can be omitted.

13:10, 10 June 2011 (CEST) Last weekend I further tested the exporter with different scenarios. And modified the exporter to fit the changes. At the end of the week the exporter was tested on the following types of animation and was successful in exporting them:

• Objects with location and rotation(euler, quaternion, euler+quaternion) animations.
• Armatures with location and rotation pose animations.
• Armature animations applied to the armature as object animations
• Animations of bones parented to other objects.

Then I began my work on modifying the importer. The import system seems a bit jumbled up on initial inspections and it was kind of hard to grasp what's what. After a good look through of code, which took much longer than I expected it would, got an okay idea about everything. Also had to study the code in the opencollada framework as well. It was necessary to summarize the contents for my better understanding and the content summary is posted in Animation Importing.

After going through the code, I edited the exporter to fit the sid addressing standards applied when parsing COLLADA documents. Also decided to write my own import procedure. Further Comments and heavy duty testing must be applied on this system. Still ToDo.

06:46, 14 June 2011 (CEST)

The importer implementation works for a simple cube. But the rotations are not being imported quite well. Only euler rotations are being imported right now. The problems were due to deg -> rad -> deg conversions of rotation curve output values and curve interpolation (Bezier Handle Values) Solved the unit conversion problem but the interpolation problem may be solved by importing in-tangent out-tangent values. Will Implement that tomorrow.

06:50, 16 June 2011 (CEST)

Committed the initial version of the new import system to the GSoC branch. The code was very untidy. The version on the commit supports object animations. Not tested very much tho. Feel like I'm behind schedule because of the implementation of the new system. But I felt that it must be done for further improvements. Anyway... :)

Done some few tweaks to import armature Animations. Tested for a simple armature animation and it worked! Was quite pleased with my self so straight away tested for a very complex system and it failed rather horribly. Still there might be something going wrong with unit conversions. Have to test from simple to complex systems step by step.

Developed some code to convert quat rotations curves to euler curves before exporting. Because opencollada framework doesn't support import of quaternion rotation curves. ( There isn't any animation class declared which can be used to support quat rotations.

Implemented creation of action groups when importing armature animations.

06:20, 17 June 2011 (CEST)

Fixed bugs related to unit conversions. Now I can safely assume that the fcurves are being imported accurately. Because for simple armature animations we can see the inherent animations being imported. But when the system gets complex some bones get all haywire. Removed animation tags of the same document and imported it and the problem remains. So an assumption was made that what goes wrong is with the armature import system. Discussed with jesterking and was given the task of fixing that issue also. This is outside of the project proposed scope but seems to be blocking the progress of the project so the fix must be done.

Also jesterking pointed out that bones which are not skinned don't get imported. I've noticed this before and decided to switch to skinned animations for testing. But It would be better to import non skinned armatures also. Added to to-do list.

Decided to test the import system on a basic skinned armature system by exporting and re-importing the scene, while making the animation more complex. This will be helpful in id'ing what goes wrong.

19 June 2011

Wrote new methods for the Armature Importer class which doesn't take in to account Skin controller data. The methods written are similar to the ones which takes skin data into consideration. Maybe later integrate the code in to a single set of functions. Initially had some problems due to leaf bones not made correctly. But this problem was overcome easily.

Still had some problems with animating the imported armatures. Had to edit write_node() function in DocumentImporter.cpp to initialize lists of armature objects accurately. Because the joint<->Object mappings needed to be rectified in order for proper animation assignment. After some modifications such as those, a satisfactory system was resulted. Which is able to import an animated armature system with there inherent animations. But some inaccuracy of the animations were noticed. This was not due to faults on the new animation importer system, because by inspections it was determined that the imported and assigned f-curves were pretty accurate. The root of the problem maybe due to imported transform values and bone roll attribute. Further testing is necessary.

07:57, 27 June 2011 (CEST)

Past week was admittedly a slow week. Did some diagrams of the new work done and updated the wiki pages with them.

Generally looked for more ways to increase the accuracy of the armature animation import. What I noticed was when exporting armature joints in to COLLADA joint nodes, What I noticed after going through the code is in the discussions section of the main page. Experimented several ways to rectify the armature orientations. Mainly devised functions which assigns the imported node transform matrix to bones pose matrix. This did not solve the problem, as discussed in the discussions. Currently figuring out algorithms to calculate mainly the roll attribute of bones which is currently defaulted to 0 for every bone which is imported!

Thinking about moving on to light parameter animations soon.

07:37, 28 June 2011 (CEST)

Further worked on improving armature importing. Wrote a bit of code which derives axis angle from the node transforms matrix and assigns the angle taken from that to bone-> roll attribute. It was discovered that the assigned value is quite different from the exported value. But interesting thing found out is that the change of the roll, however inaccurate it is, doesn't change the animation whatsoever :(. So the impending problem mustn't be in the roll after all.

With the collaboration of #pjoe, tested the exported scene with Maya and discovered that the orientations are totally wrong when exported to Maya! Good thing to know is that the animations work in Maya also :D. That's a relief with respect to the projects objectives. Maybe a re-evaluation of Bone export is in order.

However decided to move on to other features like light parameters. First, focused on color animations. But in the technique common profile colors are not animated I guess, but in profile-COMMON it is. Still in progress.

07:13, 1 July 2011 (CEST)

Successfully exported color animation of lights. No Issues there. Although to make it re-importable have to do some further modifications, Like Sid addressing. Exported in to the Technique Common Profile.

06:18, 5 July 2011 (CEST)

Implemented Light color animation import support. The procedure followed will be described here and it can be used as a cornerstone in implementing support for any parameter animations. Also using the same procedure, Implemented support ( import/ export ) for Spot light->spot size animations. Tested and verified. Still must test for combinations of animations. The system was designed to handle such combinations as can be seen in the above link.

07:22, 10 July 2011 (CEST)

Lot's of parameter animations. Following a similar procedure as with the other Light parameters support implemented. Finished Light->spot blend animations also. Combinations were supported with the use of bitwise flag operations.

Also Moved onto camera parameter animations also. Basically they were all float animations. So easy to be implemented. Aspect ratio animations is a special case. Because the value is calculated with two values when exporting. Maybe importing is possible, by assigning two simultaneously changing values to the values which are used to calculate aspect ratio when exporting.

More documentation.

16:01, 15 July 2011 (CEST)

Past few days made some screencasts demonstrating the project progress. They were uploaded to youtube and can be watched here. Since these were my first screencasts, it needed some practice. More are yet to come.

Also pjoe pointed out that color animations exported from Maya couldn't be imported correctly in to blender. I also asked for the Maya export from him and tested my self. After doing some slight modifications, fixed that issue.

At the end of the week had to go on a 3 day vacation. So work can be continued from Saturday.

21:23, 22 July 2011 (CEST)

After the vacation. Made some improvements in material animation support. Was able to implement support of export without much trouble. But having problems on re-import. The problem is in getting the common effects of an effect, so the animation list of effects in the common effects class can be used to assign animation. But the common effects object has referencing problems. still struggling to tackle the problem. Hopefully it won't waste more time than it already has.

Getting some awesome feedback for the videos posted in youtube.com. Must make more :D.

06:33, 25 July 2011 (CEST)

This weekend figured out what's wrong with material animation import. The assignments of animations occur in the finishing stages of the document importer. That means the parsing of the COLLADA document has finished. So each node is taken from the node library and animations are assigned to the object connected to those nodes. To assign material effect animations, one has to get the connected material from the geometry nodes, and get the effects referenced by the material, by sid addressing and URLs. But I found out that the connected COLLADA material object cannot be referenced. But other objects like lights and cameras can be referenced. So I investigated in to the opencollada code and found out that only the material objects gets deleted and the other objects are not. So as a solution I mapped the UniqueId of the material, (which can be taken from the geometry node) with the Effect object, during the document parsing stage. Then the map can be used to derive the Animatable parameters of the effect to get the animation lists in Animation importing. Also implemented export of the tip of bones in a blender profile. Because the COLLADA joints are just nodes instead of bones as in blender. So the tip details are not exported before. Haven't tested that yet. Will have to work on importing the tip too.

21.10, 29 July 2011 (CEST)

More Material Animations. First off specular color animations. The implementation was built upon the existing light color animation support system. Also developed support for diffuse color animation import and export also. After some identifying of variable names and rna paths, added export support for material transparency animations also. But import is constrained because the transparency variable in COLLADAFWEffectCommon class is disabled. Have to investigate it further. Got to move on to more animations also.

20.34, 5 August 2011 (CEST)

Made a new screencast on COLLADA Material animation support in blender which describes the new features added on by material animation support. Was hoping to make a video demo on Camera animation support also, but the clip start and clip end animation support was not completed. So went on and completed them, but never got to making the screencast after that. will publish it next week.

Had a talk with the blenderCOLLADA team of devs on what features would have to be added in next before completion of the project. The general vote was on COLLADA support for armature animations which are baked. So this was kind of s new area to me. But decided it would be best to implement this feature without further ado.

During the last few days studied the code on how to implement this easiest. Did some tweeks in the Animation Exporter class to enable this new feature. After some effort made a system which is supposed to export framewise pose matrices of an armature in to COLLADA document but is still in accurate. Still Has to modify this system to reflect animation baking accurately the next week.

15:57, 6 August 2011 (CEST)

Before submission of the weekly report decided to implement another parameter animation support. The parameter in question is Material raytrace transparency index of refraction animation. The Animation support works well but on import still has to enable material raytrace transparency for the object in question manually. This will be fixed later on. Mo important matters are at hand now.

The end of my current internship is going to conflict with the GSoC pens down period. Will have to manage the time of coding for the next two weeks intelligently.

18:18, 12 August 2011 (CEST)

Last few days was working on bake animation export and import. Since the last entry was busy with the import aspect mostly. Basically the export was working fine after a few changes. One problem is transform matrix curve is appended with other types of animations also. Ideally it should be developed so that user gives the option to export as transform or as a mix of location rotation and scale transforms.

Nevertheless had some test sessions with pjoe and the results were not that satisfactory. The exported bone animations doesn't work so well in the software that pjoe tested with, 3DViewr.

Developed a lot in the armature transform matrix animation import methods. Used some code in the old system also. Tested it after implementation. The bone animation curves gets imported and assigned. But the curve values are not being imported accurately yet. In the process of correcting that fault. After testing it with blender exported files have to move onto files exported from other software as well.

Pjoe pointed out that sid addressing in animation elements was not according to COLLADA 1.4 specs, there was a slight modification that needed to be done. This was not a problem before because the opencollada framework works even without that modification. But other software depends on that missing modification. So rectified that easily.

The final week is up. Have to finalize everything. In the weekend plan to implement more parameter animations support.

12:18, 16 August 2011 (CEST)

Gave an attempt to export and import light parameters which is in the blender profile. Sid's of some parameters were set and exported animations of the lamp->distance attribute successfully. The animation curves gets exported but the identification of what channel target sid to set, was tricky. Tried various combinations but the animation list were not made when importing. Therefore went in to extra handling code in opencollada and discovered that for extra parameters, opencollada doesn't set the sid addresses and add to sid trees as expected. So tried to do it manually in the ExtraHandler code, but was not successful. Even if we get the attributes correct, finding the animation curves which belong to the attribute is tricky. This is only pointed by the channel target of the curve, but getting the channel target after the opencollada processing, is also tricky. Maybe another profile bound parameter as the channel target will be a solution. Since testing the different methods to approach this needs some time, decided to put on hold the matter to continue after GSoC finishes up, because finalizing the project is more prioritized.

Discussed with Campbell Barton on solving the issue of the accuracy of bone transforms and setting the role. Generally my approach was with some loop holes. Setting the pose matrices directly was not going to work after bone exits edit mode. As the core of the problem pointed out, if the bone roll is set correctly, then the pose matrix will take care of it self after exiting edit mode. So discussed an algorithm to derive the bone roll from the node transform matrix.

11:07, 18 August 2011 (CEST)

Tried several attempts to fix armature animation exporter. Refactored a bit so output source values are not made separately but in the output source writing phase, ( in create_4x4_matrix_source() method) The same bone bone_space matrix is evaluated at each frame and exported. But importing still generated problems. Also tried exporting inverse_bind_pose matrices which is not what is expected in the standards. A wild guess. Finally applied the matrices by converting them through the Unit_Converter which I had missed earlier. This solved the problem almost instantly. Also edited the transform writer to export node transforms as matrices for exporting joint nodes. Only discrepancies in the leaf node animations remain. Otherwise export of armature animations were totally fixed. Which includes exporting quaternion rotations and correct roll and animations on re-import. Cleaned up Animation Exporter, Animation Importer and Armature Importer.

18:38, 26 August 2011 (CEST)

So This is the end of GSoC. This will be the final record I’ll make on this diary. But work will continue with the project after it’s merged with the trunk. This last entry is a little late. But its because I had to write the industrial training final reports for the University.

Past week leading to the pencils down was very productive. After testing and confirming that armature animation is working ok now, with the bone role correction, pjoe tested the system with a more complete model which has a human skeleton armature with skin controlling. Pjoe made a small fix with skin controller data inverse bind matrix source export data. He tested and confirmed that animations of such a system is also working. The success was confirmed by tests with his 3Dviewr application. This was such a relief to find that animation working.

Then the system was tested with a more complex instance. A fully rigified armature animation with the same model. The rig had constraints, IK solvers and was a quite complex model. A straight export from that data didn’t work quite well. Because the animation data involving constraints can not be mapped on re import because data involving constraints is not exported directly. But since the pose matrix of the bones in the armature reflects the data of constraints also, figured out that baking the animation to the bone system would work. So went to Bake action window and unchecked “only selected” and baked while removing constraints. Then did a export and re-import. It took a while because of all the extra data being exported because of baking. On import the bones did seem kind of mixed up. Because bones are assigned to all the joint nodes on the Visual scene. After hiding the armature played the animation and it worked perfectly. I was very thrilled to see this happen and immediately shared with other collada devs. Tested with the 3Dviewr also and it was working on that too. Made demo of the procedure in the weekend. And posted it on the reports. After that some little tweeks were made to refine the animation. Wrote a method to export only the deform bones. Although the function worked the animation was not imported correctly because data related to other joints not in the deform group is also needed in the animation hierarchy. Suggestions were made by jesterking to automate the procedure followed in the demo, but decided to postpone that because GSoC is almost over.

Jesterking pointed out another bug. The instance was a scene with 2 cubes parented to a bone. The bug was due to the document exporter node exporting sections. Because the hierarchy of nodes is not exported correctly by the document exporter for such scenes. Pointed that out to jesterking. Lots of documentations had been done finally. Fully refined the main project wiki page. Add docs to user and architecture pages also.