well still waiting for some eyes on this approach of mine..

On 7/16/13, check.nyah <[email protected]> wrote:
> Hi,
>
> 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".
>
> Currently Writing the ged_pull() with the following as subroutines:
>
> *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.]
>
> *Working on a loop which From the tail of the list[leaf] moves upwards
> towards the head performing an inverse matrix operation until I
> encounter another leaf(whose matrix tranformation is now used for
> inverse operation) after originally setting the matrix transformation
> of the old_leaf to identity and continues performing the matrix
> inverse storing them up the node till its reaches then head.
> [CURRENTLY WORKING ON THIS NOW..]
>
> * Later on I move down the linked list from the head making all these
> new changes(new matrix transformations) to database; which is similar
> to the do_identize() and identitize() loops seen in the push routine.
>
> * free up build linked list( as in the push )
>
> * then returns status (GED_ERROR or GED_OK)
>
> 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(
> Since I think this will cut through the process of dealing with
> individual primitives when accessing each node from the database.)? if
> not any suggestions or amendments to make to this method? Since i know
> the matrix transformations for any path are cummulatively stored at
> the leaves of that path; which could easily be recovered by performing
> an inverse.
>
>
> Thanks for the assistance. :)
>
> Cheers!
>
> Nyah
>

------------------------------------------------------------------------------
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

Reply via email to