Doug_Park

Regular elevations create cross section lines where the section is cut that can be snapped to. Wall elevations don't do this so there are no snaps unless you manually add some cad lines for that purpose. Dimensions don't use snap points to decide what to dimension to, although it seems somewhat logical that if you can dimension to something you should be able to snap to it and if you can snap to something you should be able to dimension to it.

For a situation like that you want to center on a room edge, not the wall. To play with how this works draw a simple plan and play with centering a cabinet on various things. On a wall you can pick up the center line along the length of the wall or if you are sufficiently close to the middle of the wall you can get a center line there as well. But that may not be the center you want. Usually you want the center along the edge of a room, so moving closer to the room you want to center on or slightly inside of it will produce the result you want. This works more or less the same for all objects. Generally there are 2 centering axes on an object, but for others, such as box like objects or polylines you can also center on the edges. It can seem a bit confusing in a busy plan as there are often many different things that can compete for providing a center line. But if you practice and observe the results on simple things you can get a better idea of how it works. Obviously, your case was an odd case based on having a bad room definition that leaked into the area you wanted to use. In most cases the filled area of the object providing the center line will be highlighted.

Your second image appears to be showing what is known as a z fighting issue. It is caused because of the way OpenGL does rendering. Imagine that your scene is composed of very thin slices starting at the front clipping plane of the view and extending to the back. In these large scenes the distance is so great that you hit the limit of precision of the video card to distinguish the layers. If you move the front clipping plane of the camera closer to the scene the problem should go away. This is set in the camera specification for the particular view you are using.

What is the other video card in your system? We have make an effort to make the Intel graphics cards work, but there may still be issues with some of them that we need to track down.

It sounds like a video card problem. Try rebooting your machine. Sometimes the video cards get into a bad state that a reboot will fix. It may also be the result of a video driver update or maybe a video drive update will fix the issue. If you continue to have issues contact our support team.

When we ported to Mac we researched the 8.3 file name limitation, thinking that surely by now that antiquated notion would no longer be a limitation for that software. We were surprised to find the even the latest versions of 3D studio still required the 8.3 format for the 3DS export format. This took us down an annoying detour to implement on the Mac code to generate 8.3 compliant file names.

Yes your picture confirms that the real cursor position and what the program thinks the cursor position is are offset. Apparently, by about the height of the tabbed window title bar. It doesn't really help a lot, but the amount of the offset is likely a clue as to where the problem is. The screen capture won't capture the cursor location when synchronize with cursor is off as the system automatically hides it. When Synchronize is on we draw it where we think it should be.

You were not in Vector View. The other views do pixel based rendering and printing only so the vector options are not there.

Thanks, that is what I suspected. It sounds like the coordinates of the cursor are not getting properly calculated for the view. This sounds similar to a problem we saw in beta when Chief was opened by double clicking on a plan. Now we will need to see if we can reproduce the problem in house so we can fix it. The best way for us to figure this out is to have you talk to our support team. Since it appears that more than 1 person has the problem it is likely something that we need to fix, but it is something that appears to be very unusual so will take some effort to track down. I would first suspect video card drivers, but it may also be something else, such as your arrangement of toolbars or something else. Your help on this is highly appreciated.

What version of Chief? What OS? This sounds like a video card driver issue. What video card are you using?

File>Print if you are using a Vector view. Other views are pixel based so only have the Print Image option. You can also send to layout which will convert the view to a line drawing.

There is a learning curve moving to Mac if you aren't really familiar with how Macs work. Mostly, this is easy. Files will just work. Copy them over however you want and open them on the Mac. Going back to Windows is just as easy. Use a thumb drive, network, or any other software that allows you to move them over to the Mac. Windows Meta Files won't draw on Mac so if you have any of those try to convert them to PDF or PNG. PDFs on Mac bloat somewhat depending on how much text you have in them. While this is a big deal for Scott, it doesn't seem to be a major problem for everyone. We are working toward a long term solution for this, but it is still a ways out. Font compatibility is mainly no different than going from one Windows machine to another. Just make sure the fonts you are using are installed on all the systems you are running Chief on. As with any new release there are always a few glitches to work through, but at this point we are very stable on both Windows and Mac. There are small differences in the minor glitches we are seeing on the two platforms. As we can we are addressing these. Normally if we see a crash on Mac there is a corresponding crash on Windows. In some cases we found crashes on Mac that were very rare crashes in X5 on Windows so that has led to some stability improvements on both platforms. Performance differences between platforms are somewhat variable. In some cases Mac is faster in others it is slower. Overall, they are close.

Your 3DS problem may be because you have long file names turned on. The 3DS format still uses 8.3 file names. We allow the long file names for round trip export/import back into Chief, but it is technically an improper 3DS format. The option ought to be removed. I'm not sure on the Collada compatibility issues. It is possible that the Collada specification that other software is using is older than the one we are using. That should work itself out over time as the older software is updated. If you do have issues with Collada import or export please let our support team know so that we can improve it. Of all the formats out there it has the most promise of continuing to be viable. 3DS is essentially a dead format as it has not changed in many years. SKP is proprietary and has shown signs of dieing an early death due to lack of support by the vendor.

There isn't a way to have two people modifying the same file at the same time. What we do to manage multiple people working on documents like this is to use source code management software to enforce only 1 person accessing the file. Since we use this all the time for our software it seems fairly logical for us. Software like git or subversion are free but require a fairly steep learning curve to master. I don't expect that the average Chief user would want to invest the time to learn these tools, but they are available. File Locking can work, but if it gets turned off you can get yourself into trouble. Subdivision of tasks is possible. Working on details or layouts separate from doing the plan is one obvious thing.

Could someone with this problem please try turning off the "Synchronize with Cursor" option in Preferences Edit. Does the cursor show up at the cross hair location after you let the cross hair catch up to it?

Generated 3D data is not stored in the file so railings, moldings, etc. don't contribute much to file size. They do however contribute to memory usage. 3D data is rarely more than a minor contributor to file size. 3D data from symbols like cabinet hardware etc. have only 1 instance stored in the file so the cost in the file is small even though there may be 100's of them.

You may want to consult the CPU benchmarks before making your buying decision. http://www.cpubenchmark.net/high_end_cpus.html It would be interesting to do a comparison of Intel to AMD for ray tracing and other multithreaded operations.

6 cores is better than 4 cores. Hyperthreading effectively doubles the logical cores and Chief will attempt to take advantage of having more cores, but this may not be faster depending on the situation. Normally turning hyperthreading on/off has a negligible effect on performance. So while 6 cores looks like 12 to Chief with hyperthreading on, it probably is only marginally better. Occasionally, we will see that hyperthreading will actually decrease the overall performance, but it is hard to predict and the effect is usually marginal. The higher end i7's are good. If money is no object, I would suggest looking at the new Xenon's and consider dual CPU options with them. That can get real pricey, but if you do a lot of ray tracing it could pay off.

In theory 2 GB is the limit. But I think if you get a file approaching that you will run into performance problems that prevent you from actually approaching that limit. As far as I know no one has ever come close to hitting this limit. Typically CAD details and embedded images are the main culprits for file size usage.

A lot has changed with regard to rendering since X1 was released. I am somewhat surprised that the NVIDIA card is slower, but there are some really good ATI cards out there. The fact that X6 is a lot faster than X1 is no surprise though as we have worked on making OpenGL use more modern techniques, especially with X6.

.rfa files are an AutoDesk Proprietary file format. They provide an API in their application to access data in those files, although I don't know how complete it is. For us to read them would require at having their software installed or for us to reverse engineer the file format. I would look into ways to export to a non-proprietary format, such as COLLODA that we can import.

Sorry to be unclear. It is the text that is sent to the printer than counts regardless of the source.

Some details about the issue. We use Qt as our cross platform toolkit. The issue is in the code they supply. We are working with them to resolve the issue, but it isn't a trivial fix. I don't have an estimate as to when they will have this fixed. The issue has to do with fonts. Normally a PDF is created by embedding the font into the PDF and then just outputting the text. But in the case of Qt on the Mac they have not finished implementing the font embedding. So instead they draw each glyph as if it were a filled polygon. This quickly creates bloating, but does result in good high resolution vector graphics so the print out is crisp. The more text you have in a layout the greater the bloat. If you have no text on your layout the size on Windows and Mac is identical. But that is not a typical case. I wish I had a better answer. Our point of view on this is that it is important to fix, but the current solution does produce PDFs that print well. Which is better than not having PDFs. Interestingly, we have a completely opposite problem with importing PDFs. On the Mac they import and draw well and quickly. But the toolkit we are using on Windows has issues with some PDFs, especially those with embedded pixel based images. Getting everything to work the same on both platforms is never going to happen. But we will continue to strive to improve things wherever we can. I'm actually surprised that we managed to get as many features on the Mac as we did. Going into this project the idea that some features might not be available on the Mac was an acceptable although not ideal option. Differences in how well features work are fairly common. This is one example. We will continue to push to improve the result. We appreciate your patience on this.

That is really odd and not something I've ever heard of. I can't even speculate as to what might be the cause. I would suggest getting with our support team to see if we can find out how to reproduce the issue. Handle sizes stay a constant size on screen regardless of zoom.

Walls not aligned vertically is my guess. Would need to look at the plan to figure it out for sure though.