2015-09-14 22:13 GMT+02:00 Christopher Sean Morrison <brl...@mac.com>:
>
> On Sep 14, 2015, at 5:09 AM, Daniel Roßberg <danielmrossb...@gmail.com> wrote:
>
>> And in a first test I was able to analyse my geometry this way.
>> However, setting a_no_booleans to 1 seems to have the same effect:
>> a_hit is called for every region of an overlap. Is this
>> intentionally? What's the purpose of a_no_booleans?
>
> Not intentionally… the a_no_booleans flag was added a long time ago for the
> solids_on_ray command as a simple way to figure out what solids are along a
> given shotline. It tells the boolean weaver to just treat all segments as
> separate objects so that segment == partition, with no merging or boolean
> evaluation occurring. Everything just gets returned.
OK, then it worked by chance only because in my test model every
region has exactly one solid and I looked explicitly for the hits on
regions (pt_regionp of the partition).
>> How should a simple a_multioverlap look like? rt_default_overlap() is rather
>> complex, starting with FASTGEN region checks.
>
> Usually something like:
>
> void my_overlap(struct application *ap, struct partition *pp, struct bu_ptbl
> *regiontable, struct partition *InputHdp) {
> /* do whatever you want */
> return rt_default_multioverlap(ap, pp, regiontable, InputHdp);
> }
> :)
>
> If you really don’t want the default handler to do things for you, just skip
> over the big fastgen-compatibility block (look for the "Examine the
> overlapping regions, pairwise” loop). You’ll iterate over the region table
> and apply any behavior you want. You can see an extra-simplified version
> that just print the overlap in rt_silent_logoverlap().
I like the "do whatever you want" part :) rt_silent_logoverlap() is
really extra-simplified, however what I did looks very similar to the
middle (and main) part of rt_default_logoverlap(). The call of
rt_default_multioverlap() at the end should be unnecessary in my case
because I don't want any additional call of a_hit and that's why reset
the region table.
Regards,
Daniel
------------------------------------------------------------------------------
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
