Area programmer laments designers don’t use the same tools he does
blog.lacebark.io
blog.lacebark.io
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.
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.
XML for objects in 3d space.
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.
[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...
You don't care about vertexes when you're spinning things in a lathe
Any thoughts about or contributions to http://stepcode.org/ by any chance?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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!
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, thanks for making my point I guess?
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.
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.
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
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.
I currently use MeshCAM for this and have thought about writing something several times (usually while fuming.)
(which itself, is a takeoff on thousands of "Area man/woman does X" type headlines in local newspapers everywhere.)
HN Reader Lament^s ^That Authors Don't Follow Basic Rules of Grammar
"Area Man Experimented With Sex Back In College"
"Lunch Barely Misses Area Man's Vital Organs"
"Area Facebook User Incredibly Stupid"
And they didn't mean north east Scotland it was an even smaller area.
It'd be nice to have tools that make this easy. Though I'm honestly surprised more people don't do it anyhow.
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.
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...
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.
The pros use something like SolidWorks and STEP or IGES to export to CAM.
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.
(The wikipedia says VSS was bought 1995, so the original product might be older?)