Assembly3 preview

[triplus]

OK therefore it will be possible to delete the linked document object and for visual representation to persist. Now i guess the question is, this is not related to Link directly, can one delete the document object, by not actually deleting it. Therefore for it to still be there, on demand.

P.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.

[fosselius]

now 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.

[realthunder]

P.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.

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.

now 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.

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.

[triplus]

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.

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.

P.S. Anyway, at some point in the future, likely large number of document objects will start to represent real (performance) challenges. And then we can discuss again, on how we could manage document objects more efficiently. I agree that from pure Link effort point of view, such effort is out of scope.

[Mark Szlazak]

Can 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.

Well, 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.

I got the following response https://www.reddit.com/r/AskEngineers/c ... an_handle/ from a Reddit forum:

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.

A second post suggests Solidworks mates as a culprit:

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

[fosselius]

https://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

[Zolko]

Some 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.

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.

It's like when you use GoogleEarth and look the Earth from very far, the Eiffel Tower is not rendered, but when you zoom in the Eiffel Tower is there.

To use such feature, either you can have some sort of fractal representation of your object with different levels of detail depending on the on-screen size, or a clever renderer might first calculate the bounding box of an object/feature, and if it's smaller than a given size on screen (in pixels) then the object is not calculated but drawn as a blob. That's what OpenSceneGraph does:

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.

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)

Second thing that one may wonder is why would an assembly of 100,000 parts be made in the first place.

if you make an assembly of assemblies and sub-assemblies, the resulting master assembly can get very big very fast.

[Kunda1]

I think that Coin3D will quite fast become the limiting factor in FreeCAD. And its tight integration with the UI.

There's been discussion about this.
Checkout this 2017 thread discussing if FC should fork coin3d because it was not actively being maintained.
Also this thread I recently created: Coin3D - FreeCAD Delegation to help move Coin3D forward

[Mark Szlazak]

https://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

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?"

[andrew.j.smart1988]

Please help me know if there is a way to reduce memory consumption. Nevermind, looks like re-importing the STEP model with this Assembly3 branch helped significantly.

Real world example here. 205 unique parts (but multiple instances of many parts, approximately 260 or so rendered parts).

Non-Assembly3:
2.8 GB memory usage from 43.3MB on disk (default file compression setting of 3).

Assembly3 (each Assembly3 container put into separate file):
5.5GB memory usage from 70.9MB on disk.
4.2GB memory usage when top level sub-assemblies are frozen per this advice.
And this is not even using the solver.
To make this I changed the groups (which were set up by the STEP import of FreeCAD 0.17) to Assembly3 assembly containers and separated the assemblies into individual files. I only added constraints to the bottom.


There is a problem with the in-memory representation of these parts. Is there any way to reduce the memory consumption? With 8GB memory I'm unable to use a browser while editing the full model! Further, with the parts I intend to add I'd expect to run out of memory using FreeCAD-Assembly3.

I did see advice elsewhere of changing threaded screws to plain cylinders (among other geometric simplifications) to reduce memory consumption, but it's hard to get to that point, and I expect there are other ways to reduce memory usage (i.e. 5.5GB -> 2.8 GB somehow?). There are duplicate parts I can simplify (I expect will lower memory usage) using Assembly3, but again it's hard to do this without my reference material open within a browser.

I don't believe something analogous to openscenegraph would be helpful here in this example, the parts/assemblies themselves appear to be represented using too much main memory. Openscenegraph analogy would be more useful for lowering/optimizing GPU memory/processing usage per the scene's demand (raise frame rate, more detail when zooming in, work around GPU bottlenecks and all that). I hardly believe that lowering detail (lowering GPU load), or unloading parts not visible to the camera from main memory will help this peak main memory usage problem.

I'm using Debian Linux, x64_86 and the most recent Assembly3 release.

EDIT: I do see this ReduceObjects parameter I can change, I'll try to re-import the STEP file.

EDIT2: Oh, this looks relevant. I guess the solution would be to put all assemblies back into one document?

EDIT3: Ok, I re-imported the step file using the assembly3 release (ReduceObjects=true) instead of FreeCAD 0.17, and that appears to have shrunk down the main memory usage to 1.7GB and disk representation to 20MB. It did a much better job importing the STEP file, I see duplicate instances appear to be linked instead of copied. Looks much more promising now.