On Jul 16, 2013, at 10:07 AM, check.nyah wrote: > Looking at the way the push routine has been implemented I think I > could follow a similar process with implementing a pull; so here is my > current working plan(model) "looked at the xpush implementation too".
Belated reply but excellent update, Nyah, thanks! I was going to write some belabored concern about how pull is not like push, but then your description actually convinced me it was more similar (implementation-wise) than I'd originally conceived it being. > *Wrote a pull_leaf routine which builds a linked list based on the > object given to be pulled; taking note of leaf nodes present on the > list (so as to be able to do a bn_mat_inverse when moving > in the revere direction); this process sets the matrices of these > non-leaf nodes to identity after comparing them with what is currently > stored. However a non-leaf node I assume which is not identity has not > been pushed so a pull( since a pull cannot be performed on an unpushed > object) so return error message and frees up list(still thinking > whether to ignore this node and continue or not ?)[need some eyes > here.] A non-leaf node may be identity or not. More importantly, you should absolutely be able to pull an unpushed object. Once pushed, the matrix no longer exists. This is no different than directly editing a primitive to make a change. For example, say I have a simple sphere in a combination: sph.r => u sph. The sph.r combination originally has an unset/identity matrix: sph.r(matrix) => [1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1]. The sph primitive has a V parameter that represents it's position, but NO matrix even exists. It's position is: sph(V) => (0,0,0). Say I edit the sphere directly to move it. The sph.r region is still the same, but now V is different: sph.r(matrix) => [1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1] sph(V) => (100,0,0) Now consider sph(V) back at 0,0,0, but instead of directly moving it, we apply a matrix edit to translate it: sph.r(matrix) => [1 0 100 0 0 1 0 0 0 0 1 0 0 0 0 1] sph(V) => (0,0,0) Those two are equivalent. Moreover, the latter is the pull'ed variant of the prior. If I had yet another whatever.c => u sph.r, it would have an identity matrix as well and I could pull that same matrix up a level (making sph.r(matrix) become an identity in the process. Make sense? > This is the approach I am currently following in implementing the pull > routine( which opposes the push). I wish to know if this method is ok( At a glance, your approach seems mostly okay but your approach is very high risk all-or-nothing. I'd like to see you prove that simple basic steps are working perfectly first, like just pulling a matrix up just one level. Or even just pulling a translation component up one level, avoiding linked lists and matrices entirely. They add considerable complexity. Lots that can go wrong and leave you in a debugger for days on end. > Since I think this will cut through the process of dealing with > individual primitives when accessing each node from the database.)? This is unavoidable. You can certainly focus on just handling combinations for now and not primitives (leaf objects). Cheers! Sean ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
