Casting RT Structs

[Tom Browder]

If I have a 'struct rt_comb_internal' pointer (say, combp):

 1. How do I confirm it's a region?

      I believe I test combp->region_flag for truth.  If it is true,
does that guarantee any regions below it are not acting as regions?

 2. If it's possible, how do I manipulate combp to get to its region pointer?

Thanks.

-Tom

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Butler, Lee Mr CIV USA USAMC]

You have the right test.  Unfortunately, it does not guarantee *symantic* correctness.  A user can union a region below another region.  It's wrong but possible.  Now subtracting a region from another region is often worth doing.

As for converting to a struct region, my (very) vague recollection is that this is performed during prep time.

One question is:  Where did you get the rt_comb_internal?

Lee

----- Original Message -----
From: Tom Browder <tom.browder@...>
Date: Tuesday, August 26, 2008 15:49
Subject: [brlcad-users] Casting RT Structs
To: brlcad-users@...

> If I have a 'struct rt_comb_internal' pointer (say, combp):
>
> 1. How do I confirm it's a region?
>
>      I believe I test combp->region_flag for truth.  If it is true,
> does that guarantee any regions below it are not acting as regions?
>
> 2. If it's possible, how do I manipulate combp to get to its
> region pointer?
>
> Thanks.
>
> -Tom
>
> -------------------------------------------------------------------
> ------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challengeBuild 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 Users mailing list
> brlcad-users@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-users

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Christopher Sean Morrison]

 
>If I have a 'struct rt_comb_internal' pointer (say, combp):
>
> 1. How do I confirm it's a region?
>
>      I believe I test combp->region_flag for truth.  If it is true,
>does that guarantee any regions below it are not acting as regions?

That is the field to check, but it does not guarantee that there are not other regions.  As Lee mentioned, any combination node in the hierarchy can be marked as a region.  Some are really bad practice, some are perfectly fine.  Technically, though, they can be anywhere.  It's up to the application to check for good behavior (e.g., that there is only one positive region down all paths through the directed acyclic graph).

> 2. If it's possible, how do I manipulate combp to get to its region pointer?

Presuming you mean get a "struct region"?  Those are stored in a ray trace instance (rtip) so you'll have to have some portion of the model loaded and prepared for ray-tracing (even if you don't shoot a ray).  With the rtip and the name of the region, you can call rt_getregion(rtip, name) to get a struct region for that region.  There are a variety of other ways as well, just depends what you're trying to do and what you already have.

Cheers!
Sean

p.s. For future reference, coding questions like this should really be sent to brlcad-devel instead of brlcad-users.



-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Tom Browder]

On Tue, Aug 26, 2008 at 3:29 PM, Butler, Lee Mr CIV USA USAMC
<lee.butler@...> wrote:
> You have the right test.  Unfortunately, it does not guarantee *symantic* correctness.  A user can union a region below another region.  It's wrong but possible.  Now subtracting a region from another region is often worth doing.

Yep, we've done that before.  But is it correct to say the first
region on a path is the "real" region?

> As for converting to a struct region, my (very) vague recollection is that this is performed during prep time.
>
> One question is:  Where did you get the rt_comb_internal?

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.

Thanks, Lee.

-Tom

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Tom Browder]

On 8/26/08, Christopher Sean Morrison <brlcad@...> wrote:
>
> >If I have a 'struct rt_comb_internal' pointer (say, combp):
> >
> > 1. How do I confirm it's a region?
> >
> >      I believe I test combp->region_flag for truth.  If it is true,
> >does that guarantee any regions below it are not acting as regions?

But at least that should be the "top-level" or parent region (the
first from the top) on that path, though, right (using db_tree_walk)?

 > > 2. If it's possible, how do I manipulate combp to get to its
region pointer?
>
> Presuming you mean get a "struct region"?  Those are stored in a ray trace instance (rtip) so you'll have to have some portion of the model loaded and prepared for ray-tracing (even if you don't shoot a ray).  With the rtip and the name of the region, you can call rt_getregion(rtip, name) to get a struct region for that region.  There are a variety of other ways as well, just depends what you're trying to do and what you already have.

See answer to Lee's reply for how I got the combp.  Any way to get the
struct region from there?

Thanks, Sean.

-Tom

> p.s. For future reference, coding questions like this should really be sent to brlcad-devel instead of brlcad-users.

Will do.

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Christopher Sean Morrison]

> 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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Tom Browder]

On Tue, Aug 26, 2008 at 9:18 PM, klaatu <klaatu@...> wrote:
>
> Greetings Mr Browder,
>
> You may or may not remember me, I first got and built BRLCAD back in maybe
> 1997 or so. How time flies!

If I remember correctly, you were interested in using BRL-CAD to build
a model of your house, or some other similar structure (I seem to
remember a discussion about duplicating wall studs for framing).  Were
you successful?  Maybe Sean could use it in the Gallery.

-Tom

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Tom Browder]

On Wed, Aug 27, 2008 at 2:12 AM, Christopher Sean Morrison
<brlcad@...> wrote:
>
>> 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.
...
> 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).

Well, what I really want during this walk is to enter at a tree top
(say 'all') and list every positive region under it (no dups).  For
each region i want all its attributes.

That's it.

Thanks, Sean.

-Tom

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Daniel Roßberg]

2008/8/27 Tom Browder <tom.browder@...>:
> Well, what I really want during this walk is to enter at a tree top
> (say 'all') and list every positive region under it (no dups).  For
> each region i want all its attributes.

As a starting point you may look at the rt^3 repository at
    http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/include/brlcad
and
    http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/coreInterface

With the code you find there you can walk down the tree and ask every
object if it is a region.  Don't hesitate to ask if you have problems
with this code.


Regards,
    Daniel

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Browder Jr, Thomas M]

>-----Original Message-----
>From: brlcad-devel-bounces@...
>[mailto:brlcad-devel-bounces@...] On Behalf
>Of Daniel Roßberg
>Sent: Wednesday, August 27, 2008 07:16
>To: Tom Browder
>Cc: brlcad developers; brlcad-users@...
>Subject: Re: [brlcad-devel] [brlcad-users] Casting RT Structs
>
>2008/8/27 Tom Browder <tom.browder@...>:
>> Well, what I really want during this walk is to enter at a tree top
>> (say 'all') and list every positive region under it (no dups).  For
>> each region i want all its attributes.
>
>As a starting point you may look at the rt^3 repository at
>    
>http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/incl
>ude/brlcad
>and
>    
>http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/
>coreInterface
>
>With the code you find there you can walk down the tree and
>ask every object if it is a region.  Don't hesitate to ask if
>you have problems with this code.

Thanks, Daniel, I'll check it out!

-Tom


-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[klaatu-2]

On Wed, 27 Aug 2008, Tom Browder wrote:

> On Tue, Aug 26, 2008 at 9:18 PM, klaatu <klaatu@...> wrote:
>>
>> Greetings Mr Browder,
>>
>> You may or may not remember me, I first got and built BRLCAD back in maybe
>> 1997 or so. How time flies!
>
> If I remember correctly, you were interested in using BRL-CAD to build
> a model of your house, or some other similar structure (I seem to
> remember a discussion about duplicating wall studs for framing).  Were
> you successful?  Maybe Sean could use it in the Gallery.

Well, see http://earthops.org/guitar/ and click any link in the left
column, the images were done with BRL-CAD for the guitar head and neck,
and the labelling was done with XPaint, I seem to recall.

Probably not suitable for widespread publication <evil grin> and
unfortunately various crashes and re-installs have lost the db.g for most
everything I ever did, but http://earthops.org/PrettyRoom.gif is some
cheesy anime stolen off the web laid on top of the output of the little
script I used to lay out the studs, etc.

One of these days, I may actually organize some of my files from the
archivable days, and if so I will send it up to the Wiki.

Cheers,



-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Doug Gwyn (CISD)]

Classification:  UNCLASSIFIED
Caveats: NONE

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

It appears that somewhere along the way, BRL-CAD has been made to
implement only the old GIFT structures rather than the more general
combinatorial geometry that was meant to replace them.  Far from
being "bad practice", the user really ought to be able to subtract
*any* object geometry from any other in the course of modeling,
without having to perform any additional work himself.  Also, what
happens when you subtract a region that itself contains a (nested)
subtraction?  The software really ought to "optimize" the tree
structure to produce a canonical form, if it requires such a form
for evaluation.
Classification:  UNCLASSIFIED
Caveats: NONE



-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Christopher Sean Morrison]

 
On Thursday, August 28, 2008, at 12:02PM, "Gwyn, Douglas (Civ, ARL/CISD)" <gwyn@...> wrote:

>> 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".
> [..snip..]
>
>It appears that somewhere along the way, BRL-CAD has been made to
>implement only the old GIFT structures rather than the more general
>combinatorial geometry that was meant to replace them.  Far from
>being "bad practice", the user really ought to be able to subtract
>*any* object geometry from any other in the course of modeling,
>without having to perform any additional work himself.  Also, what
>happens when you subtract a region that itself contains a (nested)
>subtraction?  The software really ought to "optimize" the tree
>structure to produce a canonical form, if it requires such a form
>for evaluation.

BRL-CAD does implement generalized boolean logic on the hierarchy -- that hasn't changed.  It's usually 'bad' but IS still considered completely 'valid'.  We don't warn or otherwise even complain for that very same reason that you point out.  The performance issue could very well (sometimes) be automatically resolved through optimizations, null object detection, tree simplification, and a variety of other measures.

It's no more "bad yet still valid" than it is using a half-space to perform cutaways when the modeler could have used an arb8 instead.  It'll certainly work and is entirely valid, but it's considered bad practice solely for implementation/performance/semantic reasons.

Whis is completely different from the "bad and invalid" situation where you maybe try to union two different regions or add an existing region to another region (creates an overlap or undefined material configuration).

Subtracting regions with nested subtractions is not a problem in the least and should even be optimized accordingly to not evaluate that portion of the hierarchy if a larger overlapping segment of the ray was already culled.  That said, that same optimization causes really obscure numeric instability on some fairly complicated cases, but most of the time we enjoy a nice performance boost.  There was a GSoC suggested project to look into fixing that problem (and implementing other CSG optimizations like you've suggested), so maybe next year someone will pick it up.

Cheers!
Sean



-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users

[Christopher Sean Morrison]

For those following this thread, I responded to Tom's message with an implementation posted to the brlcad-devel mailing list.  I just don't want to keep cross-posting the development chatter to the users list so it was only sent there.  If anyone is interested in subscribing to the developer mailing list and needs help getting set up, please e-mail me back off-list.

Cheers!
Sean
 
 
On Wednesday, August 27, 2008, at 07:02AM, "Tom Browder" <tom.browder@...> wrote:

>On Wed, Aug 27, 2008 at 2:12 AM, Christopher Sean Morrison
><brlcad@...> wrote:
>>
>>> 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.
>...
>> 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).
>
>Well, what I really want during this walk is to enter at a tree top
>(say 'all') and list every positive region under it (no dups).  For
>each region i want all its attributes.
>
>That's it.
>
>Thanks, Sean.
>
>-Tom
>
>

-------------------------------------------------------------------------
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 Users mailing list
brlcad-users@...
https://lists.sourceforge.net/lists/listinfo/brlcad-users