#189 rt doesn't get geometry path right

unexpected behavior
closed-fixed
Raytrace (49)
5
2009-07-17
2008-11-13
Lee Butler
No

When displaying a portion of a tree using a path using the "e" command, a raytrace produces an image of the entire scene.

Example:
start with a new geometry file.

mged> in box rpp 0 1 0 1 0 1
mged> r box.r u box
mged> in ball sph 0 0 0 1
mged> r ball.r u ball
mged> g all box.r ball.r
mged> Z
mged> e all/box.r
mged> rt

Only the box.r region is displayed in the mged window. The raytrace shows both the ball and the box, and reports numerous overlaps.

Discussion

  • Cliff Yapp

    Cliff Yapp - 2008-11-15

    This is due to a problem with how the dgo_rt_cmd is building its list of visible objects. When it calls dgo_build_tops, dgo_build_tops is returning all. It's not quite clear if this is expected behavior for this function - it looks like it might be, since the documentation for dgo_build_tops says "build a command line vector of the tops of all objects in view." Whether or not this behavior is useful, it is clearly not what is needed for this case.

    What is needed is a function that will report back all objects in view whose children are all visible and either have no parent or have a parent with children that are NOT all visible, using full path to be able to correctly handle both box.r and all/box.r being drawn simultaneously - i.e. to be able to treat box.r and all/box.r as distinct objects for the purpose in question. As a byproduct of looking for this logic already implemented, it turns out the who command has the same problem - who on the test situation above returns "all".

    So, this is actually NOT a problem with the core rt code - command line rt file.g all/box.r does what is expected. The problem is introduced in the dgo_rt_cmd and is also present in the who command logic, suggesting perhaps a different who command is called for that is used both as "who" and as the command to populate the dgo_rt_cmd argument list.

    This is something search or a more specialized subset of search could handle given a way to determine if a given object is being displayed - e.g. "object, are you drawn?" and using the above and below options. A better way would be for MGED to "know" what has been drawn by simply storing a list of what is visible and having commands that draw and erase update the list - I had assumed that was what was already going on but if so I haven't found the central view list yet.

     
  • Cliff Yapp

    Cliff Yapp - 2008-11-17

    OK, digging deeper it looks like the solid list MGED is maintaining is comprised of only the full paths to the geometric shapes making up the various objects - e.g. draw all results in all/box.r/box being stored in the solids list. Unfortunately, this means the solids list is NOT retaining information about what the user actually told it to draw - just the results in terms of displayed shapes. So long as no one ever requested an object INSIDE a tree without also requesting the whole tree, always looking at the first name on the full path was enough.

    The fix I have in mind right now is to implement a routine that will take the first solid in the list, get its path and remove the last (solid) object, then check to see if ALL the children of the new last object in the path are present in the solid list. If they are, pop another combination and try it again with all children except the one just cleared, if not return the original path since it specifies a drawn item that was specified using that path and not as part of a draw command on a node further up the tree. Probably the thing to do is make a copy of the solid list and remove confirmed items from it to avoid duplicate checking, if that can be done without too much trouble. Once the minimum inclusive path is found (usually this will be the root node of the full path - if no commands like all/box.r are used it should alway be the root node) append it to the rt command string.

     
  • Cliff Yapp

    Cliff Yapp - 2008-11-17

    Per discussion with Sean:

    The "correct" fix for this is to actually start tracking what the user has requested, rather than trying to deduce it from the solids list. This will involve some work at the libged level, which is still in a state of flux - as part of the libged effort we will need to incorporate tracking what the user has requested in addition to the list of primitives. Once we do, that list should be used for things like who and calls to rt.

     
  • Bob Parker

    Bob Parker - 2009-07-17

    This issue has been resolved in the latest (unreleased) version of the source code. Thank you for bringing the issue to our attention! You're welcome and encouraged to test and make sure this issue is resolved after the next source release of BRL-CAD.

     
  • Bob Parker

    Bob Parker - 2009-07-17
    • milestone: --> unexpected behavior
    • assigned_to: nobody --> bob1961
    • status: open --> closed-fixed
     
  • Bob Parker

    Bob Parker - 2009-07-17

    The fix utilizes a display list of the things requested by the user where each display list item has its own solid list.

     

Log in to post a comment.