Doug_Park

The 32 bit version can run out of memory and crash. Assuming that isn't the case, which it doesn't appear to be, it would be good for you to get with our support team and walk them through the steps to reproduce the crash. It is possible the crash is associated with threaded operations inside of Chief. A test would be to turn off "Optimize for Multi-Core CPUs" in preferences and see if you can reproduce the crash that way. If you can't that narrows down the possible areas. Thanks for the stress test. This something we do in testing, but everyone does things a bit differently so knowing exactly what you did is helpful.

The crash is concerning. That should not happen.

There are likely several issues here. Working with our support team to try to come up with a way for us to reproduce the problems is the quickest way for us to move forward.

As far as I know all the PDF printer drivers print to scale when Chief is properly configured. The only issue that comes up is that often people let the PDF viewer scale the printout to fit the paper when they print. This is usually just an option that you uncheck in the PDF viewer.

My guess on the slowness is the DPI of the printer. Which for this one is very high. Because Chief is trying to print at the native DPI of the printer it can produce a large amount of data for certain operations. If you drop the DPI for printing down that could improve the performance.

The terminology in the dialog is technically inaccurate, but conveys the idea of what is happening reasonably well using terminology that most are familiar with. What we do is more accurately described as controlling the number of threads being used by the ray tracer. A thread is an OS level concept that says everything that is executed in a single thread is independent of other threads. Which allows the OS to assign the work to a single core or to spread it out over multiple cores if desired. We leave the core assignment to the OS since we think the OS is better suited to manage that allocation than we are.

Ideally there should be nothing. Although that is a little hard to guarantee given the amount of data stored in a template. We do work hard to keep these clean.

You make some very lucid points.

Both options have advantages. Rebuilding from scratch is an option that we have suggested for many releases as being in theory the cleanest, although it is more work. Some releases have had very substantial changes where bringing templates forward was potentially difficult. For example when we reworked layers several versions ago. At that time starting with a clean template that we provided would probably have been the best option. For X7 the changes aren't as substantial so either option is probably a good choice. In any case a thorough review of settings is highly recommended.

Simply opening your old template and saving it in the new version is a viable direction to go. But it will lose any of the changes in defaults that we would normally push into a new out of box template. A thorough walk through all the defaults after doing this is a good idea as it will help you to not only understand the new version but may help you to refine your templates. A good understanding of all the new features of the program is helpful in knowing how to update the settings. Since new features create new and hopefully better ways of working changes in your templates are almost always required when upgrading.

Any kind of slowness that you can find for us is important. Currently, while we are aware of a couple of cases of slowness. However, we are not able to reproduce some of the issues that are being reported. Please work directly with our support team to track down what you are seeing. If we can get to the point of reproducing the problems you are seeing we should be able to do something to correct them.

Yes, there is definitely something different about X7. I suspect that one possible difference is that the MS compiler is less tolerant of faulty external code. Which may explain the reason the Dell backup and recovery problem exists. While this seems bad on the surface, if that is truly the case then the fact that older versions of Chief worked better may only be accidental. If the issues are caused by other software in combination with changes to Chief then we can look into how to fix things. The Dell backup and recovery case is interesting because it is an interaction between the dell software and our user interface toolkit library. We are pursuing fixes on two fronts here, but I suspect that the Dell utility is doing something that it shouldn't. It may have worked by accident in X6 or it is possible a change in the toolkit we use caused the problem. For those that are experiencing slowness, especially in saving files, it seems fairly logical that an external program to Chief that is not normally installed by Windows, is the trigger. The actual reason for the slowness may actually be our bug, but without tracking down the cause it is impossible to speculate on how to fix it.

The goal is to make Unicode support as complete as possible. That would include Ruby.

I use Windows 8.1 and can't reproduce the slowness issues. We have found that there are an increasing number of side effect crashes associated with software that hooks the OS as a low level. For example Dell has a backup and recovery software that seems to cause the file dialog to crash under certain circumstances. We also saw a crash with some video drivers for some older Intel cards that didn't crash in older versions of Chief. The latest Microsoft compiler that we are using appears to inject more safety checks into the code it generates which may be resulting in some poorly written low level software causing conflicts that didn't occur in the past. This is just a theory, but there seems to be some growing evidence that some add on software such as malware scanners and other things that hook the system at a low level are precipitating some of these problems. The trick is to figure out what the culprit is. There are so many things added on to typical operating systems these days that it is really hard to track things down. I generally run with a very clean OS with minimal extra drivers added on, which may be why I don't see the problems.

Chief does not yet uniformly support Unicode, which is what we would need to support the many different scripts in use worldwide. Currently you should be able to use Cyrillic scripts in Rich Text. But the rest of the application is limited to the Windows 1252 character set which doesn't support Cyrillic or any other scripts. Unicode support is something that is of growing importance as our customer base is spreading worldwide. Internally several things have been done in the code to work toward this support. Unfortunately, not all of the work has been completed.

Check the hot keys assigned to snap toggles. It is possible you are hitting those hot keys without realizing that they are doing something.

I would choose 8.1. The jump from there to Windows 10 should be a lot less painful than jumping from Windows 7. Obviously if you are coming from XP you have a big learning curve regardless of the OS you choose.

Pretty much the entire line of Mac products are decent choices for Chief. The high end iMacs actually compete well with the Mac Pro in performance so going to a Mac Pro may not be as good of a Return on Investment as one would like. The real question of performance boils down to how detailed of a model you are going to end up creating. For example a dog house would likely not stress any of the Mac hardware. But a high end condo with hundreds of rooms and a high degree of detail may make the fastest computer you can buy seem sluggish. There is a lot you can do to manage the performance issues. I've seen some amazingly complex plans done in Chief that perform well. Chief is 64 bit so all the memory you have on the machine will be available, although typically something in the neighborhood of 8GB is going to be a good minimum. Here is a link to some samples: http://www.chiefarchitect.com/products/samples.html For rental options you should contact our sales department. http://www.chiefarchitect.com/company/contact.html

From your description it sounds like you can only get what you want printing in either gray scale or by using some sort of pattern fill. Black and white is not gray scale. It is solid black and white only.

If it is a particular plan try to see if maybe the camera is just really far away. This can sometimes occur because of odd model artifacts. Do elevations work? Do internal camera shots work? If it is every plan then reboot the computer.

Cross hair lag is potentially a problem with super high resolution displays. Using smaller windows can help. Unfortunately the rich feedback that we provide while you move the mouse pushes the computational capabilities of computers when the size of a window gets large enough. There are also other factors in play as well. Some people are much more sensitive to things like this than others. Also the refresh rate of the display can be an issue. I know that when we did tests internally of 4K displays on Windows some people reported a cross hair lag that others didn't notice. This was because of the 30 hz refresh rate. A lot of this computation is done on the CPU so a faster video card may not help. Unfortunately, the push toward higher DPI displays is happening a bit quicker than the hardware can really support. I think 4K displays are fine with most modern hardware but 5K displays probably need a bit more processor power. This may be where the Mac Pro would actually be a better choice.

Look here for CPU performance comparisons. https://www.cpubenchmark.net/high_end_cpus.html The video cards are a bit tricky to get good benchmark comparisons on. You first need to figure out what the D300, D500 and D700 match in terms of the FirePro cards. This site gives some clues: http://architosh.com/2013/10/the-mac-pro-so-whats-a-d300-d500-and-d700-anyway-we-have-answers/ They seem to fall in the range of W7000 to W9000. Which are sadly not really much better than the high end iMac video cards. http://www.videocardbenchmark.net/high_end_gpus.html This results in a kind of a difficult call in terms of what is faster. A low end MacPro may handily outperform an iMac in ray tracing but may be more of a wash or fall behind some of the iMacs when it comes to OpenGL 3d graphics. I don't really have any definitive answers other than for the price the performance of the MacPro is disappointing to me. There may be additional value for running applications other than Chief that would make the price more justifiable.

The new Mac Pros run fine, but are not as fast as we expected. They are a good solid machine, but the price/performance ratio is not as good as I would like. I don't have any personal knowledge about the 5K iMacs. I don't have a reason to think that they would have any problems. Someone else may have more information than I do.

There are color calibration devices that you can get to ensure that the colors on your monitor are accurate. However, lighting in a Chief model will affect the color so things may still not look the way you might expect.

I used that awhile back to resize a satellite image to overlay a survey. It worked really well for that.