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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !3dprinting@lemmy.world
3DPrinting is a place where makers of all skill levels and walks of life can learn about and discuss 3D printing and development of 3D printed parts and devices.
The r/functionalprint community is now located at:
!functionalprint@kbin.social
or !functionalprint@fedia.io
There are CAD communities available at:
!cad@lemmy.world or !freecad@lemmy.ml
Rules
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia. Code of Conduct.
Be respectful, especially when disagreeing. Everyone should feel welcome here.
No porn (NSFW prints are acceptable but must be marked NSFW)
No Ads / Spamming / Guerrilla Marketing
Do not create links to reddit
If you see an issue please flag it
No guns
No injury gore posts
If you need an easy way to host pictures, https://catbox.moe may be an option. Be ethical about what you post and donate if you are able or use this a lot. It is just an individual hosting content, not a company. The image embedding syntax for Lemmy is 
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.