From BlenderWiki
23rd May
So Exams finished, It was long and exhausting. Finally, can start work on the project. The wiki pages were made during the exams. Added some more tweaks and sections to the wiki. The feedback from the blenderartists thread is encouraging. The problems mentioned in the thread will be answered. A solid user and testers base will be a huge boost to the project. First must get up to date on the current situation. I've missed some important updates to the COLLADA branch. Gaia Clary is handling some important improvements to the COLLADA section. Made contact with Gaia and discussed about the projects somewhat.
28th May
Last few days, did a bit of analyzing. Identified important subtasks while going through the constraint animation fundamentals in blender. Initially decided to code support for tracking constraints animations. Created a simple scene with an empty an a sphere which tracks to that empty target. After animating the target and exporting, as previously no effort for constrained animations was implemented, only the animation of the target was exported. So on reimporting the .dae the spheres animation and constraints were not reflected.
To overcome this there are two options possible, one is to have export constraints parameters in a blender profile, and the other is to sort of bake the animation of the sphere and export another animation curve for that. Gaia Suggested to have both of these implemented inside <extra> tags. <technique_COMMON> and <technique_profile = blender> elements can be used to achieve this. So with my first commit for GSoC this year, committed an initial attempt export constraint data within a blender profile in <extra> tag within node elements. Objects which have constraints are checked from the Object->constraints ListBase.
31st May
A busy week, with two project deadlines from university coming in the next week. So couldn't keep up with GSoC work as expected. Since exporting of constraint animations involves baking the constraints to the objects and exporting the new curves, had a look at blenderpython scripts to bake constraints. So they can be converted to C++ code and then can be used to automate exporting of constraints. But it seems more challenging than expected. Maybe a different approach will be needed to bake constraints. Although the theories can be used as in the python script, the algorithm may need changes.
10th June
Past week had been a busy one, not because of GSoC work but because of University work. Had 2 project demonstrations, in one week, so had to get ready for them. Time that could be spent on coding for the project had been limited because of that work. However did manage to get some useful work done. That is exporting of constrained animations on Objects. It turned out to be less challenging than expected. Had to go through lot of code in constraints.c to dig out the necessary stuff that is needed. After some digging find out the methods which made the task surprisingly easy. The details will be covered in the main wiki. So now animations of Objects which has simple constraints like track-to will be exported as technique_COMMON animations. Still has to reach users in getting interested in testing the implementation. May need some modifications according to those feedback.
Next my focus will be on importing the currently implemented stuff. First of all applying the exported constraints in the <extra> when re-imported back to blender. After this is done the exported animation data will not be needed in the re-importing scenario, because the imported constraint will take care of that. The animation part will properly have to be tested with users.
15th June
Past couple of days worked more on constraint exporting. Added another level in the extra tag which corresponds to each constraint the object has. Almost all the data will be exported for each constraint. One major problem is defining the target of the constraint. Initially the code will try to export one target per constraint. AFAIK opencollada doesn't provide methods to define URI's within extra tags. So the name of the target will be exported. Not ideal obviously, but will have to do for now. As of writing this entry, the bratwurst branch doesn't build OK, so waiting for it to get fixed. Also as per Gaia-Clary's request started having a look at armature exporting. Notes on the stuff that I learnt while going through armature code will be debriefed here.
17th June
Was having some building problems with the bratwurst branch, so debugging efforts were somewhat paused. Anyway decided to quickly remedy the situation by a quick fix in my build and continued debugging. First did some reviewing on armature exporting. Got the idea that the bone->arm_mat matrix which holds the rest position of the bones should be solely considered in exporting bones. Have to review and test more to discuss this with the community to get clarification.
But will have to look on that later, because continued to work on project deliverable related stuff again. How the importer should handle the exported constraint related animation curves, is still yet to be determined. In fact if the importer is able to correctly import the object transform animations which are due to the constraints, then that will be a guarantee of valid baking. So started debugging towards that end. To test a simple scene with a sphere and an empty was modeled. The sphere has a simple track to constraint with the empty. The empty has a two frame animation.
On the first tests I found out that the animation (refer here) were not properly made by the framework, due to the absence of matrix transform type info inside the sphere node. So after a quick fix, the animations are imported correctly! But the export procedure is not 100% because the movement is not reflected. This was confirmed by studying the dae. So will have to fix that next.
23rd June
In the middle of the week, went to several job interviews in the carrier fair organized by our University. So had to prepare for them Monday through Wednesday. After that continued work. First of all had some problems with the building of code, due to some discrepancies in merging. Had to ask for Gaia-Clary's assistance in fixing those errors quickly, because it was his area of expertise. Went on to fixing the constraint animation export.
As discussed on the last entry, the exported animations were not really reflected in the dae. To explain more it seems the object matrix of the tracking object did not change per frame. Afterwards realized that the cause was obvious. In the export procedure, the tracking object transformation was only solved for each frame, not the track-to objects also. So track-to objects would stay stationary in the solving process, and the animations due to the constraints were not reflected. This was fixed by solving target object transformations per frame, before the tracking object is solved per frame. To my delight this exported a changing output source in the dae, and was verified with importing back the dae.
But the imported objects were not really accurately placed. This was obviously due to the addition of the matrix transformation in Object nodes. But the animations were accurate. So comparing the two import procedures of animation curves and node transformations, found out an obvious flaw in the transformation import calls. I guess this was not detected earlier because Blender only exported loc-rot-scale transformations instead of matrix transformations. And the import methods didn't assume that matrix and loc-rot-scale transformations could stay in the mix. Fixed that also. And Now Track-to object constraint animations are imported and exported without trouble. Gotta make a video soon. Also must verify for other types by user assistance.
28th July
Long overdue entry. Actually the wait is due to the unfinished work of IK constraint animations. I was biding my time until it was actually finished. Since I was finally able to hence this entry. Here I will try to explain all the attempts and challenges I've faced.
The previous system identified each of the bones which have animation data associated with them and only they were considered in the animation export process. Then the animation fcurves corresponding to each bone was exported. First of all I tested this functionality to make sure it was working as expected. Armature animations without rigging or IK constraint data was exported and reimported as expected.
To enable support for IK constraint animations, since not only the bones which have associated fcurves has to be exported with animation data, but also the other bones animations due to the influence of IK constraints has to be exported as well, the process must generalized to mimic a baking of animation data, as done manually in last years project
Therefore removed the filter for bones with animation curves. Every bone will be solved for each frame and pose matrix will be exported as animation curves. As expected animations with no IK constraint solving was exported as expected and was confirmed by reimporting back to Blender. But when IK constraints were involved, the bones movements was not reflected in the exported *.dae. I tried many methods and alternatives to get some parameter which changes for each keyframe for IK bones. But the fundamental reason they weren't animated was because in the process of exporting fcurves were disabled for every bone other than the bones with animations. I simply missed this and was in search for any other reason in the Blender kernel code. At the end lot of time was wasted when there was a simple solution. But I gained a lot from the process. Now I have a thorough understanding of the whole bone animation solving process in Blender.
13th August
Busy days, due to the overlap of University final year project deadlines and the GSoC deadlines, it has been a very busy couple of weeks. So managing work as milestones occur. On a separate note I found a Job as an Software Engineer. :)
The last weekend focused on GSoC and focused on trying to finish Morph controller support, as per the leftover tasks. As per the initial studies pre-GSoC I found out for Morph controller support, the parallel Blender element is the shape keys, so renewed my memories of shape keys. Also COLLADA 1.4 specifications detailed how the tags and data should be. But I gained the core understanding from this article :[1] , which has an example of how it should be handled. The details of the operation will be discussed in the main page.
Did a search on the code base to find the code related to shape keys. After going through some functions it wasn't so hard to figure out how to get the separate meshes for export. Then developed the methods inside the geometry exporter to export the shape targets or morph targets.
Previous controller exporting code resided on the armature exporter, because the only controller exported before, the skin controller, depended heavily on the armature data being exported. But since a new controller was introduced, the controller exporting data shouldn't lie on the armature exporter anymore, so refactored a new ControllerExporter, which handles the skin controller data as well as the morph controller data exporting. After that, introduced methods to export controller data specific to morph controller.
Then I focused on exporting morph animations. First advanced the reference scene to include morph animations. Then referred the web on exporting morph animations. This page suggested that morph weights in the array could be animated. But explained no means of doing so. As per my understanding of COLLADA animations, a method of addressing animation did not seem possible at first, with the default techniques common support. This page confirmed that doubt. I shall discuss this further in the main page. Bottom-line is, morph animation support is not default, we have to implement work-arounds for that as well. Anyway after a few mods, the animation system was made to id morph animations and export them but it is not as well defined.
So next I worked on Morph controller import. First tried to refactor a ControllerImporter just as with the exporter case, but weird bugs just started to jump out of nowhere so decided to undo it. The importer is more complex than the exporter. So Decided to work my functions in to the existing code. Implemented it following the guide lines of the skin controller importing, but it wasn't as complex as the skin controller import. There is much less data to handle. followed the blender default way of inserting new shape keys to make new shape keys and insert them in to the basis mesh.
So this is it for this GSoC, wrapping up the documentations right now. If circumstances are provided, will make a video on morph controller support. It has been a fulfilling GSoC for me personally, There was so much stuff I learned from this one also, including time management. Although wish there was more time to finish it perfectly. Anyway I am satisfied with what I have done with the time I had. Hope you all are as well.
CHEERS!
