>Becoming a book publisher wasn’t on my bingo card when I started Shapr3D. Yet here we go! For now, it’s only available to select customers—but if there’s enough interest, we’ll make it accessible to the public. The book spans 860 pages and weighs approximately 3 kg—just as heavy as CAD is.
Become a select customer of Shapr3D and their CEO István Csanády might send you one.
Good luck guys! I watched the video on YT - hopefully will get around to trying the Fusion 360 add-in at some point.
Does the current add-in use AI at all?
What is your plan when, in the event of you getting some traction, Autodesk etc. copy you innovations into the main product?
As per my other comments [1][2], I worked on this area at D-Cubed and Solidworks from 1995 to 2002. Feel free to connect with me via twitter DM @delhanty [3].
Great questions. This beta version uses very little, but we hope to incorporate more over time, hoping to get more accurate and better suggestions!
If we can get the entire industry producing better products, everyone wins. This is something we feel passionate about, and think there must be a better way.
I would love to get in contact with you to chat more!
> And if this add-in becomes popular, Autodesk can trivially release something that has the same functionality, built into Fusion 360 by default. And, as you are no doubt painfully aware, the Fusion API can be limiting.
This is always the problem with add-ins like this as a business - you're essentially doing free market research for the application vendor.
> The Fusion sketch solver is badly compromised, it can't do more than two or so simple successive Tangent relations without bugging out. And, my experience with Solidworks is the same, not sure if this is still true.
In my experience of building a sketcher at D-Cubed for a consultancy client (1995-2000) on top of D-Cubed's DCM, this is because DCM's curves (which are unbounded BTW) are not directed so that there are lots of erroneous solutions to attempting to constrain G1 chains of tangent bounded curves. For example the Apollonius Problem [1][2] of 3 tangent circles/lines has 2^3 = 8 solutions. IMO if John Owen had chosen directed curves for DCM then dragging configurations of tangent circles would be more stable.
I'll end with a quote from the Preface of Julian Lowell Coolidge's 1916 "A Treatise on the Circle and the Sphere" [3]:
> Among the cartesian theorems there is a sharp sub-division between those where the radius is looked upon as essentially signless and those where a positive or negative radius is allowed.
Thank you for the great response, that does mirror my experience, those tangent curves want to flip/change direction.
I can't believe that all of Fusion, and many other CAM software, is built on such a shaky "sketchy" foundation. It seems that in general 2D sketch constraint models are far from solved in computer science, this seems ridiculous as such a basic and elementary problem. It should be so obvious that the tangent doesn't want to go back on itself to create zero thickness geometry.
Wonder if the 2D sketch experience is much better in Onshape, NX, Catia, etc?
> Wonder if the 2D sketch experience is much better in Onshape, NX, Catia, etc?
Well those systems and pretty much all of the mechanical CAD industry is built upon D-Cubed's DCM, so I'd expect the behaviour to be the same.
If I was creating a new 3D CAD system from scratch now I'd probably license Parasolid eventually, but I'd pass on DCM.
I don't want to dump on D-Cubed and John Owen though. I have huge respect for him and the company he created. This is technical criticism with the benefit of hindsight.
> I've been using parametric CAD (Pro/E / Creo, Solidworks, and Onshape) for 30+ years.
True - I implemented the first Solidworks Autodimension sketch as a contractor around 2002 based upon earlier work that I'd done for a consultancy client at D-Cubed in the late 1990s. I'm sure it could be improved with AI and a large data set of sketches though.
> Solidworks tries to help with this in the form of cycling through what it thinks are the most likely constraints to remove and then re-solving the sketch. It's OK, but that sort of tool could be better.
I agree it could be better. The behavior with under-constrained sketches depends on D-Cubed's DCM, and I seem to recall they were rather floppy. It seems kind of ridiculous to make users jump through the hoops of making sketches fully constrained once they've added the constraints they care about.
I am not an expert but surely an under constrained sketch is not a completed sketch.
Does "fully constrained" mean the simplest set of constraints that yields a shape (volume/hypervolume)? Or something rather more complicated? A simple yes or no, with a pointer to a paper will do!
To add to delhanty's reply, a "degree of freedom" can be thought of as a dimension of the drawing that can be changed or "stretched" or moved without violating a constraint (this is slightly inaccurate, but it's a good start). In a CAD program, a fully constrained drawing can't be freely stretched or dragged around; the program won't let you and the drawing will feel "rigid".
It's very intuitive if you play around with a CAD program for a bit. There is a free (GPLv3) 2D and 3D CAD program called Solvespace (https://solvespace.com/) that is probably easiest one to obtain and learn. There are detailed tutorials on the website, and you could probably download it and finish the first tutorial in an hour.
the Github page of which has the following footnote:
>I ended up directly using solvespace's solver instead of the suggested wrapper code since it didn't expose all of the features I needed. I also had to patch the solver to make it sufficiently fast for the kinds of equations I was generating by symbolically solving equations where applicable. ↩
Which really impressed me because it was the first graphical and interactive 3D program I tried which felt sort of comfortable and understandable (which is why I mostly use OpenSCAD and similar programmatic approaches).
In Fusion 360, you can drag underconstrained parts of the sketch around with the mouse. So the “degree of freedom” is still specified, but by accidental placement of how you drew the sketch. Fully-constrained sketches show a black outline and can’t be changed without explicitly editing a constraint or dimension.
"fully constrained" means that there are no degrees of freedom left so that there are only a finite number of valid solutions, which are then consequently disconnected in the space of possible solutions.
DCM then chooses one valid solution that it believes is "close" to initial supplied positions/directions/radii etc for the geometry.
>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today.
Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer environment might have evolved since the OP left in 2019?
The biggest difference not mentioned is the article is that code is no longer kept on developer machines. The sync process described in the article was well-designed, but also was a fairly constant source of headaches. (For example, sometimes the file watcher would miss an update and the code on your remote machine would be broken in strange ways, and you'd have to recognize that it was a sync issue instead of an actual problem with your code.) As a result, the old devbox system was superseded by "remote devboxes", which also host the code. Engineers use VSCode remote development via SSH. It works shockingly well for a codebase the size of Stripe's.
There are actually several different monorepos at Stripe, which is a constant source of frustration. There have been lots of efforts to try to unify the codebase into a single git repo, but it was difficult for a lot of reasons, not the least of which was the "main" monorepo was already testing the limits of the solution used for git hosting.
Overall, maintaining good developer productivity is an extremely challenging problem. This is especially true for a company like Stripe, which is both too large to operate as a "small" company and too small to operate as a "big" company. Even with a well-funded team of lots of super talented people putting forth their best efforts, it's tough to keep all of the wheels fully greased.
Glad to see that they moved to code living with the execution environment. The code living separate from the execution environment seemed like too much overhead and complexity for not enough benefit.
Especially given VSCode, or Cursor ;), work so well via ssh.
To the engineers that don't want to use those IDE's it might suck temporarily, but that's it.
IntelliJ is also supported. If you want to use something else, like VIM, then you need to ssh into the remote devbox machine. They have support for custom dotfiles, so you can set up your cool VIM environment for all your remote devboxes.
If you don't want remote devboxes, the regular devboxes still work. You just need to deal with the additional pain for syncing the files.
* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.
* Big investments into bazel.
* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".
That last point has long been a red flag when interviewing. A developer who doesn't care about their tooling also tends to not care about the quality of their work.
I'd rather work with developers who are flexible and open minded about the conditions they can work in than those who get notoriously pissy if things aren't set up exactly the way they like it. Especially when that way is ridiculously elaborate and non-standard.
I'm glad to see that first bullet point. The code living separate from the execution environment seemed like too much overhead and complexity for not enough benefit.
Not ex-Stripe but in "close relationship" with them since its inception and there's a clear mark in my calendar circa end of 2018 when their decisions and output started to become... weird, or ill-designed.
I don't think it has to do with the dev environment itself, but I'd blame such thing for allowing to deliver "too fast" without thinking twice. Combine that with new blood in management and that's an accident waiting to happen *
They're the best in business still, but far from the well-designed easy-to-use API-first developer-friendly initial offering.
Though I am under the impression that things have gotten more sensical internally over the last year or so.
Note also that the devprod team has largely been shielded from the craziness, and may still be making good decisions (but I don't know what they are in this realm personally).
I was only there in 2022, but at that point there were in fact three or more monorepos (forked roughly based on toolchain - go and scala in one, primarily Ruby in the one detailed here, and there was one for the client stripe api libs that was JS only. There may have been more.
Become a select customer of Shapr3D and their CEO István Csanády might send you one.
https://twitter.com/istvan_csanady/status/188829861216722566...