Doug_Park

In plan and layout. Line weight scale must be the same. There are no cases that I'm aware of where it makes sense for these to be different. In plan, set the scale to what you plan to send to layout at. 1/4 in = 1 ft in your case. This is also the scale that is used to populate the Send to Layout dialog. In layout, the print scale should always be 1:1. Send to layout at 1/4 in = 1 ft and things will look the same as in plan. Send to layout at 1/8 in = 1 ft choosing use Layout Line Scaling, which is the default and what you almost certainly always want, and you should see some differences in line weights. See attached images. What this will do is keep the line weight the same on paper for both the 1/8 in and 1/4 in views. These are the out of box defaults for the template plans we ship with Chief.

The images you posted do not appear to be at the same on screen zoom level to me. Zoom in until all you can see is one door or window on both screens. The attached is one I did.

Let's not derail this thread into a discussion about the good and bad of these requests.

In your post your comparison images are not at the same zoom level which makes it hard to make a valid comparison. Assuming your setup is as you showed, you have line weights on in both images, and you are using the same layer set in layout, they should look the same if you are at the same zoom level in layout and in plan. Do a side by side view of both plan and layout and get them to be same size and they should look the same. It is also better to zoom in far enough so that adjacent lines are clearly separated. As you zoom in/out some adjacent lines will tend to overlap on screen, especially with the older lower resolution displays. I think that is what you are seeing. Unfortunately, it isn't possible to draw a line thinner than 1 pixel on screen. The best test is to print each view to the same paper size, DPI and scaling in each view.

5+ years on a system these days is a fairly reasonable expectation, but at the end of the cycle you will likely be wanting something faster. It all kind of depends on the complexity of the models you do and how patient you are. If I were on a 5 year cycle I'd probably go for a $500 per year budget and buy a $2500 machine. Of course if you do the $500 per year and get 6 or 7 out of it then you are looking at having in excess of $3000 for your next system.

Lot's of good input here. Keep them coming.

Dimensions in other CAD programs are normally quite dumb while in Chief they attach to and adjust with changes in the model. This has an associated computational cost. However, what you are describing doesn't sound normal. Unless you have an exceptional number of dimensions or you are running on exceptionally slow hardware, or your model is extremely big, or... I would suggest getting in touch with our support team to see if they can identify the root cause of the problem and help you get your system to be as responsive as possible. Posting a plan here that demonstrates the problem can help as well.

Interoperability is a great goal. In practice clean data exchange is difficult. A good example is moving a pure ascii text file between Windows and any other operating system. On Windows a line ending is created by inserting both Carriage Return and Line Feed characters while everyone else uses just a line feed. This results in confusion when exchanging text data between platforms. And while this is easy to convert, it isn't always done by every application. For example notepad on Windows is brain dead when it comes to dealing with text files from other platforms. I use this as an example because no matter how complete an export or import format is, there is always something that the format doesn't handle either on the exporting application side or the importing application side. So some data loss is expected today and for the foreseeable future. Which means the goal of clean data exchange will not be achieved except for extremely basic things, such as lines and 3D triangles with simple texture mapping. The IFC standard suffers in that it cannot accurately represent the very rich Chief parametric models of things like windows, doors, and walls. While we could dumb down what we export, the importing of the data after modification in another application would have lost many of the things that we support. It goes the other way too. Some things in the IFC standard are not supported internally by Chief, which while we could support, may not make sense to do. Eventually, if you take the BIM/Interoperability idea to it's ultimate conclusion you end up with vanilla software that can only do only extremely basic things requiring a lot of fix up work at the end to get things the way you want. Parametric models would be poor, maybe good enough to count windows, or doors, but not good enough to provide highly detailed 3D views that look good. The only current solution is simple 3D meshes of triangles with texture mapping which then becomes very difficult to edit. We handle this currently by allowing you to import 3D models from other software. I think talking about these things is important. And where we can step up to good interoperability, such as exporting and importing to/from .PNG, .BMP, .DAE, .DWG etc. we should pursue those areas. I don't want to suggest that we aren't going to pursue the long term goals of interoperability, but what is often easier to do is to supply features in Chief that solve specific problems. Even then some things are hard and so don't get done as quickly as I and everyone else would like. The main thing is to continue talking about what you need. We will continue to try to hit the most important things first. Which of course varies depending on who you talk to.

Good suggestions. Making undo/redo fast seems most important to me though.

Ray tracing uses your CPU to full effect. Which is unusual for a typical computer. Overheating is a real concern. Jason's recommendations are good. Also, if you open up your system and blow the dust out of the cooling fins on your cpu and other areas that can help improve the cooling efficiency.

The number of undo's saved should have little to do with the speed of Chief. It will add to the number of temporary files on your system, which in the extreme could have an effect on your overall computer speed under certain obscure circumstances. However, if they are getting cleaned up properly this shouldn't be a problem. Cleaning out your temporary files folder from time to time is a good maintenece thing to do to keep your computer responsive.

What are the differences in the machines? If the one one on the right is a retina display then the video card may be driving more pixels than the one on the left so it would be expected to see a difference in speed based solely on that. Do you have the screen resolution set to be the same on both systems? Memory usage could be a factor. Other applications running in the background could be a factor.

Which Mac OS are you using?

If you are aware of documentation of a standard please let us know. Thanks.

I did not mean to imply that we are not interested in pursuing established standards. We are interested in doing what our customers need the most first.

I like the idea of following the ANSI standard as an option, which I was personally unaware of until now. My question is does that standard work for everyone?

I think Rod has made some good points with regard to BIM in trying to focus on what he wants to do. Focusing on what you need is important. BIM has such a broad and varied definition that you can pretty much say that everything that we do is BIM. But that doesn't pay the bills. What pays the bills is getting the tasks done that you need to do.

It can be done. You need to figure out a way of doing the trees. Using 3D trees is the easiest way. Another would be to obtain some top down tree images and map them to a 3D entitiy as a texture that you can then position where you want. Unfortuntately our billboard images don't have top down views. It would be something nice to add though.

Time to ray trace is generally proportional to number of pixels times number of lights. So for quick experimentation do a small image. When you start getting things close bump up the image size. So let's say it takes 10 minutes to do a 1024 x 768 image. If you cut the size to 512 x 384 then you will cut the time to about 2.5 minutes. And if you drop it to 256 x 192 then it should take less than 40 seconds. Obviously you need enough pixels to see what is going on, but you can experiment with settings using a smaller image and get to results that you like a lot quicker.

I think it is a good idea. I would also like to see the ability to organize any tools with a custom parent.

Group selecting is also a option.

I was using Firefox on my Windows laptop and for awhile it was flakey whether it did spell check or not and now it seems completely broken. I'm currently using Safari on Mac and the spell check works great. Not sure why this is still a problem with Firefox.

The i5 is pretty low end. The rebuilding 3D model bit is being done entirely on the i5 the graphics processor doesn't get involved until you bring up an elevation or 3D view. The Intel 3000 graphics are on board and pretty slow compared to the latest Intel graphics. Which are still slow compared to what you can get in a desktop video card. I have a MacBook Air with i5 and Intel 4000 graphics. It isn't fast enough for me to want to use it as a primary machine for doing Chief plans on, but is great for being ultra portable. The building of the 3D model indicates that you have a 3D view open somewhere. If you are editing in the floor plan you can probably speed things up a lot by closing down your open elevations and 3D views. But if your model is as simple as you state the times you are seeing seem high for your hardware. 1) Check your memory usage. If you are running low on free memory this could slow things down a lot. 2) Check for malware. 3) Clear out the files in your temporary items folder. 4) Defragment your hard disk. 5) Check to see if another process is chewing up CPU time. Often a reboot can help. If it does then something is probably being a resource hog on your system that needs to be tracked down.

Fewer is generally better. Keep them to as small a number as you can and it will be a lot less work to manage.

SKP import is not available on Mac owing to a lack of support by the vendor of the library we use for 64 bit applications. We have contacted them about this, but they are unresponsive so we don't know if it will ever be an option. Export to COLLADA (.DAE) and use that on the Mac. It is unfortunate that this option is not available, but it is out of our control.