Libraries and Polygons

[Patrick M]

Digging through the "prokit", stumbled across this gem. Its a ±1,000 poly wine glass. Maybe you need 6-8 for a place setting in a rendered view for a client presentation. this sounds great. maybe you are working on a restaurant project, and you need 200 of these (yeah, there are better solutions), so now you find yourself with 200,000 polygons in wine glasses.

So I'm not posting to dig on this object, but more to open a discussion on what your thresholds are for polygon management... and maybe to ask again "why is the polycount add-on a goodie, as an afterthought, and not integral to the software?".

For me, I try to enforce these rules for all library parts/objects in archicad:

-no object placed in a single instance should be over 15-20,000 polygons. For things like feature chandeliers or focal point furniture pieces.

-no object placed 10-20x should be over 5,000 polgyons. Looking at dining chairs, plumbing fixtures, etc.

-no element placed 20+ times should be over 1,000 polygons

-not all polygons are equal. 75,000 polygons in meshes or morphs will slow a file down more than 750,000 polygons in objects (IME)

-files running on top shelf computers (128GB RAM, best graphics cards, etc.) should never exceed 8,000,000 polygons. We have files pushing 12,000,000 with all visible, but they are SLOW

-the embedded library should never be over 350MB. A project server library should be created if the library can't be pared down.

-no single image in the embedded library should be over 3MB

-no single object in the embedded library should be over 10MB

-if your duplicates/missing warnings hits triple digits, the project halts until its fixed (avoid any missing duplicates, obviously)

...

so ... what are your guidelines/standards/limits/breaking points?

Operating system used: Mac Apple Silicon

 

[Claudiu Serban]

Sorry that I don’t have an OT answer, but I just wanted to add that I recently, after ~25 years of archicad use, discovered that using the embedded library is not good. I am in the process of migrating all of my custom textures and objects into lcfs. You get these benefits:

- PLN file size reduction and the added benefits of faster file saves and opens, not to mention they get duplicated if used in hotlinks (that’s another mess best avoided)

- easily find any object (I sometimes “fish” for that one project where I needed that something and I created it there)

- easily update an object in all projects if you ever need to (I update old objects more often now, with the help of claude).

I never cared about polycount. I load the project with as much detail as I need. If it goes stuttery, I just hide those layers while working.

[Funfun Yan]

Thank you for the reminder, and for your very helpful and pertinent advice.

[Patrick M]

I have heard recently that the E/L may be the culprit for a lot of file performance issues as well. But it really is integral to a smooth workflow; and if it is the cuase for major file performance issues, it should be a top priority for Graphisoft to fix it!

I could see how managing a linked library or even .lcf container may be a viable solution if you work in .pln files; but for every project that may have dozens or hundreds of custom images and objects, updating a bimcloud library with every change or addition is just not feasible. I only move a project's embedded library to the cloud if it can not be brought below 3-500mb after removing unnecessary, unused, or oversized contents.

[Patrick M]

polygon count and polygon distribution is absolutely critical to file performance. a mesh at 150,000 polygons is going to bog a file down more than an embedded library at 1GB. An object at 50,000 polygons will have a similar effect.
hiding elements can improve immediate navigation, but will still slow the file down, and even trigger crashes should the high poly component(s) be inadvertently switched on in an elevation or section view.

curren hardware capabilities compensate for a lot of polygon abuses, but there is still a breaking point.