We value your input!
Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey

Libraries & objects
About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

project libraries

Anonymous
Not applicable
Talkers,

In reading about libraries in version 10, the help file suggests combining the AC 10 library with whatever library you want to use for a project, and making a container file of the combination to use as the project library. Should one extract the AC10 library first, then combine and create the container file? Should that file be 'compressed'? I tried making a container file of my custom library (and compressed it). When I loaded it, none of the items from it that had been used in the project I was working with showed up.

TIA
15 REPLIES 15
Barry Kelly
Moderator
Weston wrote:
Eric wrote:
I keep the standard AC library as-is and modify parameters through favorites mostly. I don't edit the code of the GS parts.

Is that what you were asking?
Well, sort of. I'm not clear on whether you even load the AC library in your typical job...

So do you load the "culled" AC parts as a part of your office library, and then load the full AC library for those times when you need the grand piano part that you never bothered to cull?

I had experimented with that a couple of years ago, and always found that the duplicate library parts/duplicate names would cause confusion.

Wes
Our main library was based on the standard Archicad library (some years ago).
Objects we didn't need were deleted and others modified to do what we wanted.
New objects are added as we create them.

The original Archicad library is never loaded now but if we ever need any objects from it they can be loaded in on a one by one basis or better still copied into our main library for future use.
Macros that are called by objects can make it a little tricky to make sure you have all the parts, but patience and persitence pay of here.

We also create a job specific library if needed but again if we think it is something that will be usefull in other jobs we will add it to the main library.

As new versions of Archicad are released it is a matter of trawling through the new library and pulling out anything useful and either adding to our main library or replacing older style objects.
You need to be careful so that you do not affect existing jobs when replacing objects, so we have main library suitable for each release of Archicad.
The job then keeps it's own version of our main library no matter what version of Archicad it is opened in.
i.e. a job created back in version 8.1 will use the 8.1 library, even if opened in version 9.0 or 10.0

So basically with each new release of Archicad we create our own custom library based on new objects from the new library and our already proven and trusted objects.
We then modify our older objects to make use of new GDL features (such as moveable hotspots).

Barry.
One of the forum moderators.
Versions 6.5 to 27
i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10
Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11
Anonymous
Not applicable
My process is about the same as Barry's.

Whenever a new AC library is released:

1. Expand the AC library
2. Copy the AC parts I want into my library
3. Recreate the container file
4. Sync container file to all users' local drives (into the AC installation folder)

I use a completely different folder structure for our libraries (see attached) where the folders are named according to the layer hierarchy. This gives the users a hint as to where the part should go if there is no favorite defined. It also gives a hint as to where the part will be visible in the drawings and helps predict the outcome. Having things organized by CSI division is not really helpful to the people that are doing the drawings - at least not how we do it. CSI divisions are pretty much meaningless to the model as it appears on paper.

Step 4 is automated using sync software of which there are many. Check this thread for some suggestions. By default, AC looks in the location where the app is installed for libraries. If it doesn't find them there it starts looking in the path where it was last loaded. Placing the container next to the app insures it will get loaded even if paths are different for different users/computers/operating systems. Also, placing it on the local drive means it loads REALLY fast. Our library is 250 MB+ and we can open a file AND load the library in 6 seconds.

I have no duplicate parts and no duplicate names. 😉
library folders.jpg
Anonymous
Not applicable
Eric wrote:
I use a completely different folder structure for our libraries (see attached) where the folders are named according to the layer hierarchy. This gives the users a hint as to where the part should go if there is no favorite defined. It also gives a hint as to where the part will be visible in the drawings and helps predict the outcome. Having things organized by CSI division is not really helpful to the people that are doing the drawings - at least not how we do it. CSI divisions are pretty much meaningless to the model as it appears on paper.
I second the opinion that the default library structure is not user friendly. The find feature was a very welcome addition to the library browser. Graphisoft could easily have several versions of the same library available with alternate organizational structures. I now this would be welcome to many new users who stumble their way through finding the correct library part.

I use to limit my libraries but abandoned the approach due to the fact that it needs to be redone with each library release. In addition I would reset the default values to the pens that were appropriate for my output (pre-favorites). I have since migrated to exported groups of favorites which correspond to either specific drawings sheets (i.e. site plan, floor plan etc.) or modeling needs. It takes screen real-estate to keep a reasonably sized favorites palette open at all times but for me is a very fast and intuitive approach to achieve standardized output. Folder control within the favorites dialog box would alleviate the need to have groups of favorites saved out separately. I will cherish the day when Graphisoft responds to our needs of version migration with some type of favorites and/or library migration tool. Currently I upgrade my favorites by having both libraries loaded and use the command-option/cntrl-alt method of transferring parameters between library parts and redefining the favorites. This is a one by one process for each saved favorites of library parts but seems like it could be easily automated if Graphisoft would embrace the notion.
Frank Beister
Moderator
Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.

OK, yes this does not work with objects older than 8. But it is something "looking ahead".
bim author since 1994 | bim manager since 2018 | author of selfGDL.de | openGDL | skewed archicad user hall of fame | author of bim-all-doors.gsm
Anonymous
Not applicable
F. wrote:
Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.
I will have to play with that more. It does seem like a good approach. Can objects have multiple sub-types so they appear in more than one location?
TomWaltz
Participant
Mike wrote:
F. wrote:
Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.
I will have to play with that more. It does seem like a good approach. Can objects have multiple sub-types so they appear in more than one location?
No, Subtypes are unique. An object can be either a door or a window or a stair, but not combinations of the 3.

Even within tools, subtypes are unique. Object tools can be 2D symbols or some other such thing, but that's it.
Tom Waltz