One of the more interesting things about 3D printing is that it is igniting this sort of issue. A long time ago (like 1991) I was a working for Sun and representing them at the "CAD Framework Initiative" efforts or CFI. The express goal of this was to create a set of interchange formats for CAD tools so that you could move things from one system to another, you could store and diff changes, and even if your vendor went out of business you could use your designs in another vendor's tool if it was CFI compliant.
Now the irritating part was that Apollo Computer turned it into a DCE RPC vs ONC RPC thing when the committee started leaning toward the simpler RPC/XDR format that Sun had offered. The criminal part was that as soon as it became clear that the group was actually going to succeed nearly all support was yanked. The simple reality was that CAD tools cost literally hundreds of thousands of dollars for a large shop and those vendors desperately needed the 'lock in' effect of a propietary data format and tool chain to keep themselves in play during the inevitable periods where their tools totally sucked (waterfall development at its finest). It still bugs me when I think about it over 20 years later!
So to say I would be a huge supporter of an open CAD standard is an understatement. And now that there is a fairly large body of people who are both code capable and desirous of such a standard in order to create, share, and modify 3D designs, there might be enough energy to make it happen.
Robust open-source CAD software would clearly fill a niche.
The problem however, is not so much CAD as the schemas for the data that at gets attached to the models...IGES has been around for many decades, but what one engineer needs for FEA is not what the machinist needs for making the die or the Architect for making pretty pictures.
open source data formats are more important than programs initially, the above is for 3d models.
"— namely, the position of each vertex, the UV position of each texture coordinate vertex, vertex normals, and the faces that make each polygon defined as a list of vertices, and texture vertices. "
I'm sure there's one for the edge based models too.
I can see an UrStandard developing, which while probably inefficient, can describe necessary attributes for all practical applications and export into the open standardised format for the field at hand.
The defacto standards for geometric data are driven by the dominate commercial software packages, e.g. ESRI's formats for geospatial information or AutoDesk's DXF for Orthogonal data [ and here I am lumping CAD and GIS under the scope of any universal standard ].
The issue with creating a standard is that to a first approximation every CAD or GIS program creates and operates on a unique set of meta-data...this is what gives each piece of software it's distinguishing features [ sure there are possible algorithmic efficiencies, but these are not an issue that a data interchange standard ought to treat as a primary concern ].
The wonderful thing about standards for 3d data is that there are so many to choose from. [1] There have been massive projects to create standards, and many of them have completed their work, only to see time march on. In AEC, the National Cad Standard was created in the 1980's [2]. It still locks the 3d description of designs to their 2d representation as drawings. The Army Corps of Engineers implements NCS. Their document is 450 pages [3]. To be comprehensible by humans, it is based on the idea:
CAD levels or layers are analogous to
overlays in manual drafting systems
and serve to separate graphic elements
(lines, shapes, and text) according
to the design discipline they represent.
Why, because unlike a computer program, the artifact it describes cannot be assumed to be directly manifested in meat-space without human involvement...e.g. buildings require construction crews and machine parts require someone pour raw material into the hopper and put finished goods on a truck, transport them, unload and install them for their next use...a design for a kitchen renovation doesn't compile into a new cabinet configuration.
So the fundamental issue for developing creating a useful 3d data model is not a document, but a way of creating the data model that is attractive to people who create 3d data models. The prototype is JavaScript not ADA.
Plenty of money and effort was going into STEP [1] in the same timeframe, it is still in use for designing anything that flies. I'm the editor of one of the parts of it and we are seeing increasing interest from other industry sectors.
I have helped a little bit with checking their compliance to the standards.
I modified the compiler that is in stepcode many years ago to generate ASN.1 definitions for the STEP models, the idea was to define some RPC operations to allow the kind of thing that ChuckMcM describes but I couldn't find anybody interested in it at the time. It would have been easy enough to write another compiler back end to generate XDR.
I guess I would prefer to be paid to work on STEP, there is a fair bit of politics involved in it and I'm already involved with several opensource projects that are more fun.
Also, if I'm looking for an opensource project to contribute to then I wouldn't pick one that used C++ and git, sorry.
I have got some diffs to Express Engine [1] that I need to send in though.
Its a pretty big rift from my perspective. We were right alongside mechanical and architectural majore at VTC, they all learned some really crufty cad programs. The worst was SolidWworks, scripting that thing is a pig if damn near impossible. As a wanna-be tech startup in the field, I'd stay away from those tools like a plague. I heard there was way to do it, but its the kind of thing hiding behind their coprorate pay-wall and for profit training material.
I've been impressed with tools like freecad - Its all implemented on top of a great Python API and lets you run code against some of their core modules. Developing procedural and programatically (parametrically?) designed hardware is much easier - and you can still interface with the average CAD worker / engineer.
That being said, the average designer is SOL in this workchain.
We don't need a standard so much as both a plethora of special purpose tools (these are already here and more are in the works) AND an n:m pandoc style conversion utility. DXF/DWG will be with us for a long while.
The open standard would be pretty helpful, if not sufficient for both. There even are no open source viewers for DWG files for the time being, so if I'm working on some new tool it is woth nothing to me that DWG is popular, because I can't use it without tons of effort.
> They are also not on github, which makes collaboration that much harder.
This is now vim-emacs level zealotry. There are workflows which gasp do not mesh well with github. github issues/PRs have almost no metadata and absolutely none that the issue submitter can set.
> There are workflows which gasp do not mesh well with github.
If we're discussing open source collaboration, it is hugely beneficial to NOT have your own unique workflow and instead adopt one that a large community of people are already using.
In the time it takes to read your special "how to submit a patch" document, I could have already been done if you were using a de-facto standard workflow like Github's. This has a material impact on how much contribution you can expect to get from others.
This is yet another case of Worse is Better. Ubiquity trumps perfection.
I have heard it argued that making contributions harder to submit is somehow a good idea, because it keeps lower quality contributors out. This is very much mistaken, and even someone as cantankerous as Linus is on the record saying that encouraging more patches, even annoyingly naive ones, is in the long-term interest of the project.
>I have heard it argued that making contributions harder to submit is somehow a good idea, because it keeps lower quality contributors out. This is very much mistaken, and even someone as cantankerous as Linus is on the record saying that encouraging more patches, even annoyingly naive ones, is in the long-term interest of the project.
Yet Linux is not being developed on Github. Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract.
> Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract.
There is historical path dependence. Linux has changed workflows before, but each time it was controversial. I can see where it wouldn't be worth igniting a holy war.
I noticed that as well, I was hoping it was ignorant shorthand for "has a public repository, bug tracker and website".
Also, it's worse than vim-emacs zealotry, those at least have the benefit of being extremely powerful expert level tools. Those frequently, and maybe rightfully inspire some zealotry.
That same attitude towards popular, least common denominator tools is better called fanboyism than zealotry.
zealotry? It's one comment in an article dealing almost entirely with other issues.
Github has become the de-facto place to put code that you want others to work with, and it is a platform built to surface such projects and make them accessible in a consistent way.
It's not the only such tool, but it is really familiar to a lot of people, and that makes collaboration slightly easier for those who are familiar with it.
"Github has become the de-facto place to put code"
Maybe in some districts of SF and SV, but apart from that, NO
I love Github and I think that it is way better than most of "industry standarts" but amazingly, some people still use self hosted solutions, because they need it.
For the strict issue of sharing code with others (open to everybody), sure, Github is the best solution
But this is not what the article was talking about, it was talking about collaboration with other file formats, so jumping to say Github is good (on what we already know it's good and does not correspond to the discussion) is a stretch
I can't find a way to stretch the definition, for the kind of open-source projects he is very clearly discussing, that isn't some sort of reductivist #NotAllSourceRepositories or something.
The author made "being on github" a hard requirement. I think it might have been made as a kind of shorthand for "on github or something equivalent" but you can't blame someone for taking the author at their word when they state it so plainly. And that stated sentiment is pretty insane.
>"Github has become the de-facto place to put code that you want others to work with,"
I think maybe you meant to use a more general term like "source control" here. Because that's so wrong to say github is de-facto for collaboration. There are proprietary projects with their own source control everywhere and "not using github" is no concern for any of them. Source control came around long before source control front-ends, surprisingly. And, again, probably surprisingly, not everyone needs a front-end to actually work.
So, you've listed like 5-10 projects, scattered across several services. Big projects which are important, don't get me wrong--but still outnumbered by the huge number of your "fad.js" projects.
It represent decades of hard work from dozens of programmers.License is LGPL.
Freecad is a very promising tool that uses the power of Opencascade only a little(Opencascade supports things that are way more complex than what freecad does).
Unfortunately, OpenCASCADE is an unmaintainable pile of code. There's https://github.com/tpaviot/oce but does anyone really want to maintain 3 million lines of poorly written source code? Here's what you will have to deal with if you dive in: http://diyhpl.us/wiki/cad/opencascade :(
Most of the people commenting here haven't used those tools.
In a modern CAD system, like SolidWorks and Autodesk Inventor, the systems retain much more than geometry. There's lots of structure. "This is a round hole" (STL doesn't even have that.) "This part is a 6/32 screw, pan head, 3/4 inch length". "This edge of this part aligns with this other edge of this other part" "This part is made of mild steel". "This subassembly is made of these parts and is used in these larger assemblies". "The holes in this part are projected downward from the larger assembly so the holes will line up".
All the serious CAD systems today understand those kinds of things. An object is represented as a series of operations in constructive solid geometry, not a mesh. Relationships between parts are modeled. Many parts are parametric - some dimensions depend on other dimensions, and you can change one and have the others change appropriately. ("Appropriately" means this is more than scaling; making the thing longer doesn't turn round holes into ellipses.)
Capturing all that structure is complicated. Open Cascade doesn't do any of that stuff; it's just a geometry library.
Revision control for models is available. Autodesk has Autodesk Vault. Solidworks has Workgroup PDM. Revisions can be compared visually. It's a hard problem, and errors tend to have serious consequences, which is why most engineering shops have a rather rigid workflow.
Over in the animation world, there's Alienbrain, a very expensive revision control system for big animation and game projects. There, you have many different formats to coordinate - video, background art, motion capture data, textures, etc., with different people working on each.
These tools are expensive because the market isn't that big but the value they add is large.
I'm curious if you could recommend a way to do parametric design with SolidWorks.
The way my friend was doing it, the system ended up chugging like a pig and he had a rather impressive machine.
I'd prefer a system involved with a programming language. I get the impression that SW isn't geared to do that because the market they serve doesn't care for that level of control.
The author also makes a procedural 3D modeler (http://gsculpt.sourceforge.net/). You should definitely check both of them out, and talk to the communities.
I couldn't agree more with this. I have actually been looking at writing a CAM program that uses OpenSCAD (and perhaps the python bindings to it) in order to generate gcode for machining. It would work great for me, but probably less so for the guys in the shop.
Representing the OpenSCAD code as a tree you can fairly readily edit next to the renderer would help. Being able to click on something and have it pull up all the relevant nodes regarding that element for editing would be a huge help. Then of course the next step is being able to drag and get context menus for things like bolt circles or other kinds of symmetry.
FreeCAD doesn't really cut it when it comes to trying to do these kinds of things, in my opinion.
OpenSCAD can generate either stl or wavefront obj (and several other formats), there are a lot of trivialy integratable tools that can go from there to gcode. Slic3r and CuraEngine to name but two.
The academic field of Engineering Informatics addresses the particular issues the author raised as well as other connected issues. These problems are acutely relevant today although the issues have been known and attempts have been made to address them by many other concerned folk many times over for at least the last 20+ years with varying degrees of success. Given the poor state of engineering knowledge storage and collaboration and the effect this has on engineering productivity, it is a space begging for one of Clay Christensen's famous "Disruptive Innovations". As you point out the change is unlikely to come from existing vendors at they prefer file format lock-in. When the tide shifts this could be an Achilles' heel although I would expect the vendors to adapt. One of the most intractable issues is that each type of engineering has it's own heterogenous method of describing and recording their work. The best research I have encountered seems to point to Semantic technologies having the most to offer to possible solutions.
I wonder which tools use people making real things with CNC machines. I assume that there's some specific, not really friendly file format which cannot be edited in some 3dMax or Blender, so some conversion is performed before, but, anyway, there must be some more or less standard workflow, I suppose.
It's been 20 years since I wrote any CNC controller software but the "assembly language" of CNC then was g-code (http://en.wikipedia.org/wiki/G-code).
In the end it really doesn't matter how your CAM software stores its data as long as you can translate it to g-code within the software or with a 3rd party compiler. The fun part for me back then was optimizing that translation with respect to the machine's capabilities so you can do things like minimize machining time while maximizing tool life and keeping surface roughness within tolerances.
You usually generate a "toolpath" which is a set of instructions for the machine to follow. For old MakerBots this was .gcode (http://en.wikipedia.org/wiki/G-code) which is the exact instructions to control the toolhead. It's a standard insomuch as XML is a standard, that is, format but not content is standardized.
The pros use something like SolidWorks and STEP or IGES to export to CAM.
STL is really bad for 3D printing IMO. It's just a bag of triangles - there's absolutely nothing tying those faces together, and it's thus a constant battle with floating point precision to make sure there's no 'holes' in models, so they can be effectively sliced.
Many years ago, when I was designing a part in AutoCad, I drew it by hand and then back-converted the drawing into parametrized AutoLISP, which I then stored under version control (RCS at the time).
It'd be nice to have tools that make this easy. Though I'm honestly surprised more people don't do it anyhow.
You can version AutoLISP but the output is so verbose (at least for machine generated code) that diffing versions is like diffing PDFs or PCL files. You can see the changes but they don't make any sense without the whole file being rendered.
NOTE: Its been 20 years since I used AutoLISP and the code I was using was being generated from software that did cut-plan optimization for lathes so I am probably speaking from a very old/ignorant point of view.
With AutoCad or any software that exports DXF or IGES, Git or other version control would work fine. Nemetscheck VectorWorks wil export a design file as VectorScript [a super-set of Pascal].
It lends itself to a workflow where sometimes, a user checks out a file, and forgets to unlock it. Or goes on vacation. Then you have to forcibly check out the file your coworker locked to get work done. And when he has to merge his changes with yours again, it’s a gigantic hassle.
This exactly describes web development on the Microsoft stack using Visual Source Safe. I don't know if that product exists anymore or still works the same way but the frustration with it is what drove the popularity of Subversion and then later Git.
Ah, ams6110, I feel your pain, but you have not encountered true agony until you have been subjected to... Perforce (aka p4). It feels like the p4 designers WANTED software development to be harder. Perhaps they recruit developers exclusively from the pool of former TSA agents.
You were probably too Microsoft specific in your work environment. CVS is older than most(?) HN posters and had no locking problem. So your pain was not necessary. :-(
(The wikipedia says VSS was bought 1995, so the original product might be older?)
CVS was developed in the '80s specifically to get around the locking problem that locking (non-concurrent — that's what the C in CVS is) version control systems had.
Now the irritating part was that Apollo Computer turned it into a DCE RPC vs ONC RPC thing when the committee started leaning toward the simpler RPC/XDR format that Sun had offered. The criminal part was that as soon as it became clear that the group was actually going to succeed nearly all support was yanked. The simple reality was that CAD tools cost literally hundreds of thousands of dollars for a large shop and those vendors desperately needed the 'lock in' effect of a propietary data format and tool chain to keep themselves in play during the inevitable periods where their tools totally sucked (waterfall development at its finest). It still bugs me when I think about it over 20 years later!
So to say I would be a huge supporter of an open CAD standard is an understatement. And now that there is a fairly large body of people who are both code capable and desirous of such a standard in order to create, share, and modify 3D designs, there might be enough energy to make it happen.