This is really cool, but I always feel kind of dirty putting my STL (or any other binary) files into a git repository.
I hope GitHub adds support for scad files soon. In theory it should be pretty easy since they already support STL -- have openscad generate an STL from the scad files on the fly.
STL has an ascii variant if you like. But the real issue is placing derived files under source control. There's no good answer here. If the STL is the output of, say, a script engine that generates parametrized parts, then of course it shouldn't be in git. If it's the output of a manual process in an interactive tool (e.g. a CAD program) then the distinction is fuzzier. It's not really the "editable source", but then neither can it be automatically derived by a build system.
> If it's the output of a manual process in an interactive tool (e.g. a CAD program) then the distinction is fuzzier. It's not really the "editable source", but then neither can it be automatically derived by a build system.
It sounds like what you'd really want, in that case, would be an ASCII-encoded log-structured manipulation-history format--sort of similar to a Redis Append-Only File.
Github amazes me all the time with the sheer number of features they ship over a given time period. Major props! The STL rendering is an awesome feature.
This model is a combination of stl or dae files, created with a script file that puts the coordinates of the individual stl files.
I'm waiting for the day that maybe github could host full simulations and we test them out in the browser.
(Now that would be cool).
Yo github... while you're bothering, here are some other things that would be handy:
* Visual STL diffs, maybe by coloring deleted/added triangles. Possibly with a viewer on gh-pages or on the /:username/:reponame/commits/:branchname endpoint?
* DXF sucks, but yeah DXF rendering.
* Maybe consider thingiview.js (which does not use WebGL) or possibly a WebGL equivalent viewer. Controlled rotation, zooming, camera repositioning, etc. It seems that most of these features are implemented:
* openscad rendering- I know this is a pain in the butt, especially since openscad still requires xserver. But at least it feels more like source code. There are some other options other than openscad that could be easier to render without an xserver, which would be fine in my book, I am not particularly attached to openscad.
* Other scripting/rendering options... maybe implicitcad, pythonocc (opencascade/python bindings), HeeksCAD/python, FreeCAD/python, OpenJSCAD, something like that. The problem with STL is that it's like transmitting compiled binaries to other developers, but what developers really want to work with is the source code. Having to commit STL is like having to commit compiled binaries.
* UI widgets for committing from SolidWorks, Pro/Engineer, CATIA, AutoCAD, HeeksCAD, FreeCAD, and other front-ends would be really useful. I would be happy to use github.com while working on my next fighter jet project.
* Upverter claims to support git, but really it's just a link to a remote git repository and you can't push your schematics to Upverter. Please feel free to eat their lying lunches. Maybe also circuitlab's (although they have never claimed to have git integration). So yeah, schematics.
* Some projects require thousands of parts that need to be included when rendering, especially in assemblies. It would be nice to be able to see a fully rendered image of a version of the repository contents. This quickly devolves into a mess of file format hell, which I imagine is not something you want to tackle. But maybe this could be done through continuous integration hooks or something?
For whatever it's worth, here's a terrible post-receive bash script I wrote in 2010 for scad rendering on a git server:
* It would be exceedingly awesome if you could get the RepRap project to jump ship from svn to git. RepRap is the largest, most well organized open source hardware project, and I think it would be a great community to work with to show how strong git is for distributed hardware development.
There are already some really excellent RepRap projects in git repositories on github:
> Wow. That's a stupidly large amount of work, barfed out with seeming ignorance to the cost of implementation.
Actually, I implemented a lot of this on a private project in 2010-2011 that I never launched. There are a lot of other competitors trying to be "GitHub for Hardware"- but a lot of them fail to bother to implement git support. I think it's great that GitHub is moving in this direction.
No, sorry. But the commit hook in the other post should be useful in terms of openscad file rendering..
CAD is a really interesting industry from an open source perspective. BRLCAD has done some really excellent work. "Something" needs to come in and bulldoze the mess that OpenCASCADE has left. It turns out that writing NURBS intersection code is really not a cake walk.. go figure. Not sure what that "something" is going to be yet.
Btw, I would love to talk with you about your industry experience. We could mutually complain about how terrible ISO 10303 is!
The maintenance commitment cannot be understated. If you add some kind of processing to a file format, people are going to expect it to always be there, and always work, so you're taking on an eternal renderer maintenance workload. That said, we'd love to cleverly render all sorts of formats. The limitation is the time and developer energy to do it right and keep it updated.
> LOL you talk about such features as if they're simple add-ons! Each is a huuuuge commitment from dev to maintenance.
Nick, you and I have met, we've talked about this before. I'm really surprised that you think that I think they are simple add-ons. We've talked for hours about these things, how the heck could you get that impression from me!
Yea, I know Sir Bishop, so don't get offended. It just seems your post made it seem easy. This would be a massive change in direction for GitHub; it's massive technical complexity when they probably don't feel they fully know what's going on with 3D / CAD. We'll get there.
Yea, but good luck having a browser-based B-Rep kernel or some such. Seems like GrabCAD, etc. are doing back-end processing -> polygons in the browser using three.js, etc.
Shapesmith is also doing backend nurbs (OpenCASCADE + erlang server) with front-end rendering.
I think it would be possible to implement nurbs (or brep) in javascript, once there's an open source (and maintainable/legible) library that actually does nurbs intersection.
OpenNURBS doesn't count because Rhino has kept all the interesting bits to themselves. BRLCAD has had people from GSoC implement some of the remaining closed-source parts of the OpenNURBS library, so maybe they have had some recent progress on this front?
OpenCASCADE doesn't count because trying to extract just what you need is like trying to rewrite the multiple decades of software piled up in there..
Edit: Nick, didn't we have this exact conversation before in some HN comments like two years ago? I feel like we did and I feel bad for not remembering the url. Maybe this?
Getting the following error when loading an STL file on GitHub:
Invalid 'X-Frame-Options' header encountered when loading 'https://render.github.com/view/3d/?url=https%3A%2F%2Fraw.github.com%2FEmmanuelG%2FFoldaRap2%2Fmaster%2Fstl%2Flower-corners.stl': 'ALLOW-FROM: https://github.com/' is not a recognized directive. The header will be ignored.
Running Chrome stable. Looks like a malformed cross-origin directive?
EDIT: The error is still here but it works from time to time. Some of the time I get a "Something went wrong? Reload" message, the rest of the time, the 3D model actually appears.
Is the source for this STL Three.JS viewer available on GitHub?
It's be nice if, when you sign in, you could change which viewer was associated with which file type. Then I could fork their viewer, add my own features, and use that.
You wrote this comment in multiple places, but it's wrong. All 3D printing services I am aware of accept OBJ. Many printer softwares accept it. In fact, as soon as you want to print in color, you have to move away from STL and OBJ would be a good choice.
Different fields. Collada was for 3D graphics (and I don't know what's going on in that field).
STL is for manufacturing. STL has long been popular for commercial FDMs and CNC machines, and it is also what hobbyists use for their FDMs ("3D printers").
wow. I built a STL file viewer and showed it to hacker news a few days ago and got absolutely no response. (www.supercuber.com). It was a different account though. I realize that this is quite a bit different than supercuber but its amazing how different the traffic to two similar links can be.
It's a shitty, bad, bloated, slow, rubbish XML format. It has accumulated so much garbage in the name of interop that it is overkill for >95% of applications, and parsing/generating it is really annoying. It's a solution in search of a problem.
I hope GitHub adds support for scad files soon. In theory it should be pretty easy since they already support STL -- have openscad generate an STL from the scad files on the fly.