Doug_Park

If you have an old plan that has issues when you open it get it to our support team. While we may not be able to correct everything, at least we can get it into our database as something to look at. Over the years I have fixed a lot of issues loading old plans. In fact today Version 5 plans still open better in the latest version of Chief than they did in version 6 because of the work we did back in version 7. There are some things where we ended up making compromises on loading of old plans but usually we try to make them open as cleanly as possible. Because of the large amount of different possible problems with old plans some issues slip through the cracks so having you point out the cases that are important to you it helps us focus our efforts on the things that matter most. Thanks for you feedback with your help we will continue to make the program better.

The out of box settings in Chief follow what is a fairly typical industry standard of line weights based on mm sizes. Although there are many "standards" out there so it is really hard to nail down what is most common. Since the majority of standards use mm we set things up to make it easy to follow that convention. It is rare to find standards that are setup to be in inches even in the US. I like to think of it in terms of the mechanical pencils that we see commonly. Typically these have leads of .5mm or .7mm. With the Chief 1/100 mm scaling these would translate to a line weight of 50 or 70. 50/100 = .5mm 70/100 = .7mm. Beyond that line weights are a matter of taste. It is pretty easy to set up standards in Chief to match what you like regardless of whether you like to think of them in terms of mm or inches.

That sound's like a plan that you should get to our support team so that we can look into why you get that message. It isn't something that is typical. A corrupt file is a possible cause. You may want to go to your backups if you have them or if not maybe look at the archives that Chief makes.

Even stuff that is just annoying with regard to Chief should be reported. Sometimes there will be cosmetic issues that crop up as well. And while it might be something that you can live with we want to know about it anyway. I don't anticipate major problems, but then I'm an optimist.

If anyone does run across any problems with Chief on Windows 10 let us know. We are still early in the process of testing things on Windows 10 and I fully expect to find some problems with Chief. I can't recall an OS release where there wasn't at least a few issues.

Having a find and replace tool would be a very nice addition to the program.

Something like //MyServer/SharedFolder. It is what Windows uses as a syntax for referencing network drives. Here is an explanation. http://compnetworking.about.com/od/windowsnetworking/g/unc-name.htm

I hope that helps.

I'm not convinced that the issue is the graphics card. While we do a small check of the graphics on launch that should normally not cause a crash. You should call our support team though as they can walk you through a number of trouble shooting steps to help diagnose just what might be the cause. There are several things that occur on startup that could potentially lead to a crash on launch. A corrupt install is a possibility. Other hardware not working correctly is also a possibility. I don't see anything about that hardware that jumps out as being incompatible. We have worked hard to make sure we work with Intel integrated graphics. Although from time to time we do encounter cases where older hardware/driver combinations don't work. Usually this doesn't result in a crash on launch. Contact our support team and they will work hard to get you up and running. Usually new hardware isn't necessary, but occasionally we do run into hardware/driver combinations that are simply so bad that we cannot make it work. This is the rare case though.

What are your needs for network support?

Preferences>Behaviors. Make sure Rotate about center of object is selected. It sounds like you may have rotate about current point selected.

Sorry to hear about your computer compatibility issues. We do try to make sure that new versions of Chief run well on existing hardware and for the most part we succeed in doing this by improving the performance of the program so that it is faster even on older hardware. However, from time to time there are issues that come up that were unanticipated and that we unfortunately didn't catch in our internal testing. However, we have been working hard to fix the performance issues and have already rolled several into updates. Please work with our support team so that we have the information that we need to be able to address your issues.

A shot in the dark here is that you are running a Vista or newer OS and are not running version 10 in XP compatibility mode. Full support for Modern post Vista operating systems started with X2.

The suggestions forum is the proper place to put all of your wish list ideas. Those will get collected and put into our database of suggestions. All suggestions are evaluated and prioritized based on an internal process that attempts to create a prioritization that works best for everyone.

Whether it is a DXF or DWG should not make a difference. There are potentially a number of CAD blocks imported that could take up a fair amount of space depending on their complexity so I wouldn't be surprised if a large amount of memory was used depending on the DXF. This could have an effect on performance in a number of ways. The difference in the time to save is a bit hard to explain without having the plan or the original DXF to look at. It could be OS level disk caching kicking in making the subsequent save quicker. Or it could be any number of other things. However, the recommendation to quit and relaunch Chief after importing a DXF is not something that I would deduce from your observations. It shouldn't hurt anything to do so. Your observation may point to a real problem, so if you can reproduce the issue getting the necessary files and steps to do so to our support team would be ideal.

There are likely some things we can do to improve the performance on the 5K iMac. That will take some research to track down. I'm not sure if there is much we can do but it is something we should look into. The 30 minute delay on undo is something that should not be happening. If you can get a plan to our support team that duplicates the problem that would be ideal. It it hard to say what the cause is for that slowness is. It is unlikely that it is the graphics card though. The fact that it is slower in X7 is not good, we would like to have a plan to look at to diagnose the problem.

I don't have any experience with this hardware. It looks fine on paper for running Chief. And given that the older surface pros did a pretty decent job I would expect this new crop to be better. If anyone does have some experience running Chief on one of these let us know what you think.

Exposing all of the data that makes sense is the ultimate goal. In no case should the data of the class be exposed directly. Internally the program treats all data as private with access methods to extract it. In some cases the data is returned unmodified, but in others a value may be computed, computed and cached, etc. In order to expose data safely we need to run it through functions to ensure that it is correct. To do this requires adding a little code for each value we want to expose as well as thinking through the naming of the value so that it makes sense to the outside world. Internally, our names are not always as good as they would be if they were exposed to the public. However, I am in complete agreement that everything that makes sense to expose should be exposed for both read and write as appropriate.

I don't expect any change. The problem would more than likely require the rewrite of printer drivers to support it. And would certainly require a rewrite of the toolkit we use to do printing. I didn't mention Macs because I didn't know. A quick search seems to confirm that this would behave the same on a Mac if you went through a Mac PDF printer driver.

Printing on windows cannot produce transparency due to the way it printing is currently implemented. This means that when you print to a PDF printer the transparency blending has to be done before it is sent to the printer to a bitmap. This will result in certain artifacts, especially if your PDF printer driver is set to print at a low resolution. If you choose the resolution that you will ultimately print at the blending should not show up when you print, but will likely still show up in a PDF viewer because of the discrepancy between the resolution of the bitmap embedded in the PDF and the resolution of your display. The color accuracy of your monitor may also have an effect since the blending can produce a slight color shift which may not be rendered accurately. Save to PDF doesn't suffer from this limitation because it doesn't go through a Windows printer driver. Fixing this for printer drivers can't happen because of the limitations of Windows.

I know that we would all like ray trace times to be faster. However, we should put this in perspective. Ray tracing is one of a class of algorithms, like weather forecasting, computational dynamics, and a number of other engineering algorithms, that require massive computational horsepower. Traditionally these types of operations were limited to those that had access to super computers. I once did an estimate of how long a ray trace would run based on Moore's Law and ran it back to the early 90's. If I recall correctly assuming that a pre 1990 computer had the memory and other necessary hardware to do a ray trace and assuming you could keep it running. A ray trace that we do today that takes a couple of minutes, would still be running. It is important to appreciate that this class of computational problem is at the limit of what can be done on today's hardware. And while there are things that we can do, such as leveraging the GPU to do some computations, the algorithms involved are very expensive computationally. Bottom line it is expensive but it will get faster over time. Ray tracing, conceptually, computes a ray from each light source to each pixel in the model. It then, depending on the properties of the material, extends that ray based on reflection and refraction on to the next pixel until some limit is reached where the light contribution becomes insignificant or it hits some limit in number of bounces. In reality the rays run the other direction from the camera to the pixels and then on toward the light sources, but I like to think of it as going the other direction. This is a highly simplistic explanation, the actual explanation is much more complex. Given that description it should be easy to see that a spot light that doesn't shine in all directions will have fewer pixels in the model that it will effect. Also, highly reflective surfaces allow the light to travel further and will increase the number of pixels that are affected by the light source.

The issue is not the PDFs as they are perfectly well formatted. Size doesn't seem to always be the trigger for this issue. Unfortunately, the best advice I can give you in this situation is to save the PDF to a PNG at a resolution that is acceptable for printing and then import that.

Ray trace performance is highly effected by the size of the image and the number of lights. All other settings being equal number of pixels wide X number of pixels high X number of lights will tend to be the primary multiplier in the cost of a ray trace. Note that model complexity, while a factor, becomes a minor contributor as the number of pixels and number of lights increase. Other settings can also have a huge effect, for example photon mapping is costly. The smaller the image the more some of the other costs tend to effect performance. But a good test is to do a ray trace, then cut the image size by 2 in each direction. This should result in a nearly 4X improvement in speed since the number of pixels is 1/4 of what you started with.

The PDF display toolkit that we use on Windows has some problems with certain PDFs. I know that some research has been done into trying to fix this issue but I'm not sure of the status. However, in many of the cases where things are really slow rendering a PDF on Windows the core problem has often been associated with the PDF having pixel based data formats embedded in the document. In many cases these would be much more efficient to import into Chief as PNG or JPG images. I would recommend contacting our support team with this issue so that your problem is represented in our database.

The scale was always intended to be the "printed" scale. The idea is that if you print something to a scale different than normal, such as a check plot, that the output would have the correct scale. This was an important requirement that was gleaned from several people prior to implementing that feature.