dactyl-keyboard
dactyl-keyboard copied to clipboard
adereth
File not rendering in openSCAD
Tested the same file from the things folder in openSCAD for windows and openSCAD for ubuntu.
Sits at "Rendering Polygon Mesh using CGAL..." with 0/1000.
Please advise.
I saw that same sort of behavior, and chanced to leave it alone once. After like five minutes, it jumped to 400 and started counting. Have you tried leaving it to run for what seems to be an obscene amount of time?
If you don't want to run the Clojure code you can look at the rendered STL files; if you do run the code, you can turn the detail down to get an scad file that will render much faster.
Hope one of these helps; let me know.
I'm planning on modifying the dactyl into a mini dactyl, so I'm using the clojure code to do that. I'm not sure if my laptop cpu just can't handle it, but i left it for 30 minutes with no success.
EDIT: Ohh, sorry just saw the detail. Will definitely turn that down. Thanks
EDIT2: I can't find the details setting. Is it in the file itself, or is it a setting within clojure?
I found the resolution setting and lowered it to 1. The inital render loads much more quickly, but when I try to press f6 so that I can export it as an STL file it does the same thing as before. Let me know if you guys have any ideas.
Also this is what the inital render looks like when I download the openSCAD file from github.
https://i.imgur.com/sENxsUa.png
Hi, Derek !
I wish you solve those problems soon !!!
I talk to you because I also wanted to modify Dactyl into miniDactyl. Basically, I want to remove the numbers row. Is that your proposal too ?
I wonder if you mind to share your design modifications with the community. I have not even started yet to making changes.
Greetings from Spain !
Manolo Navarro
On Wed, 27 Dec 2017 at 05:46, Derek [email protected] wrote:
Also this is what the inital render looks like when I download the openSCAD file from github.
https://i.imgur.com/sENxsUa.png
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adereth/dactyl-keyboard/issues/53#issuecomment-354051486, or mute the thread https://github.com/notifications/unsubscribe-auth/AeskTQZIK2zMfO6AZ0cuEtJ2s0sv4kytks5tEcufgaJpZM4RNHUd .
@xcode-manolo I'm wanting to drop the amount of keys down to 32, only 2 thumb keys, and have it printable in a very small area 120mm^3.
Ah, that's pretty small. I had think only in removing numbers row. That's enough for me !
Thanks Derek !
On Wed, 27 Dec 2017 at 11:36, Derek [email protected] wrote:
@xcode-manolo https://github.com/xcode-manolo I'm wanting to drop the amount of keys down to 32, only 2 thumb keys, and have it printable in a very small area 120mm^3.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/adereth/dactyl-keyboard/issues/53#issuecomment-354093509, or mute the thread https://github.com/notifications/unsubscribe-auth/AeskTR3H2hDHs50lawfgNMUcxwr58TPIks5tEh2qgaJpZM4RNHUd .
i also don't have a large enough print volume for the whole thing, but i've set out to print a full-size keyboard in pieces and glue them together.
don't miss the lightcycle.clj; it might be more customizable for small keyboards.
as for the openscad screenshot, you have me baffled.
I'm wondering if the render is just failing on my laptop core i5. I'll try it on something with more power at some point.
Tried it on another computer. The preview showed up correctly, but the file did not render. I had left it for about 10 minutes.
Have the same issue. Sits at 127/1000 for ages (on a 3.6 GHz i7 core). Tried leaving it for 20 minutes or so, hasn't moved.
Additionally, the pre-generated STLs are full of issues that cause various slicers to do weird things, even after running it through the Netfabb cloud service.
Found a solution. Well, kinda. It renders fine in old OpenSCAD (2013-06 for example), except it takes about 2 hours or more.
Also doesn't have problems with self intersections and malformed polys either.
Yes and no. The parametric geometry isn't too clean, and OpenSCAD is notoriously bad at doing booleans on more complex geometry, often crashing and resulting in self-intersections.
Since the algorithms changed from version to version, some have more luck with some edge cases, others with some others.
Is there something more robust & stable that the project should be ported to?
Maybe something like Antimony?
Judging from the searching I've done every time I hit a roadblock, OpenSCAD and its underlying CGAL library are the only thing in this area with staying power. libfive looks interesting but has no hull function, upon which this code depends a lot.
Yeah, unfortunately, the only algos more robust, as well as mesh repair code that's actually decent, is closed source / proprietary stuff. CGAL is here to stay.
Antimony is interesting, but i think it'd be a bit more of a pain to work in, as you'd need to write a ton of missing semi-primitive stuff first. Fun fact - the author of Antimony works at Formlabs.