altoids

10-12 speed increase doesn't need a render farm. It slowly dawned on companies that the GPU was much faster than the CPU for non-graphic tasks, so now some code that used to be executed by the CPU is handled by the GPU. Photoshop did this with their transformations & plug-in filters, for instance. I'm guess that VW is doing the same thing for some of their calculations/operations. A couple of researches in Belguim made a simple super-computer by sticking 4 high-end graphics cards in a box and having them do the calc, video and info here: http://fastra.ua.ac.be/en/index.html A little birdy told me that Parasolids will be incorporated into the next VW release. But overall, I agree w/ clb. Before VW gets any more shiny, new features, fix the bugs and annoying features.

Save your SketchUp model as version 5, then try again.

Actually, it claims no such thing. It claims that you should "get ready to work 10-12 times faster" not that the software does. Logically, this would mean the software is 10-12 slower, and you have to work 10-12 times faster just to stay at your present speed. Or perhaps, with Biplab becoming the new CTO, it is a literal expression of 10-12 = -2, though what working -2 times faster means is not clear. Or as the famous Mr Holmes said, "When you have eliminated the impossible, whatever remains, however improbably, must be the truth."

These are very helpful techniques, but a even better would be that the wall in elevation shows the surface material as a vector hatch, as the wall sections do in VW08.

Is the conclusion that the only way to get a non-fuzzy 2D hatch (oh, lets go out on a limb and call it a vector hatch) on an generated elevation is to apply it manually, that is, additional drawing steps within the viewport? Petri, are you sure about the hood emblem, because a few weeks ago you were bitching about painful editing of class attributes and I was defending VW.

Hell No, but I didn't expect to end up driving a Yugo .

Wow. Is this true? All the sections/elevations created with the live elev tool ignore the wall type settings and render the wall as a texture? VW can only accurately apply hatches if I draw the elevation longhand? In all the discussions of VW vs. ArchiCAD, this one never reared its ugly head. ArchiCAD has a 2d and 3d surface rendering associated with every object, so tht brick looks like 2D brick in an elevation, or a 3D brick in a rendering, as it should.

Actually, OS X used PDF as its display technology since before OS X Beta, as OS X was little more than NextStep ported to Apple and made to look like Apple's Finder. In 1987, Next had Display PostScript, which was the father of Display PDF which is now rolled into Quartz. There are many vestiges of NextStep in OS X, such as the "Services" menu that no one seems to use, and the dock which everyone does. VW didn't start supporting Quartz until VW12, so OS X's display technologies where not implemented in VW until years after they could have been.

You can open the VW file on a Mac, which has inherent PDF capabilities. Every time you print on a Mac, it offers you the choice of generating a PDF file, no drivers needed. Alternatively, you can open the PDFs in Illustrator, and edit them, one page at a time. If the fonts are there but in the wrong colors, you can change the fill color and presto the color changes even without Harry's wand.

Your slowdown may be nothing more than VW requiring more memory to run and thus hitting virtual memory more frequently. Virtual memory swaps RAM out to disk and is primarily limited by disk seeks times and is many orders of magnitude slower than RAM access. RAM is currently cheap enough that you could theoretically try upgrade one of your Minis to 2GB and see if the problem is resolved, but the original Minis have a 1GB memory limit. You can see if memory is the problem by opening the Activity Monitor (in Utilities) and see how many VM pages are being swapped in and out, and compare this to VW12.5. Run this test shortly after a restart and launching VW (for both versions). BTW, I don't think 1GB was ever the minimum for 10.1. We run 10.4 with VW 12.5 on machines with 768MB without any problems. OS X 10.3 required 128MB to run, and we have file and web servers sitting in closets running on 384MB happily sending electrons all over the planet. BTW again, I think unless you are running a web or mail server, you are better off not upgrading your machines and putting the money towards a new box. You get a new fast warranted machine, and OS X 10.5 to boot. (The exception for a web server is because even the oldest machine is typically limited not by processor speed, but by bandwidth (internet connection speed).

I normally bitch and moan about VW's lousy UI design, but on this one, I think Petri is whack*. You can complete the editing with 4 or 5 operation (3 or 4 mouse operation and hitting return twice) using VW12.5 on a Mac and see the entire operation. Any menu item that opens a dialog box requires 2 operations (selecting the menu, and clicking OK when finished) so noting takes less than 2 ops and 3 if you actually want to do something within the dialog box. 1) Tools>Organization... (1 click) 2) Classes, if not already selected. (0 or 1 click) 3) Double click on the class. 4) Choose the fill color you want from the pop-up color grid. (1 click) 5) Press twice. Fewer than 1/2 the number of steps. Oh Petri... ----------------- *Actually, I always think Petri is always whack, which is what makes this all so fun.

Christiaan, you're right to expect 13.0.1. Is there a reason why this is not so? I'd think the bug sheet is long enough to qualify for a ..digit. A similar numbering non-convention happened with the 12.5 upgrade to 12.5 1 (or was it to 12.5.2?), which ate files and was subsequently replaced with another 12.5.1 upgrade that didn't eat files. As the upgrades were both given the same number, it was no easy to identify the safe upgrade. Can someone from NNA explain the numbering convention? What is signified by a .x upgrade, a .x.x upgrade and a build number? To quote Wiki

Ah, maybe idiotic was too general and strong, but the idea that the software imposes artificial limits on me is idiotic. And logically and functionally, I don't see why I can't call as many files as I want the same name. It may be idiotic to do so, but better me than the software. Anyway, to some extent you can on the Mac, provided the files are of a different type. I can have a folder called Foo and a VW file called Foo and an mp3 called Foo, and so on, without any problems or confusion.

Apple worldwide market share just rose to 8.1% from 6.2% a year ago, making it the No. 3 vendor with 37% increase in "growth". The times, they are a changing. More here: http://www.macrumors.com/2007/10/17/apples-3rd-quarter-2007-u-s-marketshare-up-to-8-1/

The debate may have been settled 20 years ago, but it was settled the wrong way. If I, as a end user, want to call everything the same name, it is not up to some idiotic software or software engineer to tell me otherwise. If VW doesn't have a private tag for every viewport name (and for every other object) then we are in more trouble than I suspected. Naming conventions should be a convenience, not a decree. This here is the western world, where we value freedom more than anything else. Just to show a little solidarity with digitalmechanics I am going to name every viewport 2/A6.3 and every file in my project folder 2/A6.3. If we all lay down and accept decisions just because they were made 20 years ago, the Earth would still be the center of the universe. And finally, digitalmechanics plight illustrates why the rule of only one name per object is so idiotic, because it forces us to modify our behavior for the software. It should always be the other way around. And without this skull-numbing rule, digitalmechanics problem would cease to exist.

Not quite enough. IF NNA was responsive and had the bugs/faults fixed by each major release, or even point release, I'd be quiet. But they leave incomplete features/bugs for *Frikin YEARS* then release a new version without fixing the previous errors, compounding the problem. I suspect the S.E. spend all their time as firefighters. This is not about the good hearted people at NNA doing their best. This is a commercial enterprise. No other software I use, none, is as buggy, error prone, incomplete and thoughtless designed as VW, and none is as expensive. And NNA consistently blames others for their bugs. See the years long problem with printing angled lines on the Mac. Screen flicker? This was an interesting issue in the mid '80s, getting the screen redraw buffer to synchronize with the CRT start of scan, 25 years ago. Coughs on printing PDFs; 12.5.2 still drops images out of PDFs. The stair maker is still tortured, grid area still wrong, use '08 for more than an hour or so on a PC and it grinds to a halt, network file access errors, 3D and PIO so ill-conceived that even power users don't use them, etc, etc, etc. These are not run of the mill bugs. I've been unlucky enough to work for companies that made buildings like this. I'm guess it is the same management style, different product. Running to get the product out the door, committee heavy, no one with vision running the division, everyone covering their ass, minimize risk taking, producing bland, uninteresting work, that no one takes responsibility for. Clients (that's us) willingly accepting poor work, and everyone blaming someone else. The end product is bloated, buggy software, with a button for every feature. No elegance, no simplicity, little thought. SketchUp (everyone's favorite example) is not the best 3D tool, but everyone uses it b/c of its ease. The product of a different management style.

tgm is on the money. Basic bug, simple to fix, but the code is released anyway. If this is the level of QC for a new release, how much of the code that we can't see is reliable? Why, oh why should I buy '08 until at least the first point release? So that I can be a Beta tester for VW? No thanks. Altoids in MA (For Petri: QC = quality control)

We use Macs, but we never upgrade until at least the first point release and more typically not until the .5 release. Why would anyone rush to upgrade? 12.5.x is relatively stable and usable whereas every new release is always buggy, no matter how carefully tested. Nothing like having 10,000 users kick your new code around to expose the bugs. As much as I'd like to be the first kid on the block with new sneakers, our time is precious and waiting a few weeks/months/years costs little. Post your question again in 9 months and I may have an answer for you.

My Sketchup imports are failing silently with SU 6. I have just patched VW Architect to 12.5.2 and SketchUp to 6.0.1145, and when trying to import a new SU model, I get nothing. I can import older SU models (or if I save a new model as version 5). Is this a known problem, or am I nuts (the two not necessarily being mutually exclusive)? I am running on a Mac OS X.4.10 on PPC.

Katie, can you put the old title in parentheses so people can follow it "BIM (VW 13, worth the wait?)?" Gaming technology: It is true that video games use clever techniques to reduce their polygon count, but we're not talking about VW suffering because it is rendering millions of polygons. It suffers because its 3D routines are not optimized for speed. A straight wall should have 16 polygons, 2 per flat surface. Sometime they are rendered a 4 polygons, but regardless, the 3d world breaks everything down to triangles. A curved wall more, but even a simple model with a few thousand polygons appears to stunt VW, meaning the frame rates are dropping below, say 10 redraws/sec., and this is without lighting, textrue, shadows, or transparency. Floating point calculations don't slow a modern CPU down. Look at the SPEC_fp and SPEC_INT for any modern CPU (less than about 5 years old). The Power PC consistently had FP values that exceeded its integer times and Intels are similar. More importantly, the video cards do the floating point calculations for 3D. The current ATI Radon 2900 can perform 475 billion floating points op per sec (flops), calculate 47.5 Bilion shaded pixels/sec and process 742 Million triangles/sec. Real world consideration will slow a modern high-end video card down to about 30 million rendered polygons/sec (30 frames /sec x 1 million polygons.), lit, textured, shaded and transparent. Now, my crusty 3 year old Mac surely doesn't have that sort of graphics card, but even the anemic Intel GMA950 can handle 1 million ploygons/sec, though even this might (sadly) be faster than my Mac's. But the problem here is VW making its 3D models redraw quickly. I don't need accurate when moving a 3D model on screen, I need fast. When I dimension, I need accurate. SketchUp speed would be fine. Do your SU models move in 3D as slowly as your VW models? And before I lose my point entirely, it is not at all about the 3D rotate speed, it is about the 3D design effort. SU is held up, not for its speed, though it is better than VW on my machine, but for its easy of use, which translates into power. If VW interface came close to it, I'd settle for stuttering speeds. I'd more than settle, I'd praise it.

Call it what you will, VW Architect is sold as BIM that allows architects to generate 2D drawings automatically from their model. Build the model, generate the drawings, augment them as needed. As an architect, I don't care how building managers use BIM - the ones I have met (who seem to have a disproportional amount of influence of the projects we bid for) invariably seem to have failed out of vocational school. Different species. I care about design, about developing and presenting our ideas, and finally, producing a drawings and a CD set that is clear, accurate and easy to manage. I also care about how good VW is, not only because we use it, because I love telling PC AutoCAD users how great the Mac is, and how cheap/effective/wonderful VW is, or almost is. And it is the almost that is infuriating. The BIM part of VW that is lacking as far as architecture is concerned, is the lack of simplicity and continuity. Many tools are frustrating to use, incomplete, or added for the comparison list only, and eventually fixed years later. The feature list for VW12 included "circle by 3 points," "live sections", "Class overrides" and a "new arc tool". Repeat that list a few times and allow its full meaning to sink in, that after years of frustration, in 2005 VW finally creates a usable xx tool. In 2002 a friend of mine was working on an 80,000 sq. ft. signature architect building at MIT that was being drawn on VW, but they could not use the wall tool because it would not reliable heal wall intersections, so they used VW as a simple 2D drafter for all 400 sheets in the set. Too many steps and nested dialog boxes, jumpy screen scrolls and rotates, views that disappear, in 3D and 2D (the scroll wheel on Mac was for the longest time all but useless with VW, but worked fine with other apps) - basic usability that needs radical improvement. Not a BIM deficiency per se, but it might as well be one. For example, the 3D view resetting to wireframe all by itself every time. I know that I can set up a view, but it is a work around, not a feature. A useable BIM package would also have many features that VW is missing or are so buried as to be effectively missing. Automated numbering of sheets, drawings and details, with manual override if wanted. User selectable 3D clipping so I can look at any parts of the model I need to, quickly and effortlessly. Real time 3D. Not zoom/rotate in stuttering steps. Even video games, like Quake and Unreal have what feels like an order of magnitude faster 3D rendering using OpenGL, with shadows, lights, transparency, (and motion and gore and BFG explosions) with complex models. It should be that anywhere drawing information appears, be it text, elevation, 3D or 2D, viewport or design layer, it can be meaningfully edited, with the results immediately visible in all views. Group editing of parts. No guessing where a 3D point might land. Call-outs that are intuitive to place and edit. Have you tried to position a spot light? 3D positioning of object with a mouse is old-hat in the programming world, but VW makes it a tortured process. Not impossible, just unpleasant. Renderworks can produce nice images, if you want to invest the time and energy to make it do so. But why should I? There are dozens of packages out there that are easier to use and produce better images without the effort. It's not that VW can't do BIM, it just does it poorly. And I suspect that there are many people who use VW who use just a fraction of the 3D stuff, because it is so tedious to use. Watch the video of how to build a 3D massing model, and it hard to believe that this is a feature. Even FormZ's screwy interface is easier to use, and it really can render anything. Yes part of this is a VW user interface problem, but it manifests itself as a software deficiency as whatever the cause, the features are not being used. And having just installed the 12.5.2 update I am glad to see that my complaint about the ceiling grid has now been fixed, but it still reports the wrong area. Perhaps in 13.5 it will work.

Illustrator's two arrows are not the program's finest moment and although both icons are arrows, they function differently. The black arrow is for selecting and moving objects and the white arrow is for manipulating the points within those objects. I think Adobe confuses many users with the two (actually called the selection and direct selection tool). It would be much better if they rolled the two similar functions into a single tool, with, say an option (alt) key press to choose a point or object. I don't understand why I need why different arrows in VW to draw in a 3D window. Can you give me a concrete example of when both are necessary? The selection tool, in 2 or 3D does exactly the same thing - selects the object under the point of the arrow.

Petri, I would maintain that VW12 is a half-baked BIM tool. Half-baked is not an ANSI measurement, but derived from the level of annoyance from trying to use the software. The most glaring example is the selection tool. Good programming guides dictate that only the relevant tools appear for the operation you are performing. This is why items on menus are dimmed as they become irrelevant to the user's current operation. This should be persuasive throughout the whole program and from the VW13 blurbs, it sounds like this has been at least partially implemented, with only relevant command appearing in pop-up menus. However, 3D modeling in VW fails this good design guideline with their selection tool, the most basic and commonly used tool. There is no need for two types of selection arrows that perform exactly the same function in 2D and 3D. A not-half-baked program wold have one selection tool, and when I click on an object, the software would determine the objects properties, something software is exceptionally good and fast at doing. Once it determined if the object is 2 or 3D, the palettes would show me what commands I can execute, no need for me to tell VW what it already knows. Moreover, the tools should remain exactly where I leave them. If I put a screwdriver down on my bench, when I next reach for it without think, it should still be there. When it is not (having rolled off the bench) I waste my time looking for it, loose my train of thought etc. VW has the problem of round handled screwdrivers. For many tools it simply requires too much effort to use. The tools should be invisible, second nature, reflexive. I don't want to have to think about how to use the program, I want to think about the design. All I want to do is point and click, and not have to interrupt my train of thought just to use the correct function. This is characterized by yet another programming and software design guideline that software should be written to minimize the user's effort, not the programmer's effort. VW dual selection arrow likely arose as it was easier to add a second icon and write all new routines for the 3D environment than rewriting the existing routines. This adding of a new button for each new function is awful user interface design, but easy on the software engineer design team.

Petri, Reasons and justification for unhappy customers in a subsequent post, but first... We're wandering off topic but I think you'll find you are mistaken about line widths. Until VW12 was released, VW on a Mac (OS X) printing to a PostScript printer did not draw or print diagonal lines correctly because NNA had not updated their drawing routines since OS 9. Nothing to do with Apple. Even though the Mac's OS X screen was driven by PostScript since '01, VW used old imaging routines. Even Katie admitted as much, when she wrote: Note that she used "alleviate" not rectify or fix. Also," carbonized" is a Mac term for software written using the old, legacy routines that runs on OSX. Please read the whole thread referenced above "Wrong Line Thickness (revisited) .

Petri, Not a CAD monkey, actually the other end of the spectrum, principal of the firm. Which is why I will not be fired for posting during work hours, but more importantly why I care about the quality of the software that we buy. The firms money is spent on software and the employees who use it, which is me some of the time. If we don't spend it, it goes into my pocket. The diagonal line was only on the Mac version of VW, but it wasn't due to the Mac OS in any way. It was due to VW not updating their legacy code. See Wrong Line Thickness (revisited). The proof was that the issue was fixed by a VW update. Type in a string of meaningless gobbled-gook to make VW work as advertised? What will I have to type in for this release to make it work as advertised, me thinks. If the move command is a offset move, like SketchUp (select the object, then select a start and end point) that is a welcome improvement, but hardly full-point release worthy.