-
Posts
706 -
Joined
-
Last visited
Reputation
189 ExcellentAbout VHampton
- Birthday 08/01/1892
Contact Methods
- Website URL
Profile Information
-
Gender
Male
-
Location
East End of Long Island, New York
-
Interests
Historic preservation. Competitive swimming & stand up paddle.
Recent Profile Visitors
7769 profile views
-
Deck/Roof over a Living Space, Best Method?
VHampton replied to tundra_dweller's topic in General Q & A
100 percent Doug. On the 2nd floor, "rooms" are always the way to go vs. "decks" even if that may seem counterintuitive. Balcony can still be the preferred method because that particular designation prevents Living Space from getting thrown off. ...unless the user know enough to check the "exclude from living area" option. -
Deck/Roof over a Living Space, Best Method?
VHampton replied to tundra_dweller's topic in General Q & A
First... don't designate it as a deck. That's going to result in some hiccups. Balcony is the way to go... w/ no roof above. Change the floor surface to whitewashed wood deck (or whatever material you might be using). Drop the floor elevation so that the EPDM, wood sleepers and wood deck stay comfortably below the door sill. -
Help getting headroom space above stairs without making a mess.
VHampton replied to GeneDavis's topic in General Q & A
Gene... I'm going to suggest a better way via a poly-line. Convert it to a hole in the ceiling. While I don't use truss framing, maybe this feature has a way of altering the truss? -
Help getting headroom space above stairs without making a mess.
VHampton replied to GeneDavis's topic in General Q & A
Gene, I think there are two ways to approach this. If the goal is an accurate framing model, I'd modify the truss profile and let the framing reflect the finished condition. If the goal is simply to show the condition with model accuracy... Use an Open Below room over the stair and then model the sloped ceiling with ceiling planes. This approach may be much cleaner than trying to modify the second-floor ceiling directly. -
Print Preview is still a handy feature for those who send plan files directly to a printer. For PDF output, though, it's also useful to see exactly what's in the print queue before committing to the export. As for PDF speed, that often depends on how much linework is being generated and whether "live" camera views have been sent to Layout. For example, a hatched fill at a 45° angle with a tight pattern can dramatically increase the PDF file size. The same is true for live camera views. In many cases, it's more efficient to send image files to Layout instead. Just my two cents. That's been my experience for a long time.
-
Dimension lines too thick on export to PDF?!
VHampton replied to TBlackwell11's topic in General Q & A
...looks like the line weight default for detail work is too heavy. As per DB... change the default. Select the dimension string, right click, and see what it's set for. Example... Kitchen and Bath Defaults are far different than dimension strings for plan views. When you right click on the string, the dialogue box will let you know what layer set is being used. -
The rendering conversation is becoming larger than the software and hardware alone. Yes, losing CPU ray tracing was a bummer… but times are rapidly changing. Many clients now expect visualization very early in the design process, sometimes before full architectural development is even complete. AI enhancement tools are beginning to fill that gap between technical modeling and presentation atmosphere. For residential architects, especially in high-detail custom work, I suspect hybrid workflows will increasingly become part of the process moving forward, and it’s curious whether Chief will eventually offer a rendering engine of its own capable of doing some of what ChatGPT is learning to do quite quickly. Attached is a simple pool house generated from a Chief model and rendered in less than a minute using prompts tailored to preserve the architecture while making up for the loss of ray tracing.
-
Thanks Michael... agreed that this has been one of the best threads in a long time. On a side, your prompts for maintaining accuracy with the AI work are stellar. Thanks for sharing them.
-
I’ve been testing this workflow on a few current projects. The speed is impressive. For example most of these took under a minute to generate. The biggest issue I ran into early on was losing control of the architecture… windows shifting, proportions drifting, etc. What made the difference was tightening up the prompt with clear constraints: – Preserve exact architecture – Do not modify structure, openings, or proportions – Enhance lighting, materials, and environment only Once those guardrails were in place, the results became much more reliable. Sharing a few before/afters here.
-
Thanks for clarifying this, Eric. I’ve edited my reply accordingly. It was a reasonable assumption that the searches might have been clocked as Google searches, which could explain where the ads were coming from.
-
The more likely explanation isn’t that Chief Architect is “selling” information, but that the web searches in the library browser may trigger an interaction with a search engine — possibly Google — which could be a plausible reason why the ads are showing up.
-
True — the snail’s pace of a remote server is not for the faint of heart.Patience is a virtue. ...except at work, where time = money and lag = rage.
-
Buy a PC and use the iMac(s) to connect to it remotely. This war’s been raging for decades, but there can be peace — a happy medium between staying loyal to what you love and embracing the cold, efficient world of Windows. For around $1,000, you can pick up a pretty decent Windows based machine and stash it in the basement like a server troll. Mac on top, PC underworld. Everyone wins.
-
You're running an RTX 4070 Laptop GPU — more than powerful enough — but Chief may still prioritize CPU or RAM in PDF generation. Make sure: Dedicated GPU is selected for Chief (not integrated). Try running in Performance Mode under NVIDIA Control Panel. Fixes & Workarounds That Helped Others with new versions where the camera dpi is set to 600 by default: Drop DPI temporarily (e.g., try 300 or 400) to test speed impact — sometimes 600 DPI just chokes the export buffer. Switch camera views to vector (as you did) or even tech line drawing style to reduce GPU processing demands. Observations & Potential Causes: Standard rendering views (especially with shadows, ambient occlusion, or PBR lighting settings) can be memory-intensive during PDF output — even more so at 600 DPI. X17 may be struggling with raster-to-vector translation or texture memory buffering during PDF compilation. Since it worked fine in the beta, it's possible something changed in the PDF rendering pipeline in the final build (maybe a bug, or different optimization).
