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".

13 hours ago, dskogg said:

I find blender not very intuitive… doesn’t seem to bring in object with texture?

 

so haven’t had much luck here…

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:

3 hours ago, Chopsaw said:

Hi Ben,  Is that something that has changed in one of the more recent versions ?  Also how would the 1/300 in. correspond to an actual line weight # using the default Drawing Sheet Setup of  1/100 mm ?

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.

6 hours ago, AndyRonLI said:

Drawzilla, I should have been clearer. I am aware of the requirements as currently stated and I run CA on a Windows 10 machine. Revit, Autodesk etc all have LInux ports. Perhaps it is time for CA to also to create a Linux port. If you can run under the current MacOS you are already 3/4 of the way there, as MacOS is a proprietary version of Linux. Anyone else out there looking for a Linux version? It would be another little chunk of market share for CA

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.

31 minutes ago, dskogg said:

to process it at the end takes a while..not sure why.

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.

1 hour ago, FredBell said:

Just for CA team benefit, just know this issue happens multiple times a day (around once per hour on average). So when you say you cannot replicate it easily... I am wondering how hard you have really tried...

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.

1 hour ago, FredBell said:

What I can see happen is an exception is raised - by your cpp class, probably due to an error code returned by the driver. 

 I am telling you this because I am software developer myself, and write c++ fat client app all the time, and this crash is your fault 100%, here is why, your code gets the error code return and decide to throw the exception, or you did not catch the exception and handled that exception correctly the way your code is supposed to. 

When this exception is caught - your code, like all other piece of software in the world, is supposed to take a "stack dump" and send it back to you for further analysis. Add a little popup box asking the user for their permission before sending the error report file and you are good to go.

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.

49 minutes ago, FredBell said:

% of the time, after your software crashes, then windows 11 will also crash within a few minutes, you know "blue screen of death" style. It is pretty brutal. I am guessing here, but it looks like the process did not clean the graphic card state properly.

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.

2 hours ago, Jeremy33 said:

It happens to myself a lot as well.

When i try to group select a lot of different items (ie. group of cad lines, polylines, especially if the polylines have a fill created in them) the pc freezes for 4 or 5 seconds then continues to work.

Never happened in the past several Chief versions until x14.

Very frustrating!!!

My pc is not the problem i dont think, its a fast machine with a good vid card.

Can someone hel pexplain this please?

Jeremy

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.

On 7/15/2022 at 3:29 AM, Smn842 said:

I wonder if creating process dumps (used for debugging) during these freezes would help CA find the cause, perhaps @Dermot can confirm?  

 

If they can, then these can be created in various ways, the simplest on Windows is from Task Manager, finding the Chief app and then expanding its entry as it has two processes, and then for each selecting 'Create dump file' for each. This creates a dump of the running application and memory that may be useful for debugging if CA has the matching debug map files from when they built the executables.  The files created are large but compress well.

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.

3 hours ago, Doug_N said:

      c) Each PDF to be in vector format.  Raster format is not acceptable. (CA does not support vector PDF)  I suspect the vector PDF would be much smaller than a raster PDF)

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)

14 hours ago, RodCole said:

Years ago I used a customized program in AutoCAD that allowed for up to 3 characters and required a delimiter to execute the program.  That meant you had to enter however many keystrokes you wanted followed by either hitting the enter key or the spacebar.

 

The spacebar is easy to use since it only requires you to hit it with your thumb, cinch-a-reno, But Chief insists on not requiring that extra keystroke.  I can see that in a way, but IMHO it actually makes using the hot keys harder.  Sometimes I want to use a short sequence and sometimes I want a longer sequence, but only when it makes sense to me to type the extra keys, not every time.

 

I for one wish Chief would reconsider their approach to using the hot keys and allow for a spacebar or enter keystroke to execute the command.

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.

4 hours ago, robdyck said:

How would you recommend closing up the side of a non-recessed tray ceiling that terminates against an invisible wall?

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.

The issue is that the ceiling finish in the family room and the hallway is different from the ceiling finish in the dining room and kitchen, as you can see if you delete the tray ceiling:

Tray ceilings will "flood fill" into adjacent rooms through invisible walls if the ceiling heights are the same. This is useful for non-recessed tray ceilings, but it's admittedly less useful for recessed ones. Changing the ceiling material in those rooms to all be the same color would fix the warning. Alternatively, if you want to keep the color difference, you can use the "Explode Tray Ceiling" command to break the tray ceiling polyline down into its component ceiling planes and then pull back the large "outer" ceiling plane that has overflowed into the adjacent rooms:

30 minutes ago, HumbleChief said:

Here's a bad question. Are there any other "known issues" we should know about? I just spent an hour trying to figure that out.

Ouch. Having spent an hour this morning on the phone with my Internet provider, I feel your pain.

We don't have an official list, unfortunately, although I'd like to see us provide something like that in the future. (I'm not the one who manages that sort of thing, though). We generally try to keep an eye on the forums and note issues that our customers are running into, though (gotta do something while the code is building!), so dropping a thread here or contacting the support team, although perhaps not the most expedient solution in all cases, is probably your best bet for the time being when Chief behaves in a way that seems unexpected.

There's a known issue in X13 (sorry, my fault!) where form fields in editable PDFs won't render correctly. I'm working on a fix. In the meantime, you may be able to work around the issue by opening the PDF in your preferred PDF viewer, printing it to another PDF, and importing that into Chief.

As currently designed, tray ceilings will "flow through" invisible walls, with the main goal being to allow tray ceilings to span multiple rooms. Exploding the tray ceiling is probably the easiest way to override that behavior in this case, at least if you're planning to recess it into the ceiling structure above it.

The tray ceiling has automatically "overflowed" from the dining area into the kitchen and the great room because all three rooms have the same ceiling elevation. If you set all three rooms to use the same ceiling finish, the error will go away. Alternatively, you can explode the tray ceiling and "cut back" the large ceiling plane to fit in just one room.

The resolution after import will depend in part on whether your PDF contains vector data (lines, arcs, etc.) or raster data (i.e. scanned images). As a general rule, if it doesn't look sharp when you zoom in using another PDF viewer, it won't look sharp in Chief.

If you have a PDF that does look sharp in other viewers but is pixelated in Chief, that can sometimes happen in X12 and prior versions for particularly complicated PDFs. The best workaround for now is to convert the PDF to a high-resolution image using external software and then import that image into Chief.

1 hour ago, fcwilt said:

Non-library Doors appear to inherit a surface color of Bone from somewhere but I have not found it yet.

If I recall correctly (haven't worked on doors for a while), this should be coming from your interior/exterior door defaults. Basically, symbol doors use the plan's "generic" default materials, while parametric (non-library) doors pull their materials from a specific default door.

Also note that unless you check "Separate Trim and Materials on Each Side" (General panel), interior doors will only use the interior material, not the exterior material.

X13 should include a fix, at least for the versions of this problem that we've studied so far.

10 hours ago, Lakeside-E said:

I didnt know that marque selecting made a difference but it certainly does... Any insight as to why Ben?

The short version is that Chief is trying very, very hard to find the best place to put the move handle. This polyline, in addition to its complexity, is shaped in a way that makes one of our internal algorithms have to sift through more data than usual, and it bogs down. The marquee select bypasses that part of the code.

10 hours ago, Lakeside-E said:

Any predictions if the problems i am having now will carry through once the polyline is extruded to a polyline solid?

Unfortunately, the issue is likely to persist after extruding the polyline. Converting the solid to a symbol should help, though.

38 minutes ago, Alaskan_Son said:

Maybe I just never reached that number of segments in the container holes.  

If this is caused by what I think it might be, then yes, that's precisely the issue. Reducing the number of spline segments before converting the splines to polylines would have improved the performance somewhat (at the cost of reduced detail).