oed command

  • Wayne Gramlich
    Wayne Gramlich


    I am new to BRL-CAD and I think I am getting the hang of it.

    I have been trying to figure out how to move objects around
    in BRL-CAD from the command line.  I have figured out how to
    use "sed", "tra", and "accept" to move solid objects around,
    but I can not figure out how to that to assemblies and parts.

    Could somebody explain how the oed works?   The explanation
    at the end of VolumeII is just to brief for me to figure
    out and it just baffles me.

    Any help would be appreciated.


    • David Loman
      David Loman

      I am in the middle of a project that entails heavy use of matrix manipulation of assemblies/groups and parts/regions.  I will do my best to explain the oed command.  As a side note, the menu selections:  Edit ->  Matrix Selection performs the same function as the oed command.

      Basically, Matrix selection and manipulation consists of selecting two items:
      1) An 'anchor' object (Region, Combination or Solid)
      2) A collection (Region or Combination ) that you wish to edit.

      Generally speaking, the anchor object MUST be somewhere in the hierarchy below the desired Collection you want to edit.

      Example of an aircraft:

          path from top most object to solid level of the objects currently displayed:

          Where all, skin, and upper are all Combinations, cowling02.r is a region and cowling156.s is a solid.  A 'B all' command was used to place the 'all' object on the MGED display.

          To use the oed command in this example, you need to specify a complete path from top level to solid level but split the path at the point you wish to edit.

          Example #1:

          B all

          oed all/skin  /upper/cowling02.r/cowling156.s
              will put the object 'upper' in to edit mode using cowling156.s as the 'anchor' object.

          oed skin  /upper/cowling02.r/cowling156.s
              will give the error:  "Unable to find solid matching path" because 'all' is the topmost displayed object.

          Example #2:

          B skin

          oed all/skin  /upper/cowling02.r/cowling156.s
              will give the error:  "Unable to find solid matching path"  because 'skin' is the topmost displayed object.

          oed skin  /upper/cowling02.r/cowling156.s
              will put the object 'upper' in to edit mode using cowling156.s as the 'anchor' object.

      Hope this helps!

      -Dave Loman

    • Wayne Gramlich
      Wayne Gramlich

      Thanks for your excellent description of oed, it is
      much clearer how it works now.

      I'm getting closer.  I may have a slightly different problem now.

      I have an object (call it wheel.r) and I would like to put
      four copies of it in my design.

      My first crack at is something like this...

      mged> g wheel1 wheel.r
      mged> g wheel2 wheel.r
      mged> g wheel3 wheel.r
      mged> g wheel4 wheel.r
      mged> g body wheel1 wheel2 wheel3 wheel4
      mged> g body

      Now I want to move the wheels around:

      mged> oed body/wheel1/wheel.r
      mged> tra .5 2 0
      mged> accept
      rt_nul_plot unimplemented

      Ok, BRL CAD is unhappy, but I don't know why.  Any ideas?

      Any help is appreciated.


    • David Loman
      David Loman

      Okay, first of all, MGED / BRLCAD is very very picky about the differences between 'copying' and 'instancing'.  They are vastly different.  Unless you use a command like 'cp', 'mirror', etc that implicitly makes a NEW copy of the object/collection you are working with, then you are using an instance. 

      What you have done with /wheel.r is actually not copying it, but rather referencing /wheel.r from four different places.  Now this is not a bug, but rather a feature that helps reduce file size for a BRLCAD model and a feature that simplifies construction.  However, it has major drawbacks.  In the situation you have described, if you set up to edit /wheel1 then a matrix will be applied at the /wheel1 level.  /wheel.r remains in the exact same position.

      If you:   'e wheel.r'    then you will see /wheel.r at its original position, however if you:   'e wheel1'   then you will see /wheel1/wheel.r at the newer position since /wheel.r is viewed through the matrix applied to /wheel1.

      Now you can keep applying matrixes to /wheel2, /wheel3, /wheel4, etc all while keeping /wheel.r unchanged and in the same position as normal.

      In steps the 'push' and 'xpush' commands.  These can be very destructive to a model should you not know what you are doing!  I make a habit of making a copy of my .g file about once every 10 minutes when I am doing massive changes as there is no 'undo' command in MGED.

      The 'push' command will take any matrixes applied and push them down to the solid level, changing the solid itself to reflect the newer position spelled out by the matrix.  Normally, this is a good thing, except for the situation you have spelled out above.  If /wheel1 was the only collection to reference /wheel.r and a matrix was applied to /wheel1, then /wheel1 could be safely 'push'-ed and the solids inside /wheel.r would be modified.  This is an excellent way to eliminate no longer useful matrix transformations in a given branch of the geometries hierarchy. 

      Where this becomes a major issue is when you have multiple collections referencing the same object, as you have with your /wheel[1-4] referencing /wheel.r.  If you were to have difference matrixes applied to /wheel[1-4], then all those matrixes are based on /wheel.r's current position.  If you were to 'push'  /wheel1 then /wheel.r would realign to the position spelled out by the matrix applied to /wheel1.  The issue is that matrixes are not anchored to a specific object, aka, once you pushed /wheel1, then the matrixes on /wheel[2-4] wont update, but rather will continue to reflect the same values of change.  Since /wheel.r is in a new position now thanks to the 'push' on /wheel1, /wheel[2-4] will now appear to be in the completely wrong position!  This where it becomes a major headache to have matrixes in a geometry file.

      The 'xpush' command is very similar to the 'push' command.  Instead of changing the solid level to match any matrixes contained in a hierarchy branch, it makes new solids wherever it runs into the situation where it would need to move something.  In your example, if instead of 'push'-ing /wheel1, you decided to 'xpush' /wheel1, then /wheel.r will remain unaffected and /wheel.r_01 will be created by 'xpush'.  If you 'l wheel.r_01' then you will see a "_01" is appended to all the solids in that region.  What xpush did was make a copy of the region /wheel.r and all the solids referenced inside them (yes even the intersections and subtractions) and them moved them to the new locations spelled out by the matrix that was applied to /wheel1.

      One way to attack the wheel problem:
      1)    Spend a fair amount of time on /wheel.r and make sure it is exactly what you want.
      2)    Move it into the front passenger side position.
      3)    I try to avoid using numbers since every person will want to number differently.  Since the 16 character limit for MGED names is long since gone, I use descriptive names.  Now I would:

              g wheel_front_right wheel.r
              g wheel_front_left wheel.r
              g wheel_rear_right wheel.r
              g wheel_rear_left wheel.r

      4)    use oed or EDIT->Matrix Selection and move /wheel_front_left, /wheel_rear_right and /wheel_rear_left into position.  Now there should be matrixes applied to 3 of the 4 wheels.
      5)    now xpush the 3 wheels:

              xpush wheel_front_left
              xpush wheel_rear_right
              xpush wheel_rear_left

      6)    If you use the command:

              l wheel.r*

          then you should see the contents of /wheel.r, /wheel.r_01, /wheel.r_02 and /wheel.r_03

      7)    Now I would go through and use the 'mvall' command and rename all the _0* names to more descriptive names, but its definitely not necessary… I am a bit of a perfectionist and like things neat and orderly :)

      A second way to attack the problem would be to make /wheel_front_right and /wheel_rear_right, move /wheel_rear_right into position xpush /wheel_rear_right,  then 'mirror' /wheel_front_right to /wheel_front_left and then 'mirror' /wheel_rear_right to /wheel_rear_left.  Then rename all the ugly solid/region names.

      A third way would be to make /wheel_front_right and /wheel_rear_right, move /wheel_rear_right into position, xpush /wheel_rear_right, group /wheel_front_right and /wheel_rear_right into /tempright , then mirror /tempright to /templeft.  Kill /tempright and /templeft and then rename all the ugly solid/region names.

      Any 'mirror' command assumes you are using an axis=0 as your vehicle's centerline.  Convention, as far as I have seen, for BRL-CAD is to use the x-axis as center line, aka +Y is left, -Y is right, +X is forward, -X is backwards, +Z is up, and -Z is down.

      Additional comments:
      I don't see any reason for your command:

          mged> g body

      What are you wanting to group into body?  Did you mean 'B body' or 'e body'?

      As for the error, I am not 100% sure what rt_nul_plot means, let the dev's answer that one, but you can probably get around it by using a method I detailed above.

      Hope this helps!  Feel free to keep posting any questions you might have.

      -Dave Loman

    • Wayne Gramlich
      Wayne Gramlich


      Great help there!!!!

      The last "mged> g body" was a typo.

      As near as I can tell the rt_nul_plot messages seems to be
      a benign warning.  When I finally figured out to redisplay
      the tree, the parts showed up in the correct locations.
      (For some dumb reason, I thought they automatically redisplay
      when I typed accept -- wrong!)

      I would have never figured out push and xpush without your
      explanation.  Thanks.

      The only reason why I used numbers and suffixes is because
      the tutorial said to do that.  I'm with you, longer more
      descriptive names are better.

      Most of the time, I want instances of the same part moved
      around, so I don't think I need use push and xpush right
      away.  But it nice to know how to get at real copy to the
      new location to happen.

      I tend to write programs that compute the locations and
      orientations of everything.  Thus, my insistence on using
      the command line interface instead of the GUI interface.

      Modulo some of the issues you have helped me clear up,
      I have found BRL CAD to have one of the more gentle
      learning curves of any CAD system I have attempted to
      use.  So far, so good.

      Now I have to go off and do some modelling.  I'll be back
      when I run into my next problem!!!!

      Thanks again,


  • Sean Morrison
    Sean Morrison

    Belated reply, but certainly.  See "Object Editing - the oed Command" under http://brlcad.org/wiki/Documentation