Labeling a MESHMIX part is almost done.
But I'm struggling with automated part-dropping right now...
Might be an macOS issue.
Could you try the code below whether it runs on WIN?
Import the sphere and select a region. After that run the code (there's no warning if you run it without selection which can't work)
This region is used to find its center to drop the part on it.
If it works it should drop number 3 from the default number parts.
For debugging purposes:
- it imports the part as a simple object to check the path.
- it drops a pivot where the part should be placed.
import os import glob import mmapi from mmRemote import * import mm remote = mmRemote() remote.connect() # get path to latest part created in Numbers: path_to_parts_dir = os.path.expanduser("~/documents/meshmixer/libraries/parts/default/Numbers/") list_of_files = glob.glob(path_to_parts_dir +'*obj') # Seems '3' was the latest path_to_latest_part = max(list_of_files, key=os.path.getctime) print (path_to_latest_part) # needs some selection of course sel_ctr = mm.get_face_selection_centroid(remote) (bFound, selFrame) = mm.find_nearest(remote, sel_ctr) mm.clear_face_selection(remote) mmframe = selFrame.get_frame3f() cmd = mmapi.StoredCommands() cmd.AppendActionCommand_DropSolidPartAtPoint(path_to_latest_part, mmframe, 5.0, True) # SOMETHING WRONG #cmd.AppendToolUtilityCommand( "deformType", 1 ) #cmd.AppendActionCommand_UpdateDropPart( mmframe, 10.0, True) remote.runCommand(cmd) # Just to check path and frame3f: cmd = mmapi.StoredCommands() cmd.AppendSceneCommand_CreatePivot( mmframe ) # working cmd.AppendSceneCommand_AppendMeshFile(path_to_latest_part) # working remote.runCommand(cmd) ### A working ActionCommand: ##cmd = mmapi.StoredCommands() ##cmd.AppendActionCommand_InsertPolygon( mmframe.origin_x, mmframe.origin_y, mmframe.origin_z, 0.5 ) # Radius: SceneCoord ##remote.runCommand(cmd) remote.shutdown()
Awesome!
It is dropping a pivot on the selected area, but then also appending a '9' to the scene, not on the sphere but off centre on the ground plane, very very small.
I made a Google Drive folder I can drop into while we test:
https://drive.google.com/drive/folders/1ymYveV0U_bP-E3mg82_q6dAjw_GK-D-m?usp=sharing
See file "1" for the .mix of this test.
Besides the fact that I'm getting the 3 instead (minor issue these default parts may have different timestamps) that's the same as I get here.... Pivot and that small number are called for debugging to see if the path and the frame parameters are set properly.
But AppendActionCommand_DropPartAtPoint should actually drop the number on the sphere (as if you would drag it from MESHMIX) Maybe I'm doing something wrong... That's a direct cmd call without that much documentation.
>>>So that's not OS related
Does the string printed in the Python shell show the full path like this?:
C:/Users/<username>/Documents/meshmixer/libraries/parts/default/Numbers/part_file.obj
I see. Is adding the pivot then deselecting our selection, thus making the meshmixpart have no info on where to be placed?
So its more of a workflow issue in the order of events?
No, the mmFrame is stored before clearing the selection - that's why the pivot (called later) on is in place.
Please change
path_to_parts_dir = os.path.expanduser("~/documents/meshmixer/libraries/parts/default/Numbers/")
to
path_to_parts_dir = os.path.expanduser("~\documents\meshmixer\libraries\parts\default\Numbers\")
to avoid that mix of slashes/backslashes (although they say this is handled internally)
Actually changes that causes a Syntax error.
"There's an error in your program: EOL while scanning string literal"
Another thing that might help or be an idea is 'Meshmixer Typewriter'.
https://www.youtube.com/watch?v=DMMYOgDZZa8
It does not work very well at all when I have tried it. The objects end up not very well ordered, and often missing or overlapped. But here is a drive download link: https://drive.google.com/open?id=1X6II853GS8tjYXBfb0fzoR9cxsG33uIm
🙂 The issue above is just the final step of the workflow.
Now I can type a single line label to a textfield, get letter strings as a single clean mesh objects (not something like Stencils on dense meshes as used in the video) and Convert these meshes to a MESHMIX part.
At this state I need to drag them to the object....:
Not sure if its a big difference whether to define the target region by selection at start or by dropping at end...
But would be cool if I could manage the later as this would not break the auto command chain for further stuff.
Saw this Typewriter too. Basically this attempt works with different imports (one object per letter) called by a string (if there's a C > import C.obj, if there's a G > import G.obj .....) , then Combine (alignment could be automated too) and do a Boolean. Think we all know about the issues of Booleans. But proper spacing of letters on non planar surfaces is impossible with MM means.
My attempt instead solves this for planar and non planar target surfaces without need to do booleans. Think if its GUI is ready, one will have the options for concave or convex text (in different "depths") of different fonts....Maybe even multiple line labels.
The object name can be used as startup entry for the textbook - shouldn't be a big deal.
Hotkeys are interesting as long as one uses a mouse/keyboard input. I'm on a Wacom Cintiq tablet display (ok, there is a remote were one can define a few buttons) and a pen calls for button controls...
Yes, it should be possible to join it to the ToolManager. But I'm thinking about how to do further changes: The long ToolManager script needs some rebuilt before (as it get's longer and longer) and its all-in-one structure needs to be broken up to modules. ToolManager is pretty useful of course but there's also that nice SceneManager and atm I'm working on some automated workflow for cases were an arbitrary object overruns the build volume of an output machine (that's were labelling becomes interesting too). I'm thinking of some toolbox joining different scripts....
Multilines with a scaleable header, pullOut/pushIn , querying the active object's name or setting MM's name according to the label's header are done (still some special cases to handle but working...).
Currently I'm calling for all fonts available on a system. This results in a options list of 100+ items here. Means one needs to scroll down in this very long dropdown list to get e,g. TimesNewRoman. Plus: The shape of the used font determines the mesh resolution of the label (straight shapes result in reasonable sizes and good working parts while complex fonts (fonts like Chalkduster) result in high density parts (long time to compute and hard to drop on low poly surfaces).
Think it's better to do a hard coded list of supported fonts available on any system.
Could you give me a list of fonts which are on your system and mark the ones you would like to have?
Amazing again, you rock! For 3D printing a lot detail will get lost, and even moreso after a few months use of wear and tear of the orthotic. Plus for a medical device I'd like to keep it medical/professional looking, so I really don't need anything much. A more simple font is probably most functional, thicker letters would probably print cleaner. So lets say: Arial Black, Impact, Calibri Bold.
Would be nice if it remembers the last used font too.
Also here is a list of all the default Win10 supported fonts if needed: https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list
I think, to remember a used font (most likely) will need external libraries (not sure). ATM the font settings stay in the GUI as long as it stays open. So one can do different labels with the same settings. Maybe I add something to save/load settings via csv (as in ToolManager)...
Besides technical labelling this can be used for arts too. So I'll add some fancier fonts too.
Whether a printer is able to print such details most depends on the printer. I'm always astonished how many details my two low cost resin printers are able to give. Well, SLS might not be that detail friendly. But these are MESHMIX parts and one can scale them while dropping.
Yep very true. You're the brain's here so you make it however you want! I can always try to fine tune it for my preferred use after.
Another question, are you using python 2 or 3 now?
Both. Still have some codes in 2.x not converted to 3.x.
I do new codes as this on 3.x. It's not that big deal to convert them to 2.x after that.
But if you dare to build mmApi against 3.x (which worked fine for me modifying the building .sh files (for macOS) and a few minor changes in the mm script files) this would save some work (and 2.x isn't supported by its developers any more - so each OS update might break it.... fingers crossed... ).