Start a new topic

## mgGetBounds

Original Post by: spoulin Tue Mar 30 19:49:13 2010

Hi,

Does mgGetBounds actually calculate the bounding box for a node or does it return the current bounding box value for that node, i.e. the values entered last time "Calculate" was clicked in the bounding volume tab for that node? Basically, what I'm trying to do is to temporarily detach certain parts of a model to calculate a new bounding volume. Can I achieve this with mgGetBounds with the top-most node or do I have to combine every bounding box found in the model?

Thanks

1 person has this problem

Original Post by: ChrisRogers Tue Mar 30 20:19:16 2010

Hi spoulin,

mgGetBounds calculates the bounding box for a node every time. It is completely separate from the bounding volume for a node. You could detach nodes then run mgGetBounds to calculate your bounding box for you, however I think using the mgboxd and mgBoxExpandCoord3d functions would be less complicated and more readable. You could simply walk the nodes you want to calculate the bounds for (including vertices) then just expand your box with all the vertices that you find.

Original Post by: spoulin Tue Mar 30 20:27:13 2010

Indeed, the mgBoxExpandCoord3d solution is much better! Thanks.

Original Post by: ChrisRogers Tue Mar 30 20:39:39 2010

The only thing to worry about with the expand coord3d version, is you want to set your box up properly before hand. The best way to do this is to set the box min and max to be equal to one of the vertices. This is not always practical, so sometimes I set the box up like so:

`mgboxd box;box.min = mgMakeCoord3d (FLT_MAX, FLT_MAX, FLT_MAX);box.max = mgMakeCoord3d (-FLT_MAX, -FLT_MAX, -FLT_MAX); `

I'm not sure if a box is constructed initialized like that, so I always set it to be sure. This code sets the box's minimum value to the largest possible point, and the maximum value to the smallest possible point. You need to #include <float.h> in order to use the FLT_MAX constant.

Original Post by: spoulin Thu Apr 1 13:18:30 2010

I've got a question using mgBocExpandCoord3d and mgWalk. The nodes I'm trying to eliminate are DOF nodes and everything included below them. First, does mgWalk traverse the hierachy branch by branch or there is no specific order? Second, if the former is true, does mgWalk stop traversing a branch or completely stops traversing when MG_FALSE is returned by the mgwalkfunc? If not, how do I stop mgWalk from going through the nodes under a specific node? The only thing I can think of is to recursively check for a node's parent and if I hit a DOF node I won't process it.

Original Post by: SteveThompson Thu Apr 1 15:18:43 2010

First, does mgWalk traverse the hierachy branch by branch or there is no specific order?

mgWalk traverses the hierarchy using a depth first traversal. See the attached image to see what that means.

Second, if the former is true, does mgWalk stop traversing a branch or completely stops traversing when MG_FALSE is returned by the mgwalkfunc?

If your pre- or post-action function returns MG_FALSE, the entire traversal is stopped, not just the traversal on that branch. If your preaction function returns MG_FALSE, the traversal is stopped before visiting the node's children. If your post action function returns MG_FALSE, the children have already been visited and the traversal stops before visiting the "next" sibling (if any) of the node.

If not, how do I stop mgWalk from going through the nodes under a specific node? The only thing I can think of is to recursively check for a nodeÃ¢â¬â¢s parent and if I hit a DOF node I wonÃ¢â¬â¢t process it.

You cannot get mgWalk to do this automatically. Your walk function will have to "know" to ignore nodes (somehow). You could put a test in your walkfunc that determines if the node is a descendant of a DOF by looking up the parent chain as you suggest but that might be a bit slow. You could also keep track in your walk function of how many DOF nodes are in the current ancestry. Something like this:

`struct walkinfo {   int dofCount;}walkinfo w;w.dofCount = 0;static mgbool Pre (mgrec* db, mgrec* parent, mgrec* rec, void* userData){   walkinfo* w = (walkinfo*) userData;   if (mgGetCode(rec) == fltDof) {      // starting to traverse into a DOF      w->dofCount++;   }   if (w->dofCount <= 0) {      // no DOF in rec's ancestry, can process it   }   else {      // w->dofCount DOFs in rec's ancestry, ignore it   }   return MG_TRUE;}static mgbool Post (mgrec* db, mgrec* parent, mgrec* rec, void* userData){   walkinfo* w = (walkinfo*) userData;   if (mgGetCode(rec) == fltDof) {      // just finished traversing a DOF and its children      w->dofCount--;   }   return MG_TRUE;}mgWalk (db, Pre, Post, &w, flags);`

Note that I did not compile this code so I can't vouch for it absolutely but it gives you the idea.

And of course there are many other creative programming options -- all up to you -- that's what makes software design so FUN!!

Original Post by: spoulin Thu Apr 1 15:48:05 2010

And of course there are many other creative programming options -- all up to you -- that's what makes software design so FUN!!

Hehe true but I like your solution :P

Thanks for info!

Original Post by: spoulin Thu Apr 1 18:24:10 2010

Hi again,

Everything works fine but the shadow vertices are messing up my results. I'm trying to filter them out but mgGetAttList with fltObjShadow on a fltObject is returning 0 attributes retrieved. How do I determine if an object is a shadow?

Original Post by: ChrisRogers Thu Apr 1 18:34:24 2010

It sounds like how you are doing it is correct. You call mgGetAttList on the fltObject node and it fills in the mgbool value you pass in. Are you sure the rec you are passing in is the fltObject node? Can you post a snippet of your code so we can take a look?

Original Post by: spoulin Thu Apr 1 18:41:28 2010

My bad, forgot the "&" before the variable...

Original Post by: ChrisRogers Thu Apr 1 18:48:03 2010

Happens to the best of us. I always do a quick search on all my mgGetAttList calls to make sure all the &s are there and that the MG_NULL is there. It is very easy to leave one out. I also like to double check the types with the expected type from the data dictionary. Just in case.