Area programmer laments designers don’t use the same tools he does(blog.lacebark.io)
blog.lacebark.io
Area programmer laments designers don’t use the same tools he does
http://blog.lacebark.io/2014/09/25/area-programmer-lament-designers-dont-use-the-same-tools-he-does/
11 comments
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.
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.
https://en.wikipedia.org/wiki/Wavefront_.obj_file
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.
XML for objects in 3d space.
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.
XML for objects in 3d space.
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:
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.
[1] With perhaps disputed apologies to Grace Hopper. http://en.wikiquote.org/wiki/Grace_Hopper#Disputed
[2] http://www.nationalcadstandard.org/ncs6/about.php
[3] http://www.saj.usace.army.mil/Portals/44/docs/Engineering/AE...
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.
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.
[1] With perhaps disputed apologies to Grace Hopper. http://en.wikiquote.org/wiki/Grace_Hopper#Disputed
[2] http://www.nationalcadstandard.org/ncs6/about.php
[3] http://www.saj.usace.army.mil/Portals/44/docs/Engineering/AE...
The texture thing just solved the 3D drawing problem, not the FEA problem, or the machinist/CNC problem
You don't care about vertexes when you're spinning things in a lathe
You don't care about vertexes when you're spinning things in a lathe
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.
[1] https://en.wikipedia.org/wiki/ISO_10303
[1] https://en.wikipedia.org/wiki/ISO_10303
> I'm the editor of one of the parts of it
Any thoughts about or contributions to http://stepcode.org/ by any chance?
Any thoughts about or contributions to http://stepcode.org/ by any chance?
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.
[1] http://sourceforge.net/projects/exp-engine/
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.
[1] http://sourceforge.net/projects/exp-engine/
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.
Still haven't found a good mix.
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.
Still haven't found a good mix.
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.
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.
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 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.
> 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.
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.
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.
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.
The more interesting question is what new projects should do. Even Linus puts new things (https://github.com/torvalds/subsurface) on Github.
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.
The more interesting question is what new projects should do. Even Linus puts new things (https://github.com/torvalds/subsurface) on Github.
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.
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 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.
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.
full quote: "Github has become the de-facto place to put code that you want others to work with".
Maybe I should clarify: "others" == "people who don't know or directly work with you"
Self-hosted solutions do not make collaboration simpler (in an OSS context), which is the reasonable, non-zealous claim made by the article.
Maybe I should clarify: "others" == "people who don't know or directly work with you"
Self-hosted solutions do not make collaboration simpler (in an OSS context), which is the reasonable, non-zealous claim made by the article.
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
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.
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.
Let's not mince words.
Where else is that code being written, and what is it's volume of code compared to Github?
SourceForge? CPAN? The OpenBSD CVS? Bitbucket? Google Code (lol)?
I'd be genuinely surprised if you could show me a place with more repositories right now than Github--I'd love to see such a vibrant ecosystem!
Where else is that code being written, and what is it's volume of code compared to Github?
SourceForge? CPAN? The OpenBSD CVS? Bitbucket? Google Code (lol)?
I'd be genuinely surprised if you could show me a place with more repositories right now than Github--I'd love to see such a vibrant ecosystem!
No Linux distribution uses github. Same for FreeBSD/OpenBSD
The Linux Kernel is there but development is not done there, it's merely a mirror.
Gnome (https://git.gnome.org/browse/), KDE, XFCE (http://git.xfce.org/) are not there.
Nginx? Uses Mercurial http://nginx.org/en/download.html Apache? Not there as well
Gcc? LLvm? http://llvm.org/docs/GettingStarted.html#checkout
But the latest fad.js is in github so that's what people use, right?
The Linux Kernel is there but development is not done there, it's merely a mirror.
Gnome (https://git.gnome.org/browse/), KDE, XFCE (http://git.xfce.org/) are not there.
Nginx? Uses Mercurial http://nginx.org/en/download.html Apache? Not there as well
Gcc? LLvm? http://llvm.org/docs/GettingStarted.html#checkout
But the latest fad.js is in github so that's what people use, right?
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.
So, thanks for making my point I guess?
So, thanks for making my point I guess?
Open Source geometric kernel?
It is called "Open Cascade": http://www.opencascade.org/
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).
Everything in Freecad is a script in python.
It is called "Open Cascade": http://www.opencascade.org/
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).
Everything in Freecad is a script in python.
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 :(
So far the absolutely cleanest implementation I have seen is http://verbnurbs.com/ which is amazing. Seriously, go over here https://github.com/pboyer/verb and compare. This is way, way cleaner than OpenNURBS like uh https://github.com/kanzure/brlcad/tree/master/src/other/open... here. And it has tests distributed with the source code, so hey you can actually attempt to maintain it if you are into that.
So far the absolutely cleanest implementation I have seen is http://verbnurbs.com/ which is amazing. Seriously, go over here https://github.com/pboyer/verb and compare. This is way, way cleaner than OpenNURBS like uh https://github.com/kanzure/brlcad/tree/master/src/other/open... here. And it has tests distributed with the source code, so hey you can actually attempt to maintain it if you are into that.
I had no idea that verbnurbs existed. It's one reason for writing, to get wind of other projects I didn't find in my google searches. Thanks!
This characterizes the filter bubble I can get into here, and few other venues, because they are poorly- or entirely un-moderated.
Its also what forms the heart of OpenSCAD, which is built ontop of OpenCascade
Larch is a visual programming environment. http://www.larchenvironment.com/
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.
One of the main examples in Larch, is of modifying the visual representation of a polygon, rather than the textual representation. See: http://www.larchenvironment.com/what_does_it_do
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.
One of the main examples in Larch, is of modifying the visual representation of a polygon, rather than the textual representation. See: http://www.larchenvironment.com/what_does_it_do
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.
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.
Seems like there would be a lot of distance between an openscad model and generating a toolpath in gcode.
I currently use MeshCAM for this and have thought about writing something several times (usually while fuming.)
I currently use MeshCAM for this and have thought about writing something several times (usually while fuming.)
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.
I am confused about the title. What is "Area"?
It's a riff on a common type of onion headline: e.g: http://www.theonion.com/articles/area-man-experimented-with-...
(which itself, is a takeoff on thousands of "Area man/woman does X" type headlines in local newspapers everywhere.)
(which itself, is a takeoff on thousands of "Area man/woman does X" type headlines in local newspapers everywhere.)
Thanks.
HN Reader Lament^s ^That Authors Don't Follow Basic Rules of Grammar
HN Reader Lament^s ^That Authors Don't Follow Basic Rules of Grammar
It looks like a riff off of a common Onion news article headline pattern. Looking at their homepage now, I see these:
"Area Man Experimented With Sex Back In College"
"Lunch Barely Misses Area Man's Vital Organs"
"Area Facebook User Incredibly Stupid"
"Area Man Experimented With Sex Back In College"
"Lunch Barely Misses Area Man's Vital Organs"
"Area Facebook User Incredibly Stupid"
the "area man" on the onion is a satire of local news, the kind of thing you'd see in a small township newspaper
Apparently taken from real life allegedly one vary parochial Scottish news paper reported the sinking of the titanic as "North-east man lost at sea"
And they didn't mean north east Scotland it was an even smaller area.
And they didn't mean north east Scotland it was an even smaller area.
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.
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.
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.
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.
Huh? The whole point was to version the AutoLISP source, not its output. And I didn't really mean machine-generated code...human-generated.
And of course, as for making sense, well, you have to use good commit logs as well.
But maybe you're talking about some technology that generates AutoLISP from a GUI? I don't know anything about that...
And of course, as for making sense, well, you have to use good commit logs as well.
But maybe you're talking about some technology that generates AutoLISP from a GUI? I don't know anything about that...
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].
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.
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.
The pros use something like SolidWorks and STEP or IGES to export to CAM.
I think STL is a nice file format that is used a lot. It can be imported and exported in a lot of 3d software.
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.
Alternative? Do tell.
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.
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.
Perforce was fine compared to ClearCase.
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?)
(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.