Our LIBGED geometry editing library contains lots of small modular commands that are made available in mged and archer. We'd like to have a command that lets users create and edit polygonal meshes (BoT and NMG).
This task involves stubbing in a new 'mesh' command. It doesn't need to do anything initially other than print a usage statement and actually work in both mged and archer when you run the command. Figuring out the latter is the majority of work for this task, but don't worry -- there are lots of examples to follow.
You'll want to download our latest SVN sources or update the VM image following http://brlcad.org/wiki/Compiling and compile BRL-CAD.
Then make your edits, make sure they compile and work, and submit them as a unified patch file (svn diff my_changes.patch).
References:- src/libged/*.c -- look here for hundreds of examples
- http://en.wikipedia.org/wiki/Polygon_mesh
- Check out some other programs that have a command line interface
- src/libged/mesh.c -- you create this
- src/libged/CMakeLists.txt -- edit this to add your new file
- src/mged/setup.c -- where you hook into mged
- src/libtclcad -- where you hook into archer
- src/tclscripts -- where you hook up a help string
File name/URL | File size | Date submitted | |
---|---|---|---|
task-21-stub-in-mesh.diff | 5.4 KB | December 09 2014 07:52 UTC | |
task-21-stub-in-mesh.diff | 6.0 KB | December 09 2014 15:45 UTC | |
task-21-stub-in-mesh-v2.diff | 6.0 KB | December 10 2014 03:56 UTC |
I would like to work on this task.
This task has been assigned to Andromeda Galaxy. You have 100 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
The claim on this task has been removed, someone else can claim it now.
I would like to work on this task.
This task has been assigned to Andromeda Galaxy. You have 100 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
The first diff was uploaded previously before I fully understood the task; the second one is the correct final one.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
Few issues noted:
I'm addressing the other issues right now; however, for face_description, my original thought was tht it might look something like the way that faces are specified in the get/put representations: {loop1, loop2, ...} where each loop is {v1, v2, ...}.
The work on this task is ready to be reviewed.
Congratulations, this task has been completed successfully.
... it's still work applying some test-driven development principles to actually work through some of the design issues, before spending time implementing a lot of argument parsing that we might need to change regardless. What is written for get/put is highly opaque and implicit. I strongly doubt that would make for an intuitive interface, but I could be wrong. That's the point of working through a few examples. I'd like to see what a simple box would look like in bot and nmg format, then a box with a hole through it for both (the whole creates interior loops for the nmg, but not for the bot. I'll schedule a GCI task for exactly that.