On Sep 4, 2013, at 12:51 AM, phoenix wrote:
> Agreed. But a tree leaf can have that info (a db_i pointer), and tr_a does
> have (for OP_SOLID, but it doesn't exist for a comb).
I presume you mean through tr_a->tu_stp->st_rtip->rti_dbip? A soltab is a bit
of a special case because they're tied to a raytrace instance (for prep) which
by definition are tied to a dbi (which can even be memory-only).
> Is it a good idea to add a dbip to struct tree_db_leaf (defined below)?
>
> struct tree_db_leaf {
> uint32_t magic;
> int tl_op; /**< @brief leaf, OP_DB_LEAF */
> matp_t tl_mat; /**< @brief xform matp, NULL ==>
> identity */
> char *tl_name; /**< @brief Name of this leaf
> (bu_strdup'ed) */
> } tr_l;
There is space for one more pointer without increasing the union size due to
tr_b's three pointers, but I'm not convinced the information you need isn't
already available through a different method. The combined_tree_state in tr_c,
for example, keeps track of directory pointers, for example.
Moreover stashing a dbip into every union tree node just seems wrong.. it'd be
the same pointer on every node. It'd seem more feasible to change tl_name to
something else (like a directory pointer), but would have to look at all the
places it's used. I see you've kept the dbip argument to your callback, so
perhaps moot for now.
Sorry, I don't have an obvious answer. This all requires more research.
Cheers!
Sean
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
