利用者:Aramis acg/FBX2012-Worklog
目次
GSoC 2012 - FBX Importer Worklog
For an overview of all wiki pages I'm maintaining for this project, see my user page.
I'm working in bratwurst branch (mhhhm)
https://svn.blender.org/svnroot/bf-blender/branches/soc-2012-bratwurst
and, in parallel, development on Assimp takes place on a assimp branch hosted on github.
Week 1
- setup work environment
- started work assimp -> blender integration.
- further investigated available FBX reference materials, did some model testing and planning on how everything will work together and how I'll design the assimp FBX importer.
- decided to move the assimp side of my work to github (https://github.com/acgessler/assimp-gsoc2012-fbx)
I didn't commit anything to bratwurst yet, but I'll do this in the course of the weekend.
Week 2
Worked on Assimp integration in Blender. Geometry, scene hierarchy, basic camera and lamps and materials (including UV mappings) and textures are imported now. Started a TODO page on which I'm documenting what is missing/yet to be done on assimp integration
Started my assimp FBX importer. No, it doesn't load anything yet
Currently it looks like this:
Assimp got its own menu entry and basic import works.
Week 3
Got totally eaten up by other work :-(, so everything I planned there is postphoned to week 4.
Week 4
Original Plan:
- get assimp animations working in Blender and finish up the TODO
- FBX importer with solid geometry up and running in Assimp (in my git repository)
Results:
Worked up nearly all TODOs for bf_assimp (see the TODO page for assimp). During the week I found a lot of other mini features missing from bf_assimp and implemented those as well (and added them to the checklist).
Animation support is not yet complete, but armatures are read correctly. The importer now no longer mixes up bones and nodes and the object hierarchy for skinned scenes in Blender's scene should now look as users expect it to look (bones only imported as part of the armature, no longer as EMPTY nodes).
I did not work very much further on my FBX code since bf_assimp took longer than expected, and also I think it is crucial to get this done first.
I also updated this wiki, assimp integration proposal got some slight updates to reflect the updated interface.
Problems:
No real problems (I struggled with getting Blender to build on my Debian (to have a linux build and a sane workbench for updating the SCONs build). But that's something I'll get resolved sooner or later.)
Week 5
Plan:
a) Finish up animation during the weekend. I hope to complete this with a video showing some of assimp's sample skinned files running in Blender :-)
b) Finally get a first version of the FBX importer (basic geometry importing) up onto Github. I didn't do very much on the FBX importer yet (in fact, it's just a skeleton with basic parsing so far, no data extraction yet), so I'll plan Monday-Wednesday for this.
c) Merge with the latest Assimp version and update the copy in Blender SVN as well. Not much work.
d) Have FBX importing (to the extent it will be implemented at this time) over the assimp-blender bridge till next Friday. This is theoretically not much work, too (because basically it should work as soon as the updated assimp code is in but who knows .. ).
e) talk to / find more potential testers on BA.org
f) further document the structure of the FBX importer on the wiki. I don't plan to go much into detail unless it's requested. After all, the importer is, from Blender's point of view, third party code and will be maintained by external developers (uhm, me) :-) (also all assimp importers share a similar structure and there are already some other importers with characteristics similar to FBX).
Results:
a) this took two extra days, but I got it done and assimp import in Blender is feature-complete now and the entire assimp data structure is covered. On thursday I found another issue with armatures that prevents some assimp test files from being loaded correctly - I couldn't yet fix that one. I also added some smaller TODO entries which I'll fix while working on FBX in the next weeks. I also started a wiki page to track files from assimp's testsuite that don't pass yet.
FIXME Add video showing animation import ...
b) since most of the week got eaten up by a), I did't get to this before today (Friday). What I have is up on github. For processing FBX syntax, I revamped the version I had before and switched to a more classical tokenizer+parser structure.
c), d) delayed both. Didn't get far enough with FBX. Also assimp 3.0 is about to be released, merging now would just cause double work.
e) done - there are quite a few people who expressed interest in testing.
f) done - see revised plan for integrating fbx into assimp and for dealing with different FBX versions and plan for integrating fbx into Blender.
Problems:
None.
Week 6
Plan:
a) keep working on assimp FBX importer - this means finishing b), c) and d) from week 5.
b) bf_assimp bughunting
c) add bf_fbx module in Blender (frontend for FBX as described in my docs).
d) make sure there are bratwurst builds containing my work on graphicall. If far enough, ask testers to try out.
e) wiki: need a definite checklist for fbx features to be implemented, and also a list of those that I definitely won't implement for now (based on original proposal, BA.org feedback etc).
Results:
a) done. Most of my time went into writing a solid and (imho) relatively well-designed FBX import infrastructure (check out https://github.com/acgessler/assimp-gsoc2012-fbx/commits/master/ for commit history). Current converter reads only meshes, but adding further stuff will be much easier. I finally updated the assimp copy in the Blender repository (which updates it to assimp 3.0 and makes FBX reading available in Blender).
b) didn't work on that. c) done - FBX got its own module (dependent on assimp), its own import operators, menu item, .. d) this was on my schedule for Friday, but since I'm away till Saturday it'll likely be done next week.
Problems:
None
Week 7
A slightly more complex 3D model read from fbx:
Plan:
a) fbx importer implement
- scene hierarchy & transforms
- cameras
- lights
- materials
(I'm not tackling animations yet)
b) b from this week (debug armature import errors in bf_assimp)
c) d from this week (public test builds)
d) Finally update SCons build - my entire work is so far only accessible via CMake and I'm also guilty for not having tested with any compiler except vc9.
Results:
a) this was my main work during the week (https://github.com/acgessler/assimp-gsoc2012-fbx/commits/master/). The net result is that static fbx files are usually read correctly now, including materials, scene hierarchy, proper names etc.
A group of Blenderartists users interested in fbx import did some test files for me and will keep doing so in future.
I merged this into bratwurst.
b) no - my armature code was based on bf_collada's and phabtar did work on these code parts in this week so I decided it would be best to wait a bit
c) done. Added SCons build files and did some gcc fixes
d) TBD, not yet finished
Problems:
None
Week 8 + 9
Plan:
a) go through fbx import TODO, do more testing and bug-hunting (see wiki)
b) design a generic dictionary/property system to allow the fbx importer to pass extra data through assimp into Blender. This will be useful for some other importers in assimp, so it's not a fbx-exclusive "hack".
c) start work on fbx animation import in assimp (the generic implementation goes first).
Results:
a) fixed some issues, collected many more
b) done, but not merged into assimp so far
c) done - first work on animation reading has been done (all the stuff is read), now I'll need to improve on the conversion to fbx.
- there are now public testing builds of the fbx code
Problems:
I got some feedback about the importance of also fixing up the exporter to ensure a roundtrip. This has not been forgotten, indeed it is still _the_ target for the project. It is not yet clear, however, whether I'll end up writing an importer from scratch (possibly post GSoC, hack-fixing the current export script in the last week of GSoC) or not.
I actually tend towards rewriting it - importer and exporter share lots of code, many stuff is symmetric and assimp's fbx implementation would thus become some kind of open source (limited) replacement for Autodesks FBX SDK.
Week 10
Plan:
a) work on animations, animations, animations - proper fcurves need to be generated and bone weights should be read (if I get skinning to work then great, otherwise this will be the job for next week).
b) investigate fbx binary format, see how to fit a reader for it into my existing code.
Results
- devised a scheme how to transfer fbx animations seamlessly to blender (and back again some day) and implemented it. Things are complicated because fbx has a relatively complex node transformation chain that doesn't match blender's, nor assimp's. The updated importer generates additional nodes to keep the original transformations and tags them with special names so the exporter can undo this transformation. It took a lot of time to implement this, since we're not only talking about nodes but also about the animations associated therewith. This scheme kicks in for nearly all animated fbx files I have for testing.
- implemented a fallback scheme to make sure files that only use basic stuff (i.e. rotation, translation, scaling) don't get their scene hierarchy busted up for no reason.
- implemented bones/weights. Some quirks in there, though.
- REed the binary file format.
- Got some feedback on BA.org
Week 11 - 13
Plan:
- More work on skinning
- Implement binary file format
- Implement import option UI in Blender
- Various fixes, tweaks etc
Results:
- Binary reading works
- Vastly improved animation support
- Some fixes to avoid busting up the scene hierarchy and to be more or less compatible with the fbx exporter
- Fix logging for the FBX importer
- Integrate import settings into the Blender UI
- End user documentation for the importer
- GSoC 2012 is over, but work will continue :-)
