BenMerritt

If you're using Google Chrome, it has some specific restrictions on cookies that don't play nicely with our authentication flow when the page is embedded in an <iframe>. You might try adding the following attribute: sandbox="allow-same-origin allow-scripts".

What format are you exporting to from Chief? Blender seems to bring the textures in for me when using COLLADA (aside from the texture that's missing from the uploaded plan file), and it embeds them on export to glTF. Since the textures aren't embedded in the COLLADA file, though, just exported to a directory alongside it, an online converter would fail to load them unless they were provided separately. Also note that Blender won't show the textures unless you set the viewport shading mode to Material Preview or Rendered. See the button outlined in red here:

This behavior dates back to X12 Beta 2. By my calculations, 1/300 in. comes out to 0.085 mm, so between 8 and 9. With the rounding involved, slightly larger line weights than that may round down to match a line weight of 1. As an additional restriction, the line will never be thinner than one "dot" at your given DPI setting, e.g. 1/150 in. at 150 DPI.

There's a hard-coded minimum line width of about 1/300 in. for PDFs (when using "Chief Architect Save As PDF") in order to mitigate issues where zero-width lines would come through as extremely faint in many PDF viewers.

Technically speaking, MacOS is a UNIX derivative, but not really Linux; it uses the XNU kernel instead of the Linux kernel, and many of its userspace utilities are either BSD-derived (rather than the GNU utilities that most Linux distributions use) or proprietary. It's more similar to Linux than Windows is, but the parts that are most relevant to Chief Architect (especially the GUI components) are still radically different from MacOS. I'm an avid Linux user myself, but despite recent improvements and slowly growing market share, it's not really the "year of the Linux desktop" yet. I wouldn't call a Linux port impossible, but it'll likely be a significant amount of time before such a project begins to make sense from a practical perspective.

That's likely due to the computational cost of encoding the final video file.

It's possible to override this behavior if you open the library object for specification and change the type on the Options panel.

If you're using a font that doesn't actually have an italic variant installed, trying to make some instances of that font italic can cause issues when printing. You may want to look in the system font settings (Start → Settings → Personalization → Fonts) to see if the font you're trying to use has an italic face.

GPU issues like this often involve very specific hardware/software combinations that are extremely difficult to reliably replicate. We can run tests all day on a Windows 11 machine with a GTX 1050, but the chance that it'll behave the same as your machine with your GTX 1050 is slim to none. It's frustrating for both us and our customers, but it's an unfortunate reality in the world of graphics programming. We're well aware of these techniques and use them where appropriate. These "Device Removed" errors are a specific class of error that is nearly impossible to recover from without restarting the entire rendering subsystem, which is an extremely complicated operation. As far as reporting goes, our rendering team has found that even a full stack trace and all the diagnostic information we're able to glean from the GPU drivers is rarely enough to reliably diagnose this kind of issue. On a system with correctly functioning hardware and drivers, a userspace process should be completely unable to cause a blue-screen condition; the operating system is, by design, responsible for preventing any operations that would lead to one. Any case where an application can trigger such a condition is a driver or hardware problem. There may sometimes be a corresponding bug in the software that triggers the driver bug, but in many cases, the software isn't doing anything technically "wrong"; it just encounters a condition that the drivers were supposed to handle correctly but failed to do so. We've found that trying a variety of driver versions sometimes fixes these issues, but it's still a hit-or-miss process.

For cases where you've got a specific action you're trying to carry out in a specific plan, and the software consistently performs more slowly than you'd expect, it's generally best to submit a case to our tech support team with the plan file and full details on how to trigger the slowdown. Especially in cases like this where it's just hanging for a few seconds after a specific operation in a plan view, there's often analysis we can perform with our debugging tools to isolate the cause.

This sounds like a known issue in X12 on Macs with Retina displays. Using a non-Retina screen (or possibly reducing your screen resolution) may help. Another workaround is to take a screenshot of the PDF in the Preview app and import that into your plan as an image. If what you're experiencing is in fact the issue I'm thinking of, it's also fixed in X13.

We do keep debugging maps on hand for precisely this scenario, and they're often quite helpful for at least narrowing down where to look for the issue.

If you print a view with just CAD in it, you should generally get a vector PDF. There are some things that will add raster elements to the PDF, such as: Embedded raster images Other PDFs embedded in the plan/layout Camera/elevation views (except for plot-line views without color fill) CAD with transparent lines/fills (when not using Chief Architect Print to PDF)

It looks to me like this is already possible. Binding "Straight Exterior Wall" to "W, Space" and "Curved Exterior Wall" to "W, C, Space" works as I'd expect it to on my machine. Of course, this requires manually customizing your hotkeys.

In that case, if you can get away with it, I'd just use soffits. They're a little clunkier to edit, but at least in real life, a non-recessed tray ceiling is basically just a soffit.