[HN Gopher] A New Era for Mechanical CAD
___________________________________________________________________
A New Era for Mechanical CAD
Author : jasim
Score : 75 points
Date : 2021-06-15 16:10 UTC (6 hours ago)
(HTM) web link (queue.acm.org)
(TXT) w3m dump (queue.acm.org)
| nickpinkston wrote:
| There are a few problems with making new CAD, especially open
| source:
|
| - CAD math is hard and severely limits contributors. Unlike many
| open source projects, you need a pretty big core team to make
| something worth using. FreeCAD/OpenCASCADE, etc. have remained
| hobbyist CAD, where we've seen the success of open source in
| software.
|
| - Another core problem is that MechE's can't easily edit the tool
| they're using when they run into a bug/feature they want to work
| on, unlike open source software where the users can more easily
| be contributors.
|
| - High switching costs: there are four big CAD companies:
| Dassault, Autodesk, Siemens, PTC, and once a company commits to
| one ecosystem, it's very hard to change. Ex: Boeing isn't putting
| the CAD for the 787 in OnShape - ever. There also aren't that
| many new huge hardware companies, meaning that folks like OnShape
| get SMEs, but virtually all enterprise is taken. This has
| essentially led to an oligopoly in mechanical CAD, and slow pace
| of innovation in the space. I believe CAD tools have 50x less $
| investment (including big companies) than software dev tools.
|
| - InterOp is also hard, file formats are
| complex/proprietary/inconsistently implemented. There are kernels
| like ParaSolid with import/export/conversion systems, but they're
| not trustworthy enough to really put the 787 into new CAD without
| so many bugs that you'd lose a year fixing them and likely be
| paranoid forever wondering if you got them all.
|
| - Folks like nTopology have done a good job side stepping these
| concerns as they built a CAD tool that does a specific function
| (generative design) that can't be done in traditional CAD kernels
| and can be sold for very high value-add situations - ie designs
| that need very high performance from the uniquely optimized
| geometries that they're able to generate, and export files that
| play nice with regular CAD. This means Boeing can have some fancy
| nTopology-created parts in their planes without having to blow up
| their CAD/PLM systems.
| frontiersummit wrote:
| This hits the nail on the head. All of the CAD kernels
| basically date from the 1980s. The mathematics involved in
| extending them is not widely taught, and while this knowledge
| still lives in books, it is not finding its way into minds.
| adfm wrote:
| I'm surprised the article doesn't mention Rhino/Grasshopper,
| considering how prevalent it is.
| baybal2 wrote:
| 3D modelling !== solid modelling.
| Animats wrote:
| _CAD math is hard and severely limits contributors._
|
| Yes. Autodesk used to have a staff geometer, and probably still
| does. Constructive solid geometry is hard, because you can use
| complex forms to cut into complex forms, and have to represent
| the result.
|
| A typical exercise in a good CSG program is to model a bolt.
| You start with a cylinder. Then you draw and dimension a thread
| cross section. Then you extrude the thread cross section along
| a spiral, subtracting that from the cylinder, to cut the
| threads. Then, at the end of the bolt, you cut a chamfer by
| extruding a triangle around a circle and subtracting that from
| the bolt. The CAD program must correctly and precisely describe
| what happens to the thread as it is cut by the chamfer. You can
| zoom way in and take a close look. You might have a design
| constraint that the chamfered thread can never be thinner than
| some specified width, to avoid bits of metal flaking off as the
| bolt is tightened.
|
| Most of the free CAD programs bail before they deal with
| problems that hard.
| nickpinkston wrote:
| And the BREP math is even worse... And the implementations
| are pretty dirty too
|
| Also, good to see you John :-)
| regularfry wrote:
| I'm not certain about that very last constraint (the
| chamfered thread not being thinner than X) but other than
| that, precisely what you describe is a workflow I've been
| following for the past couple of months in FreeCAD: not for
| metal threads, for plastic, printed ones, but the workflow is
| the same. They added helical cuts and additions in the most
| recent version, but even before that you could get the same
| effect with a helical path (so a few more steps for the same
| result, essentially).
| Animats wrote:
| Oh, good, FreeCAD is catching up. It's been a few years
| since I tried it.
| regularfry wrote:
| Yeah. 0.19.2 is good, at least for the stuff I need; 0.20
| is shaping up to be full of good stuff too (and hopefully
| won't take as long as the 0.18->0.19 cycle did). On-
| topic, though, if you're doing threads and gears, it gets
| slow quickly. It doesn't take very much for me to start
| needing to switch parts of the design off for the UI to
| stay usable because recalculations kick in that _I_ know
| shouldn 't be needed, but the dependency tree isn't
| detailed enough to filter out.
| jbay808 wrote:
| Sometimes closed source software gets open sourced for business
| reasons, and backed by a big consortium, rather than being
| written from the ground up by hobbyists.
|
| I wonder if big aerospace and defense companies like Boeing,
| and automakers, and heavy industry, and so on, might decide
| it's in their interests to collectively buy and open-source an
| existing commercial CAD package rather than risk being held
| hostage to the vendors that gatekeep their engineering.
| cogburnd02 wrote:
| BRL-CAD was created by the US Army Research Laboratory (then
| the Ballistic Research Laboratory, hence 'BRL') and was
| released in 1984, and became free software in 2004.
|
| https://en.wikipedia.org/wiki/BRL-CAD
| paddy_m wrote:
| Dassault Systems was spun off from the european fighter plane
| manufacturer with the same name. They bought up solidworks
| and Catia and runs as a standalone business.
|
| https://en.wikipedia.org/wiki/Dassault_Syst%C3%A8mes
| nickpinkston wrote:
| Yea, I believe most (all?) CAD systems are spin outs from
| industrial programs. Pierre Bezier (of the curve) was
| actually an automotive engineer at Renault as they were
| trying to better define shapes.
| agumonkey wrote:
| here's a short but fun bit with bezier unisurf system
|
| https://www.youtube.com/watch?v=c0_a6r2JaWQ
| nickpinkston wrote:
| I think the companies want an independent for-profit
| maintaining the business because they don't trust the
| dynamics of open source / non-profit to actually provide good
| products/services. Which I think is actually a reasonable
| argument given the issues in my OP.
|
| I wish the FTC, etc. tweaked how the CAD industry was handled
| to increase competition / decreasing switching costs, etc.
| This relates to them preventing people from being in their
| equivalent of the "app store" which Dassault has been
| particularly aggressive about.
| carabiner wrote:
| Another blocker is that CAD is a relatively small part of
| mechanical engineering. Pretty much all software engineers use
| version control, but depending on subfield/company, maybe
| 20-50% of mechanical engineers will use CAD significantly.
| Mostly the design guys. The engineers in test, analysis,
| materials will barely touch it.
| nickpinkston wrote:
| Though interestingly if you look at the numbers there are
| more CAD seats than MechE's, so I'm guessing a lot of other
| engineers, technicians, etc. are using it.
|
| Test folks have totally different systems like LabView for
| data logging and analysis that don't really talk to the
| simulation tools, CAD, etc. - very fragmented dev tools.
|
| I really like Bret Victor's "Seeing Spaces" vision for a more
| integrated hardware dev environment where it integrated
| software and workshop into an real-world "dev environment":
| http://worrydream.com/SeeingSpaces/
| carabiner wrote:
| I had a SW license for sure when I was a stress analyst .
| I'd use it to look at a part to take a dimension, and maybe
| once a month use it to make a drawing from an existing part
| that would go into a report. I never modeled in it. By far
| the most important software for me was Excel though.
| analog31 wrote:
| I can confirm that. While it's true that the MechE's at my
| workplace all have CAD seats, we also have a number of
| floating seats that get used by a variety of people. There
| are things you can do in the CAD tool, but not in the free
| "viewer" tool, so we provide CAD seats to our manufacturing
| engineers, who also use CAD to design things like jigs and
| fixtures.
|
| I believe it actually takes a bigger and more hierarchical
| engineering organization to have MechE's who are not busy
| at the CAD terminal a lot of the time.
|
| In addition, our machinist has a CAD seat, the machine
| shops that we use all have CAD seats. And while optical
| engineering is a small field, most OE's have CAD skills.
| grumblenum wrote:
| OpenSCAD exists, is perfectly usable, is very cool, and stores
| CAD models 'as code' which is git-friendly. Professionals don't
| use it. I like it, but I would never standardize on it at work.
| I'm sure a more point-and-click front-end is certainly possible,
| but that nobody has tried something quite so obvious probably
| speaks to its incompatibility with use common use cases. I use
| Autodesk software daily, and merely representing 3D objects is a
| very small part of the utility it provides. The software is
| undoubtedly an unstable mess, but feature parity with Revit or
| just Fusion 360 is far beyond a pizza-box team of 'disruptors'.
| There is also a culture of professionalism and practicality in
| AEC that I don't see folks used to coastal VC/startup playgrounds
| doing well in.
|
| I also find it pretty hard to take the contents of an article
| seriously when there's name-dropping of celebrity-developers
| whose business appears to be self-promotion. "I use vim, btw ;)"
| really puts the nail in the coffin for me. I'm sure CAD-but-on-
| electron would look great on a slide deck, though.
| jstanley wrote:
| OpenSCAD is cool and I do use it when it is the most convenient
| tool, but I find it to be _incredibly_ slow, and if you don 't
| want the output to be all blocky polygons (which you can only
| achieve by increasing $fn AFAIK) then it gets even slower.
|
| It also suffers from not having any general-case way to fillet
| or chamfer edges, which means you have to bear your
| fillets/chamfers in mind throughout the entire design if you
| want any (which is why most OpenSCAD designs don't bother).
| dTal wrote:
| There is actually a general-purpose way to do fillets in
| OpenSCAD, using a slightly Rube-Goldberg combination of
| booleans and minkowski sums. Unfortunately it is, again, far
| too slow to be usable in 3d at anything like an acceptable
| resolution. It works great in 2D however.
|
| http://www.scorchworks.com/Blog/openscad-modules-for-
| automat...
| ur-whale wrote:
| > it is, again, far too slow
|
| It also fails miserably as soon as the geometry you're
| trying to fillet is complicated.
| ur-whale wrote:
| OpenSCAD is a neat tool, but it has a few huge drawbacks for
| real world use: - a weird domain specific
| language that only adds a bit of syntactic sugar and is a pain
| to learn. They would have been *way* better off using Python
| and extending it. - no filet / chamfer tool. No
| CAD program can be taken seriously unless it has those.
| - the CAD core is (IIRC) CGAL, which only works with polygonal
| models and is god-awful slow as soon as the model gets complex.
| For example, Minkowski sums are basically unusable on any real-
| world model.
|
| What _is_ really neat about OpenSCAD is the notion that a 3D
| object is basically code.
|
| This brings in for free a ton of very nice things:
| - version control - collaborative editing -
| parametric modeling - object optimization
| alanbernstein wrote:
| As for your first point, this is a pretty clunky workaround,
| but at least it exists:
| https://github.com/SolidCode/SolidPython
| rurban wrote:
| So Jessie is looking for people building KittyCAD. I'd rather
| improve SolveSpace, because this is open source and already
| operational. Solvespace branded as VsCode with collaboration
| tools? Ok, why not.
|
| I think OpenMP is back in again, but the database format is
| important, agreed.
|
| In her vision I miss the importance of CSG, where the brep
| surfaces are created dynamically. Looks like she thinks the
| history and construction of the solid can be thrown away, but
| with thin shells (3d printing!) Lost precision will haunt you.
| You need CSG. This is not modern, this is antique.
| Haemm0r wrote:
| I work with NX and Teamcenter(central data storage amd PLM
| software) daily and find the single threading during almost all
| the design work annoying (except for FE, drawings and maybe a few
| other things). On the other hand the backwards compatibility is
| exceptional, opening 20 year old models exactly as they are and
| rendering the drawings exactly as 20y ago is quite useful (using
| the renderer of the version it was created with, sometimes with
| the ols bugs too ;) ). Expanding NX with custom features and
| custom scripts is quite easy (plugs into MS VS). Afaik as i know
| you could use C, C++, C.net, python or even Vjsual Basic to
| access/modify the data.
| Haemm0r wrote:
| Sorry for the typos; was in a hurry before :/
| phkahler wrote:
| >> Most parametric CAD operations are single-threaded; however,
| the open-source project SolveSpace [solvespace.com], which uses
| NURBS (nonuniform rational basis splines), has some parallel
| operations.
|
| Current Solvespace maintainer here if you have questions on that.
| I did most of the work on making NURBS boolean operations use
| OpenMP for parallel operations. The code is highly functional, so
| that was mostly adding the appropriate #pragmas, but some things
| needed fixes, and some required tricky critical sections.
|
| https://solvespace.com/
| helltone wrote:
| Philosophical question but why do we still use nurbs instead
| of, for example, subdivision surfaces? Is that mostly because
| users want to export to nurbs after editing?
| phkahler wrote:
| >> Philosophical question but why do we still use nurbs
| instead of, for example, subdivision surfaces?
|
| Subdivision surfaces are a generalization of B-spline
| surfaces that predate them. History aside, sub-d surfaces can
| not exactly represent circles, cylinders, or torri. When
| you're designing real objects - rotating machines in
| particular - you want perfect circles. Round wheels and
| bearings. Trimmed NURBS (which result from itersections) are
| also easy to model features like chamfers, where again
| subdivision surfaces may fall down. Pixars creased
| subdivision surfaces probably do a bit better for things like
| chamfers. Nurbs are a better fit for modeling the kind of
| surfaces created by traditional machining operations. You
| wanna make movies? Use subdivision surfaces. Wanna design
| mechanical devices? Use NURBS.
|
| I'd like to see something better, but the industry isn't
| likely to change. Open source is IMHO the way to go with any
| fundamentally new representation.
| bsder wrote:
| How are you handling the fact that it seems like none of the
| computational geometry algorithms parallelize?
|
| Even something as fundamental as line segment intersection
| doesn't seem to have any good parallel algorithms.
| wlesieutre wrote:
| 3.0 is out, congrats on the release! I'd built that myself to
| try it out earlier this year, IIRC the previous stable build
| was 5 years old. Guessing I didn't have the OpenMP version from
| my build, so this should be a performance boost.
|
| Unrelated to parallelism, is there a way to lock the vertical
| axis for orbit, what blender calls "turntable" style rather
| than "trackball"? Coming from an AutoCAD and Blender
| background, I'm a lot more comfortable in that mode.
| phkahler wrote:
| >> Guessing I didn't have the OpenMP version from my build,
| so this should be a performance boost.
|
| The performance in 3.0 is dramatically better, not just from
| the OpenMP. We still have a lot of code that doesn't scale
| well because it's O(n^2) but what is there is much faster.
| There's also a post-3.0 improvement already in one slow area,
| and we hope to get Eigen in there to speed up the constraint
| solver.
|
| >> is there a way to lock the vertical axis for orbit, what
| blender calls "turntable" style rather than "trackball"?
|
| Oh man I forget. You might want to comment on this pull
| request: https://github.com/solvespace/solvespace/pull/956
|
| We obviously can't implement every option under the sun, but
| I think turntable is more asked for than the one implemented
| in the PR (which I haven't even had time to test properly).
| wlesieutre wrote:
| Never mind, I found it! Turntable already exists, it's in
| the second block of checkboxes on the config screen,
| between "enable automatic line constraints" and "edit newly
| added dimensions."
|
| I think that issue is looking for a toggle like Apple's
| "natural scroll direction" where it's a question of whether
| you want the metaphor that pushing your scroll wheel is
| pushing the content up and down or moving the scroll bar
| grip which makes the content go the opposite direction.
| therein wrote:
| I love Solvespace. It really changed the way that I perceive
| CAD when I got into designing 3d printed parts that needed to
| fit together.
| digdugdirk wrote:
| Any thoughts/recommendations on how to get started in the
| software development side of things coming from a mechanical
| engineering background?
| baybal2 wrote:
| What do you think of non-history based CADs using direct
| constraint solving? Can they even hypothetically match history
| based ones on functionality?
|
| As I understand history is a "hack" for low capabilities of 3D
| constraint solvers, which are limited in shapes they can
| express by what the solver can express.
| skybrian wrote:
| Onshape is briefly mentioned. Yes, it's online only, but it's
| also free if you make your designs public, and as a hobbyist
| tinkering with 3D printing, I find it a good tradeoff.
|
| The constraint system is elegant but took some learning since
| there's a geometric puzzle aspect to it. I find it nice for
| making simple revisions like changes in dimensions. (For more
| extensive revising, it seems easier to delete that part of the
| sketch and redraw it.)
| hrdwdmrbl wrote:
| Innovators dilemma. I have worked at Autodesk on a project to do
| exactly this and seen it happen.
| paddy_m wrote:
| I have been working to script Autodesk Fusion 360 with python
| recently. Programming against this environment is tough and
| frustrating. A couple of things I have noticed
|
| 1. Using the API is far from intuitive. There are many objects
| that you have to use from the API that have no _named_ corollary
| in the UI. I know BReps are a thing (probably faces) but there is
| no way to name a face in the UI and find that via the debugger. I
| have to poke and prod to try to create the objects to build the
| things I want to. 2. Limited documentation. The APIs and object
| tree are documented, but examples are often limited 3. Poor
| programming environment. It is nice that there is a debugger mode
| that works with vscode, but this debugger connection frequently
| breaks, requiring tabbing back into fusion, restarting the
| debugger, tabbing back to vs-code, restarting the debugger... 4.
| Most examples are written by non-programmers. I have seen a
| couple of examples of object graph printout programs, instead of
| building up a list of lists or objects, these programs intertwine
| navigating through the tree with print indentation.
|
| That said, I just found this repo [1] which looks well written.
|
| On the other hand, CAD software is much more complicated than
| most systems I interact with. CAD platforms are one of the few
| remaining software systems that are written for experts.
| Experienced practioners are very productive [2]. So programming
| these systems will also be complicated.
|
| FWIW I'm trying to template a bunch of part imports and their
| layouts. I'm surprised that this isn't built into the system. You
| can edit variables for almost (almost) every input in the system,
| you can name variables and elevate them to file wide variables -
| all without touching programming. I wish importing was
| parameterized such that upon import I got a chance to edit the
| filewide variables as parameters in the new document.
|
| [1]https://github.com/JesusFreke/fscad/blob/master/src/fscad/fs..
| . [2]https://youtu.be/G3rho-24DWQ?t=184
| wrnr wrote:
| I've been trying to build a CAD system, where the node's of a
| model are stored in a content addressable network, a bit like
| glTF but with CSG or BREP instead of meshes.
| dekhn wrote:
| There's a whole subquestion the article mentioned mostly as an
| aside: version control systems don't facilitate multi-way merging
| of binary/complex file formats. I don't know that anybody has
| developed a good solution to this (that scales to large numbers
| of different formats), and "just use a text file format" doesn't
| really work for complex models where changes don't appear like
| minimal diffs.
|
| I invested fully in FreeCAD, it does support pointers and
| instances for many ops, but the reality is that you have to
| instantiate all the instances in 3-space if you want to do
| complex geometry conflict checking.
| GloriousKoji wrote:
| I'm not sure what method it's using (if any) but Perforce is
| the prevalent version control system for most industries with
| large files. I think most programmers have heard about it from
| it's integration with the Unreal engine but as a hardware guy I
| know it's used at a lot of semiconductor companies for things
| like managing versions of the various CAD required (layout,
| schematic, HDL, etc.)
| ofrzeta wrote:
| This might be possible if the binary format encodes a sequence
| / tree of CSG operations. A binary blob might be difficult to
| merge / conflict-resolve for humans.
| krapht wrote:
| Even if you had that representation, resolving merge
| conflicts would be a huge headache. Imagine resolving code
| conflicts by resolving things at the AST level.
|
| Forget CAD, we don't even have a good way to version control
| images, something programmers work with every day, besides
| "use Git LFS and pretend an image is just a pointer".
|
| edit: just saw GumTree mentioned above. Guess I have
| something to check out...
| ofrzeta wrote:
| Of course not possible with images as a binary blob but it
| could be possible with a series of operations on a (vector)
| image ("event log").
| dTal wrote:
| >Imagine resolving code conflicts by resolving things at
| the AST level.
|
| This sounds extremely nice actually. The more semantically
| aware the version control system is, the more likely it can
| gracefully handle merge conflicts. A textual diff is a very
| low level transformation primitive; composing them doesn't
| guarantee very much at the higher level.
| regularfry wrote:
| Coming at it from the other end, you may or may not already be
| aware that one of realthunder's branches (can't remember which
| right now but probably LinkStage3 since that's where the action
| seems to be) lets you save the .FCstd file as a directory so
| that you can commit it to git. I've not tried it myself yet to
| see how useful the diffs are, but it's not unfeasible to think
| there's some value there.
| zokier wrote:
| GumTree does AST level diffing, hypothetically one could build
| VCS on top of that. That would work for binary files as long as
| they are parseable to some sort of sensible AST.
|
| https://github.com/GumTreeDiff/gumtree
| aardvark179 wrote:
| I worked on this type of problem in the context of structured
| data in a version managed database, and you need more than
| just an AST.
|
| These types of systems have lots of extra cross dependencies
| and complexities so to resolve changes you need enough to
| effectively replay changes from one branch onto another.
| You'll find points where this will not work and at that point
| you need to be able to present the user with self consistent
| alternatives to choose between, and a way to safely save and
| recover the other data while they do this. That goes through
| the entire application stack and UI.
|
| The stuff I worked on all worked, but every application and
| customer that built on our core needed to develop custom
| rules for their work flows, and I'm not sure many ever did.
| zokier wrote:
| > you need to be able to present the user with self
| consistent alternatives to choose between
|
| That seems very high bar to aim for compared to git (and
| other traditional VCS), which do not ensure that the end-
| result of a merge (or rebase) is in any way sensible.
| aardvark179 wrote:
| It is a high bar, but consider what happens when you get
| an inconstant merge. With text representing a program you
| get a compiler or interpreter error and can view and edit
| the text to fix things up. With something like a CAD
| drawing you may not be able to open the file, or it might
| be almost incomprehensible to the user (if you broke
| coordinate transforms or accidentally combined sub
| assemblies or something). If you are really unlucky you
| end up with something that looks okay but subtly breaks
| the application in a way you will not notice for a long
| time, and then it's going to be hard to fix.
|
| Oh, and you need to implement this for every file type.
| someguy321 wrote:
| I'm a mechanical engineer.
|
| The version control software that we use (I'm most familiar
| with Windchill, and just a wee bit familiar with SolidWorks
| PDM) is dumb. It's a B2B market with fat margins that is ripe
| to be disrupted.
|
| Typically in Windchill, a part has a part number, and can be
| checked out and checked in, iterated, and revised, in
| operations that are non-intuitive and difficult to reverse. If
| you ever wanted to build an assembly using older versions of
| current parts, the process to figure it out might take 100
| clicks, or might not be possible depending on how your system
| administrator set things up.
|
| Merging (in the style of git) is generally a completely foreign
| concept, and engineers generally avoid collaborating on a
| single part or assembly file for that reason. Dividing up the
| interior of a vehicle's engine bay, for example, is best done
| as separate assembly files that are only later brought together
| as a parent assembly. Communicating about the volumetric
| boundaries of these assemblies is complicated.
|
| I'm often aware that I could be more productive and adaptable
| using a git repo (or similar) containing my parts, assemblies,
| and drawings than I currently am with Windchill's specialized
| system. Haven't ever seen it in the wild, though.
| ryegar wrote:
| Completely agree, there is a lot of opportunity here. I have
| extensive experience using Solidworks, its PDM and another
| vault software (Adept, don't get me started). Collaboration
| on reasonably complex assemblies is rarely worth the effort,
| it's easier to communicate in other channels and link up at
| the end. File versioning is needlessly complicated and often
| frustrating, especially for less tech-savvy designers.
| frontiersummit wrote:
| I've used Windchill extensively and I've set up a Vault
| instance (the Autodesk equivalent). I completely agree with
| what you are saying. At most companies, there is a "Emperor's
| Clothes" scenario where even the expert users and
| administrators have no idea what's going on under the hood,
| or how to execute advanced operations. (granted, Git has the
| same issue sometimes, let's face it) To make matters worse,
| Windchill has quite possibly the worst UI of any software I
| use --- first off, it runs in an instance of Internet
| Explorer embedded in the Creo CAD package. Few icons are
| labeled, and the UI is not discoverable at all. Google is
| often no help, since it is relatively niche BTB software.
| Doing what the parent suggests, using old versions of parts
| in new assemblies, is only reliable when saving the old
| versions out as a "dumb solid" like a STEP and re-importing
| them into Windchill. Part of the issue is that version
| control and databased file systems as a mental model do not
| align very well with how the human brain operates. The
| hierarchical structure rules the day in the end, because it
| aligns well with how we think.
| bobjordan wrote:
| I met the founder of Grabcad when he made a trip to
| Shenzhen China around 2012. I took away that he was trying
| to build the "github for CAD". We tried the Grabcad system
| out in our office for a while and it was useful but didn't
| really meet that vision. I haven't tried it since the
| company was acquired by Stratasys in like 2014 but a quick
| login looks like it hasn't changed much.
| SV_BubbleTime wrote:
| I deployed PDM at my company. It works fine, and even for
| people who don't really know what version control is.
|
| Multiple downsides though... cost, only really wants
| Solidworks files (although does handle everything as
| binaries), but the worst and most unforgivable issue...
|
| They keep full versions of every file, at every check in...
| forever.
|
| If you have a 500MB file, change the color, and check it it,
| you now have 1GB of file space taken up, with no clear way to
| cut that down! Coupled with the fact that deleted files don't
| delete until someone manually does a destroy operation, it's
| a storage space murderer.
| HPsquared wrote:
| Lots of programs have an "undo" feature, perhaps the history of
| this could be saved along with the files.
|
| EDIT: that is, saving all user inputs used to generate the
| binary files in a text format.
| gopalv wrote:
| > Just as I would use Vim for side projects as well as
| professional jobs, I would expect my CAD tool to work just as
| well for building a toy for fun as it would for a complex
| project.
|
| Not picking on the specific editor there, but that's a high skill
| tool we're talking about which is full of repeated memory effort
| (or "muscle memory"), with layers in it.
|
| The reference to Jai in this context is probably equivalent,
| since it is a programmer's tool for a programmer's need to
| automate/repeat the same operation.
|
| The best thing in this whole article is that as more programmers
| work on problems which require CAD, the more likely they are to
| solve the problems they run into, but in ways that works for them
| directly (think Linus, git and emails).
|
| The second part was always the hardest (the "make") at the toy
| project level.
|
| In the bay area, the death of TechShop is unfortunate though,
| where getting a CNC machine time (& my python madness with printf
| of g-code) meant things went from patterns to real.
|
| Like, I'd love a 3-d equivalent to graphviz's dot for
| representing a 3-d scene in a minimal way for navigation through
| it, but not for actual manufacture (though things like SPICE went
| both ways in the end for me).
| etaioinshrdlu wrote:
| I suspect another breakthrough will be of a completely different
| nature: having the computer reverse engineer voxel or polygon
| models back into a tree of features (something like solidworks).
| The user gains much easier editing an object as a series of
| understandable steps instead of a blob of polygons.
|
| This is a pretty crazy difficult CS problem! There's a bunch of
| research papers using deep learning to solve this, and it is
| starting to work, although in very limited domain. (Relatively
| prismatic objects.)
| frontiersummit wrote:
| User of 3D CAD here. The reason this is so hard is that a
| part's geometry will be governed by a different set of
| parameters, depending on its function, and the software will
| not know the function of the part, unless is was written by a
| domain-specific expert.
|
| I'll give the simple example of a hex-headed nut: how will the
| software know that the flat-to-flat measurement is critical
| (since it corresponds to the wrench/spanner needed to drive it)
| rather than the point-to-point measurement? In less trivial
| examples, questions like this need to be though out when
| creating models, and require domain-specific knowledge that a
| ML model will not have.
| ur-whale wrote:
| > This is a pretty crazy difficult CS problem!
|
| I suspect machine learning, and specifically GPT-3 style
| transformers, is the perfect tool to solve this.
|
| Especially given the fact that you can basically generate an
| infinite training set automatically using a parametric modeler.
___________________________________________________________________
(page generated 2021-06-15 23:01 UTC)