For the vertex biconnected components can you say how your implementation compares technically with Boost Graph library's `biconnected_components` and `articulation_points`?
The Boost algorithm computes the vertex-biconnected components rather than the edge-biconnected components, which are two different but related concepts. Articulation points are also more related to vertex-biconnectedness than to edge-biconnectedness (articulation points are vertices that lie in multiple vertex-biconnected components, i.e., if you remove one you split up the graph into more components). From what I can see in the Boost docs, it doesn't have an implementation of edge-biconnected components.
You can write an algorithm to compute all of the articulation points & bridges & edge-biconnected components & vertex-biconnected components in a single DFS. Because of this you refer to all of them as just "Tarjan's algorithm" even if you just compute one of them (he is kind of the Euler of graph algorithms in that like half of graph algorithms is named after him). So, on a technical level, I guess my implementation is similar to the algorithm in Boost because they both use DFS and this `low` map, but they compute different things.
Finding the vertex-biconnected components next to the articulation points involves more work though (the implementation I used to have manages to also do it in the same pass but also maintains a stack of edges).
Vello is general purpose, like Rasterizer, but is based on GPU compute. Rasterizer uses the 'traditional' GPU pipeline. Performance numbers for both look very competitive, although Vello seems to have issues with GPU lock up at certain zoom scales. Rasterizer has been heavily tested with huge scenes at any scale.
The longer answer is that using straight-edged geometry to represent curves is a resolution-dependent operation, e.g. a full screen circle may need to be flattened to an 80-sided polygon.
Rasterizer can solve quadratic curves in the fragment shaders, which massively reduces the geometry needed for a scene.
Also, the native rasterizer only supports MSAA, which is inferior to reference analytic area AA.
> They introduced a feature that took me hours and hours to disable (the file not downloaded until you try to open it thing). One bit of documentation pretty much lied about turning it off. Turned out it had to be disabled in more than one place.
Are you able to say what the relevant settings are? (I would like to be able to do that too ...)
As someone who has been mitigating and managing chronic pain for 25 years, with respect IMO your expectation is unrealistic.
There isn't a "solution" - you're looking at a life-long mitigation and management strategy that will not be "brief".
The time commitment typically goes up as one ages. I could spend 40 hours a week on nutrition, exercise and relaxation if I was trying to optimize for chronic pain reduction.
>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.
https://www.boost.org/library/latest/graph/
https://www.boost.org/doc/libs/latest/libs/graph/doc/biconne...
Am I correct to suppose both are C++ implementations of Tarjan's algorithm?