<div dir="ltr">On Sat, Aug 17, 2013 at 3:54 PM, David Jeske <span dir="ltr"><<a href="mailto:davidj@gmail.com" target="_blank">davidj@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><br></div><div class="gmail_extra"><div class="gmail_quote"><div>This is interesting and goes far beyond what I was thinking with plane-constraints (though not necessarily in a complex way). </div>
<div><br></div><div>If there were a mechanism for specifying persistent constraints between trackers and 3d-models WRT camera-solving, it might also be practical to use this to handle origin/floor/scale as well. (current origin/floor/scale is frustrating, as they are not persistent constraints but actions which need to be repeated after every camera solve)</div>
</div></div></div></blockquote><div><br></div><div>It is conceptually quite easy, and in fact the easiest implementation is the most general one: a scene graph solver. But I don't know much about the implementation of the scene graph in Blender, and if it's not designed so to compute a function between any two nodes (and between any attributes of two nodes) it may be hard to do it in practice. </div>
<div><br></div><div>Start with the simplest case: the point constraint. You have one (possibly animated) 3D point P(t) which is the solution of a track. Call it a "bundle", because It is theoretically the intersection of a bundle of rays going through it an the camera centers at each frame in the track. Let it be an object in the scene graph, whose attributes are its coordinates X(t),Y(t), Z(t) at each frame time t, defined with respect to some parent transform node. </div>
<div><br></div><div>Now, the important thing is that the bundle's coordinates are used to compute the re-projection error w.r.t. the tracks, which drives the solver, but are not necessarily the unknowns solved for by the solver itself. In fact, the unknowns we want to solve for could be something completely different elsewhere in the scene graph. To get a solution it is necessary that a "solvable" relationship exists between the two. In the simple example of my previous message, the unknowns would be the 6 scalar attributes defining the pose and location of the box (6 functions of time). </div>
<div><br></div><div>To define the above relationship you need a way to "attach" the bundle, which provides the error signal driving the solver, to the unknowns you want to solve for. Consider then another scene graph object representing a 3D point, call it a "point constraint". It has 3 coordinates at each frame as well, but unlike the bundle's they are <i>assigned </i>by the scene graph, i.e they are knowns. For example, if the thing you are solving for is the pose/position of a car, whose shape you have modeled with a mesh, and the track is for the spoke of a wheel, you attach the point constraint to a mesh vertex on the spoke. Now the point constraint's coordinates with respect to the unknowns are well defined. Next, you "attach" the point constraint to the bundle, effectively establishing a relationship in the scene graph that says "this bundle shall have the position of this point constraint". That's it, you are done. Assuming the problem is balanced and solvable (i.e. that you have enough good tracks), the solver will try to find the values of the unknowns that cause the point constraint to drive the bundle to places where the error is small, effectively matching the tracks.</div>
<div><br></div><div>This definition of point constraint neatly separates the modeling of the geometry (which is done with ordinary meshes) from the solver. You don't need to complicate the mesh software with "special" vertices or facets that know about markers and tracks. You only need a 3D point thing (the point constraint) that's under the same parent transform node as the mesh. And this thing, likewise, needs not know about cameras and reprojection errors, it only needs to know how to drive (i.e. "force") the position of another 3D point thing, the bundle, which knows about cameras seeing it and markers reprojecting it (so that it can compute an error term).</div>
<div><br></div><div>Yes, I have left out plenty of details (in particular, how to compute derivatives of the error term in the scene graph), but hope the idea is somewhat clear.</div><div><br></div><div>Ciao</div><div>Franco </div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div>
</div>
</div></div>
<br>_______________________________________________<br>
Bf-vfx mailing list<br>
<a href="mailto:Bf-vfx@blender.org">Bf-vfx@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-vfx" target="_blank">http://lists.blender.org/mailman/listinfo/bf-vfx</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Franco Callari <<a href="mailto:fgcallari@gmail.com">fgcallari@gmail.com</a>><br><br> EC67 BEBE 62AC 8415 7591 2B12 A6CD D5EE D8CB D0ED<br>
<br>I am not bound to win, but I am bound to be true. I am not bound to succeed, but I am bound to live by the light that I have. (Abraham Lincoln)
</div></div>