Re:GitHub announces 3D File Diffs
by jotux on Tuesday September 17, 2013 @03:03PM
(#6401188)
A neat feature but I wish they had support for 3d source file types instead of exported "binary", for lack of a better term, file types. If you wanted to truly open source your mechanical project you'd need to add an extra step to delete the previously exported STL and export a new one every time you commit. You also lose color/texture data when you export to STL.
[ Parent
| on HN ]
Re:GitHub announces 3D File Diffs
by steveklabnik on Tuesday September 17, 2013 @03:24PM
(#6401294)
STL files are the source file for most 3D printers, which is probably the vast majority of 3D files on GitHub, I'd imagine.
Yes, it's the output from a CAD tool and used for 3d printing but STL is a binary file type and not easy to edit. Committing STL files to a repo is analagous to commiting EXE files instead of source code or PDF files instead of TEX.
What about ASCII STL files? I'd say they're "pretty easy" to edit. I wouldn't want to write an entire one, but I've tweaked values in one before.
What I mean is ease of editing in a typical CAD tool: Solidworks, AutoCad, Sketchup, etc. STL is imported as a solid blob and you lose all the individual features from the source model.
Re:GitHub announces 3D File Diffs
by DanielRibeiro on Tuesday September 17, 2013 @04:16PM
(#6401645)
Actually there are 10x more OBJ formatted files than STL files. I created a Chrome extension to visualize these on GitHub as well: https://github.com/danielribeiro/three-hub
Collada format is also very popular, particular with WebGL guys. The problem with diffing these is that you start diffing animations as well. Which literally adds a new dimension to the problem. If you take textures and materials into account, then the problem soon becomes really hard to visualize
Re:GitHub announces 3D File Diffs
by NickPollard on Wednesday September 18, 2013 @07:55AM
(#6404711)
That's a really great extension; My indie game currently uses .obj for some output files and this is very useful for me.
STL files aren't sources. They are near the very end of the toolchain. At the front of the toolchain tends to be scripting languages like AutoLISP, OpenSCAD, MGED (BRL-CAD), etc.
it's pretty trivial to include your SCAD file (for openSCADders like me) alongside your STLs. That's what I did on my github project (linked to indirectly via my info, and elswhere in this section).