For the possible future Draft workbench, I would suggest to go for something similar with the current Sketcher WB. When you editing a line, you are seldom changing just that line, there will be many connected lines affected, as well as many possible attached annotations. It will be better to handle all those internal structures within the draft object itself. It is different from assembly as the assembly WB does not handle geometry modeling directly, it's just there to arrange them. On the other hand, drafting creates and manages everything by itself.triplus wrote: ↑Thu Apr 18, 2019 1:37 amP.S. Initially you said this might not be a suitable use case for drafting purposes. But i don't' see all that much difference, compared to an assembly. An assembly can have a million parts, suppressing their document objects and resulting to visual representation, promoting only the document objects of parts one will use for adding relations. This doesn't differ all that much. Compared to importing a DXF with million lines. Showing the resoult on the screen only as a visual representation, promoting only the document objects of lines to be edited. It's a bit of an unorthodox approach for tackling 2D drafting, suppressing and promoting of elements involved, but in return you get an ability for viewing and editing huge amounts of 2D geometry, just like with assemblies.
My partial document loading is already somewhat like this. It allows loading document on demand, instead of objects. It still lacks some features like unloading on demand, and maybe loading/unloading object on demand, which is a lot more complex because of the dependency issue.fosselius wrote: ↑Thu Apr 18, 2019 6:38 amnow this sounds like an good optimization, the renderer or graphics libraries also have its own selection support. if the graphical representation then have a object id that we can correlate between the graphical and actual object then some signals might be possible to forward to the actual object once loaded.
you could load actual objects once selected or load object close to the "area of intrest" on the fly.
Sketcher object has (internal) elements too. Therefore i don't know if it would be able to handle large amount of them, all are listed in the sidebar. Developers would more an more like to have this (internal) elements exposed externally, as i guess document objects.realthunder wrote: ↑Thu Apr 18, 2019 11:44 pmFor the possible future Draft workbench, I would suggest to go for something similar with the current Sketcher WB. When you editing a line, you are seldom changing just that line, there will be many connected lines affected, as well as many possible attached annotations. It will be better to handle all those internal structures within the draft object itself. It is different from assembly as the assembly WB does not handle geometry modeling directly, it's just there to arrange them. On the other hand, drafting creates and manages everything by itself.
I got the following response https://www.reddit.com/r/AskEngineers/c ... an_handle/ from a Reddit forum:realthunder wrote: ↑Thu Apr 18, 2019 12:27 amWell, I can't, since I haven't used those software. And I think we may need someone inside the automobile or aviation design industry to tell us the real difference, not just someone who have 'used' the software. Another thing, CATIA and SW are from the same company, so obviously they won't compete with each other.Mark Szlazak wrote: ↑Wed Apr 17, 2019 5:41 amCan you elaborate more how strict protocol enforcement would allow software like NX, CREO, CATIA larger assemblies even over the latest version of Solidworks (2019)? An example may help. I can pass this onto teaching assistance since what they say does not seem right or more like hand waving. Thanks again and look forward to your work.
A second post suggests Solidworks mates as a culprit:I can't give you an in-depth, technical look into the fundamental workings of the SW engine - because I don't know. But I can say that what people say is true.
Solidworks can handle large assemblies, in the same way that MSPaint can do everything Photoshop can do. Building large assemblies in Solidworks requires being acutely aware of and very strict about number and type mates, feature order, which features you use, how you build your subassemblies, etc. Get one thing wrong and you might increase your build time by 50x due to a mate chain or rebuild chain or circular reference that will take all day to track down. Solidworks also does not handle zero-thickness geometry, which nearly all other CAD packages do. This comes up all the time, especially with manufacturer CAD or parts imported from other packages. For instance, at work we use both CATIA and Solidworks. You'd think that being from the same company they'd be pretty compatible. Almost every model imported from CATIA is loaded with import errors. We have STEP files that take literally hours to import where the same part takes a couple of minutes to open in CATIA.
Add a team, where nobody ever agrees on assembly strategies and etc. and the problems get worse.
Can't really talk to the software side, but I feel the problem is the mates
but as far as strategies to make larger assemblies somewhat usable some stuff that I have done is used lightweight settings on all components, make a simplified representation or configuration that excludes stuff like fasteners or any kind of complex geometry, and also mate 1 component or sub assembly at a time and when it's in its position delete the mates and make it fixed
All that being said I've had difficulty with assemblies as small as 20 or so components
the problem is not so much the number of parts in the assembly but the number of details to draw: if you have a large assembly (large in dimension, length) and have very small features inside, and if the renderer doesn't do anything fancy but tries to draw everything by brute-force, you can end up calculating a vast number of complex features with sizes of less than a pixel, meaning the work is done for absolutely nothing.Mark Szlazak wrote: ↑Tue Apr 16, 2019 5:08 amSome class teaching assistants claim that CAD products like NX, CATIA and CREO can handle very large assemblies of say 100,000 parts while Solidworks (maybe not Solidworks 2019) and others cannot. Usually unsatisfying answers are given as to why this is so.
I think that Coin3D will quite fast become the limiting factor in FreeCAD. And its tight integration with the UI. Ideally, you'd want GUI and Viewer window be as separated as possible, to the point where you could use different viewers for different use-cases (think ray-tracing for photo-realistic views)By default, the OpenSceneGraph uses small-feature culling, meaning that when an object becomes very small in the current view (roughly a few pixels) it will be culled.
if you make an assembly of assemblies and sub-assemblies, the resulting master assembly can get very big very fast.
There's been discussion about this.
Thank you. My question was more why Solidworks cannot handle very large assemblies while those others can. My previous post is copied from Reddit AskEngineers which says it can but you have to be really careful how you do things. Apparently, all the nice automation in Solidworks (some might call it bloat) is the culprit. At least that is my interpretation. So my next question is "can you have all this nice automation, ease of use and very large assemblies?"fosselius wrote: ↑Fri Apr 19, 2019 7:50 amhttps://www.technia.co.uk/catia-v5-perf ... ssemblies/
"The reason for the freezing, or delay, is usually due to the presence of an Inertia Measure within the assembly. Depending on a certain setting within the main CATIA options, the Inertia Measure is recalculated every time the product is updated. This can mean that every time a part is moved within the product, the Inertia Measure (including the centre of gravity and inertia) is updated."
so if the biggest issue catia have with several 100 parts assemblies is inertia calculations?
assembly guide for http://www.catia.com.pl/tutorial/assembly_design.pdf