Joe_Carrick

Years ago (1980's) at CalComp Systems Division we had a "Picture Processor" which was essentially a 2D GPU. This was one of the first (or maybe the first) hardware solution to the problem. Actually, current GPU's perform the same functionality. The problem with Chief is that the 2D view is a software representation of the 3D Model. The 2D View graphics doesn't actually exist as a database that can be processed by the GPU - instead, it's created on the fly which can only be done by the CPU. It would be interesting to see if Scott's model would be much faster if "Walls, Main Layer Only" was checked.

It's just my opinion but I think instancing only works with 3D (GPU handles instances) but that's only Perspectives and Isometric Views. The Plan Views and Sections/Elevations are really 2D representations of the Model (that's why we can add Text, Dimensions, & other 2D CAD objects to those views) and I think are displayed by the CPU by redrawing them. Maybe those views could somehow be displayed via the GPU using instancing but I don't think so. I think a better solution would be for CA to implement either: 1. A viewport save and restore (with x/y offsets) when panning or zooming. 2. Offset the viewport itself when panning. 3. Change the scale factor of the viewport when zooming. Either of those should be much faster than a redraw of the 2D representation of the model.

IAE, check this thread - I show how to do it in a video https://chieftalk.chiefarchitect.com/index.php?/topic/4257-x7-glass-shower-video-by-joe-carrick/?hl=%2Bglass+%2Bshower

You should post this in the Q & A Forum. This Forum is for users to post their "Tips" and/or "Techniques" that might be useful to others.

Dermot, Can the CD's and Manuals for older versions be sold - (X1 and prior) if they don't include the hardware locks? In that case they could only be used by someone who had a valid license with an existing hardware lock.

This was discussed in another thread where a unit plan was copied multiple times, resulting in several hundred walls, doors, cabinets, appliances, etc. To avoid this problem, create the single unit plans (however many different units required) but then just show the separation walls for each unit and label the unit types where they occur. The unit plans can even be in separate Plan Files if you want. It's not really the size of the project that matters but the number of surfaces (walls generally have lots of surfaces since they are made up of layers) IOW, minimize the number of interior walls, doors, etc. This is the way we would have done it on paper before we had CAD systems. BTW, this problem is most evident in the Plan View performance - not so much in 3D if you have a good graphics card with sufficient memory. Evidently the 2D Display is being handled by the CPU - not by the GPU.

After further examination of your Plan, it appears that you have a 2 story living room. Rather than define this as a tall room, create a room above it on Level 2 and set it as "Open Below". Then you can modify the wall between the Bedroom and the Open Below Room as a "Railing".

It appears that you already have a "Stairwell" but it's not inside the 2nd Floor Walls. Delete the Stairwell walls on Level 2 and rotate the Stair on Level 1 so that it will be contained on Level 2 - Then create the Stairwell.

It might be easier to simply edit the 2nd Floor Walls, Normal to a new Layer that you could turn off in a Layer Set that has all the Framing ON. When that Layer is turned off, it will take care of all the Windows & Doors - including the Casings, Sills, etc. You would need to do something similar for the Roof Planes and Attic Walls. You could probably use a Layer named "Hide_This" for all such items.

One way to deal with Wall Types is to add the one's you want to the user Library arranged in folders and named according to their construction. Then when you want to draw a particular Wall Type you just select that Wall Type in your Library and start drawing. When you use one of those in a Plan, it will get added to the Wall Types drop-down menu. Any wall type that isn't used in the Plan can be deleted in the Wall Type Definition dbx. It would be nice if there was a "Purge unused Wall Types" function, but that doesn't exist at this time.

CAD > Lines > Create Line Style You can combine any set of Dashes, Dots & Text with Gaps

Another option - one that I particularly like: 1. Rename the view in the Project Browser 2. Add a Text Box to the Elevation View a. Place the macro %view.name% in that Text Box & size it as desired. b. The name in the Project Browser will be displayed in the Text Box 3. When you send the View to Layout, suppress the "Layout Box Label"

My Layout Template is pretty extensive. Floor Plans, Elevations, Sections, Schedules, Standard Details and General Notes are already there. I have the Layout open along with the Plan so as the Model is developed, the CD's are being built automatically. My Plan Template has Elevation and Cross Section cameras in place and those have been sent to Layout. All Schedules are predefined in CAD Detail Windows and have been sent to Layout. Almost all annotation is done in the Plan - mostly thru the use of Default Labels using user macros. I do all my Details in a set of "Detail Plans". As each Detail is created, I copy it to a CAD Detail Window which I name. Many of these are common to all my projects so they are already sent to my Layout Template. Additional Details are done in those same "Detail Plans" so that they are available for future projects as well. One area that I haven't been able to automate very much is Interior Elevations. I do use the view.name and a predefined mask to standardize the height so that when sent to Layout they will snap and align easily. I do the same with my Details. Another thing that is time consuming is Detail Callouts - because Chief doesn't provide an automatic way to link them to the detail location in the layout.

Chief has a "Lines to Walls" tool but IMO it's cumbersome and not all that accurate. If I have a DWG I will just draw walls over the top and once I have the basic layout with doors and windows in place I delete the 2D CAD lines.

Terry, I agree that Engineers have a tough time with the advances that have been made with computers. The same is true for draftsmen - it just doesn't take as many draftsmen today as it did years ago. The big difference is "Design" and by that I mean the artistic and functional aspects, not what engineers refer to which is really analytical and computational analysis. There are many Chief users who are good at the "Design" aspects of both residential and commercial projects. I personally spend almost as much time designing a home today as I would have 30-40 years ago. It's a little less because Chief provides excellent 3D visualization, but even so the design time hasn't changed much because it ultimately requires my brain and experience. The analysis and decision making process isn't something that computers are capable of yet. Maybe someday they will be but so far it's pretty well accepted that computers do not yet have the ability to be "creative". IAE, In addition to providing superb 3D visualization, Chief virtually automates the ConDocs to the point that I don't need any draftsmen. What I'm most concerned about is that too many people think Chief in itself is a substitute for design. We see everyday someone with a plan that is horrible and they want us to critique it so they can have a better design. That's one way that Chief actually promotes a lot of junk being built. In addition, there are a lot of builders and remodelers that are doing the same thing. But don't get me wrong - it was happening before CAD. Bad Building Design has existed for ages and the only thing now is that it's just easier for the laymen to do. I guess I could rant on this for hours but I have work to do. I prefer to spend my time doing good Architecture.

Michael, Just to clarify. When you display a PDF on your monitor - the display is limited to the resolution of the monitor. When the same PDF is printed on a printer, the resolution is whatever the printer supports. So, you can never get a screen shot that exceeds the monitor resolution. That's going to be the same no matter how you display a picture (rendering)

Michael, You just took a picture of the Screen at a given zoom factor. That's going to be limited to the number of pixels on the screen, not the printer. OTOH, if you zoom in on the Live View you will have more pixels for the amount of the view shown on the screen. There's no way to take a screen shot that's going to be as clear as the printed output.

When sent as a "Live View" it should print very clear. It will depend on the printer selected (PDF is probably the best) but basically, a "Live View" is printed at the resolution of the printer so that's as good as it could possibly be. IOW, don't be confused by what you see on the screen. If you zoom on a "Live View" you will see that it gets better and better as you zoom in.

My understanding is that it's the Printer's resolution". See Dermot's explanation in post #14

OK, I'm going to jump in here and try to explain. The OP didn't just send a Standard Render to Layout. He exported the Standard Render to a BMP and then imported the BMP to Layout. This is the wrong way to do it. He should have simply sent the Render View to Layout (as a live view or Plot Lines) - in which case it would display on the screen according to the degree of zoom but would print without any pixelation or blurriness. Actually, a Standard Render can't be sent to Layout as Plot Lines. It would need to be a Vector or Line Drawing in order to have that option. Please, both Perry and Michael, let's knock off the ..........

I guess I should clarify my use of RT and Text. 1. A great majority of the text in any of my projects is "Labels"and "Dimensions". a. These are all automatically "Text". b. The Text style for these are all controlled via Layer Sets. 2. For Room Labels I use a Rich Text Box with different fonts, fill and border 3. I also have several Tables (similar to Schedules) but created with Ruby Macros a. Most of these require Titles and Headings in different Fonts and Sizes so I use RTBs. 4. For Layouts a. I use text only on Page 0 - everything else is from the Plan(s) b. All the text on Page 0 is consistent for whatever Layer Set is being used. c. Text or Rich Text works equally well for Page 0

Good point - which works perfectly for most Labels. But for custom data tables it prevents hiliting headings, paragraph titles, etc. That's where RT shines.

The way I remember it was that he cropped the Layout Box, then put a solid filled mask (rectangular box) on top of that and a hole in the mask. The hole can be shaped as much as you want, including fillets so that you get an oval or a circle. I do this in my CAD Detail Windows, my Interior Elevations and sometimes in Sections. I don't do it in Layout very often but for a case like the OP I would do it in the Layout. The mask (both the boundary and the fill) can be the same color as the background so it won't show.

No, the only superscript characters we can use at present are 1,2, & 3. All of the other superscript characters require Ruby support for characters above ASCII-255. CA would need to add UNICODE support to Ruby or provide a custom font with the superscript characters 4,5,6,7,8,9 & 0 in a non-standard location. This is something I requested but I have no way of knowing if they will do either.

Yes, "Test".ljust(20) + "This is a Test to show ........" "Test doesn't work".ljust(20) + "This will be aligned with the above" because the first part of both lines are padded to 20 characters.