I’m gonna need help, y’all. I’m a single-part amateur hack with a penchant for anything cheap. I don’t know enough to make it what you’ll want it to be, but I am very interested in the broader industry and also its impact on maker hobbies. You want Solidworks advice? To gripe simultaneously about enshittification and the limitations of free tools? Need to dive into Lasering or Machining or CNC’ing stuff and don’t feel like the 3D printing community is quite the right place? Come on over.
I will keep posting stuff that I find interesting, and I will mod as long as doing so doesn’t make me hate life, but if nothing else the name is now parked with an active user.
I updated the sidebar with this. I like the comparison on github.
I might try and break down why exactly the topological naming issue is not a “problem” and why it is actually beneficial to learn how to design while it is in place. I doubt the information is public for all of these other CAD packages, but how they each address the TNI versus π would be most interesting in my opinion.
It is all patches and hacks under the surface with all proper design methodologies revolving around the TNI. Obfuscating it makes the resulting failures a big mystery to the ignorant end user. Then the whining is shifted to “bad software bugs” when in fact it is ignorant user. I think this is the primary reason FreeCAD is so slow to obfuscate TNI with a hack. Even Solidworks had a TNI in place in the beginning. The professional gurus that can fix anything in CAD are all addressing the issue with a TNI mindset while looking for obscure references that somehow invoke π.
I’m no professional, but it does seem that many of the ways to design around TNI, e.g. defining reference planes for sketches that are associated with geometry via shared variables rather than a face earlier in the tree, are ripe for automation and/or are very sensible to obfuscate under a layer of abstraction. TNI doesn’t strike me as inherent to the way designing a solid object needs to be, but rather that it’s difficult or impossible to avoid based on the code that actually makes a 3D solids kernel work. To my mind, it seems like awareness of its persistence is sufficient if you have a mature set of workarounds and heuristics that make the software act predictably. I suppose it does promote lock-in and precludes a truly complete and portable file format though; the solution is clearly for one of the big 3-4 industrial suites to open-source itself!
As for that github table, I’m all ears about expanding it or correcting anything that might be wrong with it. The “real” one on wikipedia is rather daunting and necessarily for a broader audience.
TNI is not about planes. It is about the linearity of the tree, the truncation of infinite numbers, and the loops the tree must patch on in order to break a linear branch of the tree. These breaks create a cascade of problems that are not possible to address because the information required is missing once the initial reference is created and truncated at the register level. It is not a single reference issue. All references down tree are relative and themselves often truncated. Breaking the tree is always the wrong thing to do. Yes it can be done as a hack to do something quickly, but that is just a hack. Stacking hacks is terrible design. This is the difference between a good designer and the bad. It is all about a linear tree and π.
I can design without any reference planes and just offsetting my sketches. I never use faces or import 3d geometry. I am very intentional about what references I import and those I do not. I also make some sketches as references only, and these are used to alter other sketches down tree. All of this is TNI centric.