Renerabbitt

I hope you caught my ton of being a goof ball. And thank you, dad was buying all kinds of gadgets for as long as I can remember. I don't think I've ever purchased something>NG that I didn't take apart... And am always amazed by the ingenuity of it all

He says from the comfort of his faster Mac

Ah understood, thank you I'll give it a test when I'm back in the office mon

Yes and a ram disk does very little in my tests when compared to the raid0 sn8100s. Plus you need 4 times the space of your managed resources which for me was originally 15gb. So a 60gb ramdisk. That's just to eliminate it as a bottleneck. 1x is the managed resources, 2x is the temp directories, 3x is any outside resource pool and 4x is the write directory. I had to write a symlink to capture the temp.directory since it's a unique directory name that chief creates every time you have some file I/o pulling from managed resources I have 128gb ram on my main machine so so did get to test it. Then you're just limited by caching, bus speeds etc. It's still slow because of how many thousands of I/O it's going through, which is why I think the method needs revision. Macs system architecture is just setup better for sets of large incremental read writes so Macs over there having a blast while I'm stuck in the mud

WHAT WE ALREADY KNOW ABOUT X18 LIBRARY SLOWNESS A few things about the X18 Library slowdown are already known from watching Chief’s actual disk activity during Library import and deletion. A .calibz library is essentially an archive containing all of the Library assets — textures, images, etc. — along with an internal .calib SQLite database that Chief uses to identify and cross-reference the Library contents. THE IMPORT PROCESS During import, Chief does not stream those assets directly into Managed Resources. It first unpacks the entire .calibz into a temporary directory, writing all of those image and texture files to disk in their normal form. Chief then references the .calib database and processes those same files again into the encrypted Managed Resources structure used by the X17/X18 project-management system. So for a large Library, we are effectively writing the asset data twice: .calibz → TEMP → Managed Resources That becomes especially painful with a Library containing thousands of items and many thousands of textures. THE DELETION PROCESS IS JUST AS BAD Deletion creates essentially the opposite problem. Because Chief still has no proper Replace Existing or Overwrite Duplicates function when importing a Library, updating a custom Library while preserving links to things like Custom Toolbars often requires deleting the existing Library first. When that Library is deleted, Chief again creates a temporary working directory and processes those assets into the Trash library within Managed Resources. Then, in order to import the replacement Library without the old items continuing to exist as duplicates, the Trash has to be emptied — meaning Chief has to process all of that data yet again just to finally get rid of it. So an update cycle can involve an enormous amount of unnecessary disk I/O: Existing Managed Resources → TEMP → Trash followed by another processing operation to permanently delete Trash, followed by: New .calibz → TEMP → Managed Resources For a large Library, that is an extraordinary amount of file activity simply to replace one version of a Library with another. THE MIGRATED .INI FILE CAN MAKE IT EVEN WORSE There is another major source of slowdown that may explain why some users experience this much more severely than others: the migrated Chief Architect .ini file. If you have not completely removed the remnants of previous Chief installations, X18 can inherit the .ini configuration from earlier versions. That file can contain historical Missing Resource search locations accumulated over years of using Chief. Any time Chief reported a Missing Resource and you pointed it toward a top-level folder to search for that file, that search location could become part of your saved configuration. Those paths can then continue migrating forward from version to version. The result is that an X18 installation may still be searching through enormous directory trees that were added years ago — potentially drives, project folders, texture collections, old resource folders, backups, or other locations containing huge numbers of files — whenever Chief is trying to resolve resources. In my case, deleting the carried-forward .ini file and allowing Chief to rebuild a clean one produced a drastic improvement in Library performance. That also means two users with nearly identical computers and identical Libraries can potentially have very different performance depending on years of accumulated resource-search paths buried in their configuration. SO THERE ARE REALLY TWO DIFFERENT PERFORMANCE PROBLEMS The amount of unnecessary file I/O involved in the current Managed Resources, Library Import, Trash, and deletion workflow. Legacy Missing Resource search paths migrating forward through the .ini file and causing Chief to search locations that may no longer have any reason to be involved. THE FIRST OBVIOUS FIX: LET US OVERWRITE LIBRARY ITEMS The obvious first fix on the Library side is something I have been asking for forever: Give us the ability to Overwrite or Replace Existing Library Items during import. That alone would eliminate much of this: Delete → Trash → Empty Trash → Reimport workflow. It would also eliminate an enormous amount of frustration when maintaining custom Libraries that are already linked to things such as Custom Toolbars. THE IMPORT ARCHITECTURE COULD ALSO BE MUCH MORE EFFICIENT There also seems to be a significant opportunity to improve the import architecture itself. From a developer standpoint, why does every texture need to be fully extracted into TEMP before being written into Managed Resources? A more efficient pipeline could theoretically read the .calib SQLite database, determine the required destination records, and then stream each compressed asset directly out of the .calibz archive into the Managed Resources processing/encryption pipeline: .calibz → Stream/Decompress → Hash/Validate/Encrypt → Managed Resources The .calib SQLite database itself could be extracted independently, potentially even into memory, without first dumping every image and texture into a temporary folder. That would eliminate one complete write/read cycle for every asset in the Library. TRASH SHOULD NOT REQUIRE REPROCESSING THE ENTIRE LIBRARY The same general principle could apply to deletion. Moving an item to Trash should ideally be primarily a metadata/state operation whenever possible rather than physically reprocessing every associated texture through a temporary directory. Then permanent deletion could simply remove assets that are no longer referenced by any active Library item. Right now we are effectively doing substantial file processing to delete something, putting it into Trash, and then doing more processing when we finally delete it from Trash. That is an incredibly cumbersome way to permanently remove a Library. CHIEF SHOULD ALSO GIVE USERS CONTROL OVER OLD RESOURCE SEARCH PATHS On the configuration side, Chief should reconsider carrying forward years of accumulated Missing Resource search locations indefinitely. At minimum, users should have a clear way to review, remove, or reset those paths without having to discover that deleting an old .ini file dramatically improves performance. THE BOTTOM LINE I’m describing the implementation from the outside rather than knowing Chief’s source code, but the disk activity itself is observable. When a Library update involves tens of millions of filesystem operations, and an old .ini configuration can additionally cause Chief to crawl enormous directory trees looking for Missing Resources, the answer cannot simply be: “Libraries are large.” There are multiple parts of the current Library and Managed Resources workflow that could be made substantially more efficient. here is a chapter in my user manual to completely remove chief from your computer to reinstall new. Something that it doesnt mention, make sure to export your current library https://renerabbitt.github.io/ppx18-manual/?chapter=completely-remove-chief-architect-x18-for-a-fresh-install

Library and Asset Manager are EXTREMELY slow at deletion and import across all PC. Mac, not nearly as bad. I have installed my libraries on at least 100 machines, and every single PC is unbearably slow even with the fastest hard drives on the market in RAID0 Ridiculous to wait sometimes up to 2 hours to delete/empty trash and the install a fresh library copy. Yes you read that right, 2 hours. For my machine with striped sn8100's with 16000 sequential read, it still takes 30-40 minutes. Its stupid. Just tried to delete assets from asset manager, 600 items took 10 minutes.stupid. I am beyond frustrated with this in X18 Otherwise LOVE X18

I would report it, and in the meantime just make your half wall versus railing wall macro layer dependent in other words make your out of the box half wall go onto a unique half wall layer and so if the layer includes half then it's 1/2 wall if it includes railing it's a railing otherwise let it report automatic description

try it for yourself. change to a box newel and draw out your railing wall

Good idea to state when the slow down occurs. For me, selecting the railing makes the slow down happen..which is b/c of the 4095 box newel, not your macro. Also have you considered displaying your railings like this?

I haven't been able to wrap my head around this logic, Chief is fully capable of dimensioning on a per-floor basis...0 is a fictitious number, 109.125 is no more true than 0..there is nothing keeping someone from throwing a rock on the ground on site and saying thats 0 , same goes for chief...objects can reference a finished floor, including windows and doors and framing members. I don't think you currently tell a framer the head height for the basement level is -29.125, haha. But also...there is nothing stopping you from setting whatever floor you want to 0" Also not a combative tone...im not autistic..but im some thing...some kind of dummy more likely..which is to say that some things confuse me, and i get frustrated when I am confused..this is not subjective..I am confused and frustrated with myself I wasn't going to come back to this thread until I just got commissioned to bring forward a plan into my templates that had a walkout on level 0. The amount of work it took this person to "make it work" trying to depict foundation walls crawlspaces and footing alongside living space was nuts to me....and it still looked very sub-par. I would be curious to see anyone's plan printout of their foundation plan and their walkout plan. Not directed at you rob, but I think maybe I have a hardheaded expectation about what I want my plan to look like, and it just wouldn't be up to my standard trying to get it all on one level. The image Jason posted earlier in this thread..that is not a foundation plan to me, nowhere near one. I'm really curious why this has been such a point of contention in my work as a trainer in this software. It makes so much sense on paper to me. Why wouldn't someone want this simplest approach? Isolating by level, isolating two systems that should be isolated from one another, not requiring any new defaults or layer sets or workarounds. Just the fact that you have fenestration interrupting a stem wall that for all intents and purposes does NOT belong on a foundation plan is not to my level of acceptable plan documentation. I don't think there is another program out there that would allow you to show a door opening in your stem walls where there is not a door opening. What about foundation vents? Couldnt be simpler, place them on level 0 using louvered windows. Isolated area analysis, no problem..I could keep piling on the reasons if I thought about it more. Stepped foundations, mixed floor structures, keyed stem walls, sunken floors, auto rebuild foundations throughout the design process, showing a brick or stone stepped pony wall. I'd bet my years salary I it's less steps in almost every scenario...starting from chiefs OOTB template I would also bet its less steps starting from my template vs anyone else's. Fairly certain we are arguing over long standing preference, not fundamentals. One method simply has more capabilities, and that's in inarguable fact. It has its draw backs, which would largely all go away if we had a dedicated foundation "floor" Also my note to Rob is meant for you as well.. I'm just being passionate, and using a competitive tone..mixed with this inexplicably weird discomfort with this convo, haha. I'm not trying to be in a pissing match though my language might say otherwise You quoted me mentioning a buckout so I'm not sure if you meant to quote a different part? this is a buckout or blockout This is caused from drawing a door on level 0. this is a common condition where the plan-north facing wall is daylight, meaning there is no pony wall assembly. This buckout will be in your foundation plan. This would confuse the uninitiated framer and form workers. The only way to avoid that is lift the door above the height of the ponywall, or the ponywall below the height of the door..my forms crew would call me up and ask me if thats supposed to be a crawl access or something. my plan checker would kick that back We have to draw the same walls in both approaches...level 0 requires an extra step of designating a wall as a foundation wall, thus turning off auto build foundations. It also requires that you make a new layer set to isolate your footings as well as your pony wall. In some cases it requires you draw a pony wall whereas I would not need to draw that pony wall. This would be in the case that you need to represent the stem wall construction separate from the upper wall assembly. Another major draw back on daylight basement sections above grade...don't you have to manually draw in floor joists? Floor joists on level 0 would only show if you have it set to have a floor but even still, chief always shows floor joists for the current floor on the floor below. I dont think it will even generate floor joists, am I mistaken? Setting a room in the OOTB template to Has Floor with a wood frame I-joist and auto framing produces no perceivable floor joists on level 0 Yes, for drawing a walkout on level 0 you would have to adjust the floor heights of the room that supplies the garage footings/stepping, keep in mind that there is a lot less liability keeping auto foundations on and working for you as opposed to manual foundations. You would also need to copy the walls, if you had turned off auto build foundation before drawing your top level. Correct, but you are still having to manage the room height since you dont want your stem walls 8' under ground We are arguing steps for a single use case but fundamentally one approach has more options. How does one handle using the post footing tool if I do not want a room divider in my walkout level? Especially if its within allowed deflection and offset Two levels of pony walls, isolated floors means you can use one set of defaults across the board, text/callouts/notes/dimensions/layer set etc. How are people showing crawlspace vents? Crawlspace access? This is automatic foundations, automatic dimensions, same layer set/text defaults as the walkout. I got to use a hotkey to change floors, didnt need to change the plan view, windows dont kill auto foundations. This is the floor above, same auto everything Even the depiction of a raised slab butted to a mono slab is difficult. and then again there are just some things you simply couldnt get chief to do without splitting the level CMU wall U block ledger? etc. etc.

reach out renerabbitt@gmail.com Rendering artist for 30 years. Seasoned designer and chief architect technician. 10 years in e-design with infrastructure for seamless file and screen sharing. Fast enough in this software to work with you live

You do have 5 listings on the front page of offering services...this certainly can upset some people not wanting to spam the offering services board just to be seen. Also, consider contributing content and information to the boards and you will gain positive upvotes to the extent that it wouldnt matter if you have a downvote

very, I couldn't find this setting. It would be nice if this was in the wall type

Most of my career has been in remodel, I have built a few new homes,but I have never physically built a walkout basement new home. I have remodeled a ton of them(including my own) Is there a reason for the 0' main level?

the blog I wrote illustrates a few of the advantages. For instance, I can show a wood framed wall with a furring wall, or I can show the pony wall(stem wall) with a furring wall, independently of showing a stem wall with no furring wall and showing the footing. This is all from drawing one wall type and leaving auto foundations on. One saved plan view, one layer set. I drew 4 walls and got this. Regardless, drawing on level 1 allows for a lot more flexibility. Notice my stem wall doesnt show a buckout like it would if it were drawn on level 0 What issues? Genuinely curious

260820 (3).mp4 You would have to manually edit foundation walls in this configurations even if it you srew it on level 0. Just copy your garage and porch walls, go down a level, paste/hold position, change to foundation walls, and adjust the foundation rooms relative heights. It takes less than a couple of minutes

Going to leave this here. ill leave it public for 3 days then it goes back to the membership area. l I draw a walkout basement on level 1

just leaving this here, https://www.rabbittdesign.net/rabbitt-blog/chief-architect-walkout-basement-foundation-floor-0-floor-1

My friend this system is yours, just shoot me an email. Let's go grab a beer?

Official X18 added the capability of adding individual door types, such as sliding doors, barn doors etc.. This change rendered the check box "Only Apply Properties to Doors of Same Type" non-functional. This is a retroactive change, so now all of my style palette tools that effect doors of different types other than the type the palette was created with no longer function. Will report this. Thank you, this creates a lot of work for me, making it so that I have to add every single door type to every single style palette and painstakingly go through all of the settings one by one. This amounts to hours of work to repair

260818.mp4

it shows n/a for me, the OOTB one

this is a problem with the macro that you are using. if its your macro, post it here and we can fix it

I think your suggestion should just be allow rich text in room labels which we've been hammering for years. Because you could just write conditions for room type and accomplish the same thing and would be less work than going through every room type to produce a unique label. Also I will mention it again, I am perfectly happy to login to your machine and show you exactly how I have this done using a custom font and how simple it is once you have it setup. Its a helper manual that remaps anything you want to another part of a font family. And I can do this for any font you want in a matter of minutes. So while we are holding your breath for RT in room labels you can have the perfect system without all of this manual work that you are doing with your labels. If you are at the raining in idaho I'd be happy to set this up for you