> Yep, we've done that before. But is it correct to say the first
> region on a path is the "real" region?
If it's the first "positive" region, yes. The region can't be part
of a subtraction and you can't just check his parent combination.
You have to check all the way up the hierarchy (until you encounter a
subtraction) to make sure it's not part of a subtraction.
What happens in practice (and it is bad practice, but it happens
often enough that it usually has to be dealt with) is that the
modeler may subtract a region or combination containing a region from
some higher-level assembly in order to eliminate some overlap problem
as seen in this example hierarchy:
u toplevel_group
u body_assembly
u left_body.r
- engine_assembly
u top_engine.r
u inner_engine.r
u ...
u right_body.r
u internal_components
u engine_assembly
u top_engine.r
u inner_engine.r
u ...
u armor_assembly
u ...
Here, the modeler subtracts the engine_assembly from the left_body.r
region in order to (presumably/usually) remove an overlap between the
engine and the body. Instead of figuring out exactly what regions
are involved in the overlap, the modeler took the easy route out and
just subtracted the entire region. This is generally very bad
practice (usually due to performance), but it happens and it's still
considered "valid".
When traversing the hierarchy, one of the paths to top_engine.r is
toplevel_group->body_assembly->engine_assembly->top_engine.r .. which
is not a "positive" region, it's a negative one since engine_assembly
is subtracted within body_assembly.
What you said is, however, true for all positive regions. If it's a
union or a non-null intersection, then it'll have some mass.
> It comes from a function used by db_tree_walk for region starts.
> Function args to db_tree_walk include:
> rtip->rti_dbip, // database instance
>
> The args to the region_start function:
> struct db_tree_state* /* tsp */,
> struct db_full_path* pathp,
> const struct rt_comb_internal* combp,
> genptr_t client_data
>
> Inside this function is where I would like to get the struct region
> if possible.
Aha, much easier to work with. You have several options available
with the tree walker. The tree state may actually already have in it
what you're wanting from the region structure. It includes much of
the same information (regionid, aircode, los, and more). If it
doesn't have what you need, though, you can get a region structure
within db_walk_tree's reg_end_func() callback via curtree->tr_regionp.
You could also get at it via the rtip directly/manually (not
recommended) by iterating over the regions (which are stored in the
rtip -- can use tsp->ts_rtip). Similarly, you could use one of the
other tree walkers that maintain a union tree during the walk (where
again you'd just use tree->tr_regionp).
I'd be careful that you're not getting lost in the forest, though.
What is it that you're actually trying to accomplish with the tree
walk? What data are you needing to get at? The region structure
itself might not really be what you should be using as it is intended
to be an in-memory raytrace structure (hence the trivial access via a
hit() callback).
Cheers!
Sean
p.s. apologies, the rt_getregion() call I mentioned previously is
actually a static function, so it's not available to you though it is
an example of iterating over the rtip regions that I mentioned.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
