Differential D2187
GSoC 2016 - Multiview Reconstruction Authored by Tianwei Shen (hlzz001) on Sep 1 2016, 7:19 PM.
Details This is the patch for the GSoC 2016 project - Multiview Reconstruction for Blender. Project proposal: https://wiki.blender.org/index.php/User:Tianwei37/GSoC_2016_Proposal Weekly progress: https://wiki.blender.org/index.php/User:Tianwei37/Report_%26_Blog User doc: https://wiki.blender.org/index.php/User:Tianwei37/User_Documentation Blog post: http://hlzz.github.io/blender3/
Diff Detail Event TimelineComment Actions Oh wow, that's a huge patch. No wonder it took so long to have even initial review. Only did some quick inline notes and here is the bigger picture notes: Libmv SideSolver Do you have explanation somewhere how's the solver is intended to behave now for the multi-camera case? Does it resect/intesect/bundle all cameras at the current frame at once? What if camera does not exist on the current frame? Biggest thing i'm not sure here is how you managed to use GRIC to find out keyframes for reconstruction. API I do not think we should expose Correspondence idea to the Libmv. Unlike Blender side where we can not have "big picture" in the same entity due to possibly linked nature of ID blocks, in Libmv adding Correspondence only adds extra unneeded entity. We do have Marker::clip to indicate the clip marker belongs to. So basically, in the new auto pipeline all tracks from correspoding tracks from Blender side should go to a single track from Libmv side. Tests We really really really prefer to cover all the code with tests. You should be able to use them from simple pipeline. Duplicated code Is it possible to get rid of some code there since we moved from simple pipeline to a new auto pipeline? Blender sideGeneral notes Even tho this patch seems to include the whole branch, don't see much deletions in there. We should be using new auto pipeline for both single-camera and multi-camera reconstruction. That would be a good test to new API as well. Split the patchThink it should be possible to split patch into smaller areas, such as:
That would make it easier to review and accept patches which could momnetarely be applied to a temp branch when then is merged to master in one go. Users testingDo you have some good non-artificial example of the new feature? Did you get any user feedback on interface and workflow here?
Comment Actions Merge the latest master branch. Hi Sergey, I also felt that the current patch is to big to be merged. I will follow your suggestions and split this patch into several smaller patches that can be not only useful for multi-view camera reconstruction, but also for the automatic feature tracking pipeline. For example, I think removing some duplicated code of simple_pipleine to automatic_pipeline would be a good start. What do you think? | |||||||||||||||||||||||||||||||||