| 3 Jan 2024 |
 shehabattia96 | not sure if that would work on engineering models that need to be precise, but possibly on more artistic ones | 22:51:17 |
 medicationforall | 
Download PXL_20240103_205310880.jpg | 23:25:59 |
| medicationforall | 
Download 19_palenite.png | 23:26:00 |
| medicationforall | 
Download PXL_20240103_204956834.jpg | 23:26:01 |
| medicationforall | Made a display stand for more mini's I'll post later when the whole kit get's painted. | 23:26:02 |
| 4 Jan 2024 |
|  lishine1 joined the room. | 10:23:48 |
|  regattaguru_70755 joined the room. | 13:55:05 |
|  regattaguru joined the room. | 13:57:37 |
|  jackfairhaven joined the room. | 15:11:09 |
| 5 Jan 2024 |
|  meneelyt joined the room. | 12:17:21 |
|  ewald7730 joined the room. | 15:08:42 |
|  mofef joined the room. | 22:26:10 |
|  rlane joined the room. | 23:59:40 |
| 6 Jan 2024 |
|  ring_raitch joined the room. | 19:19:00 |
 yeicor | 
Download Screenshot_20240106_203046.png | 19:35:09 |
| yeicor | I made this bike handlebar/stem mount. Sources and 3D viewer here: https://github.com/yeicor-3d/bike-stem-mount
I'm still learning, so any tips or suggestions on how to improve the code are more than welcome! | 19:35:09 |
 barnaby | very impressive! how are you going to manufacture it? looks like it’d be quite a task to 3D print | 19:40:37 |
| yeicor | The top is not finished, I will add a flat surface with holes to actually mount stuff. I will use that flat surface as the bottom of the print. I don't have a solution for the screw holes other than add supports as necessary and hope for the best. | 19:43:33 |
 Roger Maitland#7070 | Your site if very impressive as well. How do you create the interactive 3D view? | 19:44:39 |
| yeicor | I made a GitHub Action that takes care of building the models, generating that website and previews for all my projects. You can check it out here: https://github.com/Yeicor/ocp-action | 19:48:41 |
| barnaby | very interesting. I’m planning on putting my codecad repo on github soon, I will look into using that or something similar for it | 19:49:55 |
| yeicor | Sure, go ahead | 19:57:18 |
| yeicor | I am using ocp-vscode with the show_all function, and I found it easier to delete old "helper" objects than toggle their visibility in the interface | 19:58:54 |
| yeicor | * I am using ocp-vscode with the show_all function, and I found it easier to delete old "helper" objects than to toggle their visibility in the interface | 19:59:09 |
 Draek#9615 | Ah I see, fair point ! | 19:59:10 |
 philipsd6 | I do that too— the alternative iirc is to keep a list of objects to show and pass that into the show function. Because sometimes when troubleshooting I want to still show a helper object. But for the final version del makes sense. | 20:00:54 |
 felix.haeberle | Hi yeicor I love your project.
I started to read through the code and you wanted feedback so I write some questions here:
1. Is there a reason why you use the del function extensively
(Python would not need it, because it does its own garbage collection (but maybe there is a good reason why you do it...)
2. concerning handlebar_side_xy = (80, 25) # (center, start) and handlebar_size = (10, wall) # (width, height) I personally would find the code more readable if you would not use tuples here. The references with [0] and [1] are more cryptic (indirect) than a real name (data classes and named tuples might be something that you could use)
3. do you know that the python script can use a
if __name__ === "__main__":
... do something if the script is run directly
else:
.... do the stuff for importing it
Many python scripts use this for calling a function like main, but the concept can also be applied during the import phase.
I really like your concept with the to_fillet. I was not aware that this works the way you do it.
Furthermore is the split a nice. | 21:03:35 |
| felix.haeberle | * Hi yeicor I love your project.
I started to read through the code and you wanted feedback so I write some questions here:
1. Is there a reason why you use the del function extensively
(Python would not need it, because it does its own garbage collection (but maybe there is a good reason why you do it...)
ok that was already answered this is a neat trick.
2. concerning handlebar_side_xy = (80, 25) # (center, start) and handlebar_size = (10, wall) # (width, height) I personally would find the code more readable if you would not use tuples here. The references with [0] and [1] are more cryptic (indirect) than a real name (data classes and named tuples might be something that you could use)
3. do you know that the python script can use a
if __name__ === "__main__":
... do something if the script is run directly
else:
.... do the stuff for importing it
Many python scripts use this for calling a function like main, but the concept can also be applied during the import phase.
I really like your concept with the to_fillet. I was not aware that this works the way you do it.
Furthermore is the split a nice. | 21:04:15 |
| yeicor | 2. Yes, that would definitely help readability. Thanks!
3. I did not think of that. However, when I import a script I want to run all of its code in order to generate the part, and when I run the script I want to generate the part and also call ocp_vscode.show_all(); so I guess I wouldn't gain anything by restructuring the code in this case. | 21:39:28 |
 bernhard#0011 | Yes, I also use del for this case. On the other side, if you de-select a variable the viewer keeps it de-selected across runs, which is helpful for re-running code after changes | 22:01:09 |
