Embarrasing VW failures

[Jim Smith]

To go back to original post's subject; I have used the "clip surface" rather than the trim with better results ( for the most part). For what it's worth, I only use trim tool for walls and lines for polygons, and circles I use clip.

[islandmon]

Over the last two decades I've used Minicad/Vectorworks on many thousands of projects and taught many hundreds of students. i empathize with those who must demonstrate critical functionality to others ( recalling Bill Gates publically crashing Win95 while attempting to print ).

My solution to the above mentioned VW tool problems is normally to clip and decompose in lines then recompose into new surfaces.

Also keeping in mind that Vectorworks is NOT a drawing program but a programming program. Shifting the paradigm is important especially for those who still most use a mouse rather than a precision pen&tablet for input.

Regardless, it's important to develop ways to always check on the parameters and registrations between events. VW offers exceptional feedback loops.

I've tried many different techniques and approaches and i'm still developing new ways to do things with the tools available.

Nevertheless, at the very heart of Vectorworks there is a critical flaw in the PIO & Class data structures which allows for persistent corruptions in the 'saved' file structure. Until NNA address this fundamental issue all else is nibbling around the edges.

The corruptions are always lurking and can cause mayhem with DXF/DWG exports.

Perhaps tech should chat with Austin Meyer over at XPlane and let him give them a 'heads-up' regarding calculation leakages, and the benefits of 'OOP'.

regards,

ejarmstrong

[alanmac]

Islandmon

Are you saying in this post and in your thread Death of Vectorworks that there is fudimental flaws in the basic programs writing, scripting whatever you call it, and that this is the main reason why we get file corruption and the program starts to get screwed up.

I thought it was something I had done that caused symbols to lose part of their make up when doing an undo.

Or suddenly loads of rectangular shaped lines would appear which would mean me saving each element of my drawing piece by piece to a new file in the hope of removing the corrupted element.

Or that all of a sudden once something strange had happened in the file it then took ages to do things, longer to open, save etc. is because there is a unaddressed basic flaw in the program writing?

I'm know nothing of coding, script writing but if what you are saying is that no amount of additional features such as Sketch, new tools etc. will help you because within the program is this problem, its like a fault in the foundations of your home.

I think we need to be reassured by NNA pretty quickily about this issue and clarification of what you are saying. If you export a file as Vectorscript and re import it the results should be the same each time, so whats going on !!

Your writings as certainly got me very worried and I'm only a single user, let alone large companies with huge investments and multiple seats.

I have deadlines to meet like all of us and the thought that the next action I undertake in Vectorworks may corrupt my file and lose me all

my work seriously worries me.

I was prepared to accept issues when upgrading, opening old files, bugs etc. which would be patched and sorted but to hear that there is a fundimental flaw unaddressed for years causing file corruptions and other problems is not acceptable.

Alan

[David Bertrand]

I've been playing around with the trim tool and found that if I pause a long time over the segment to be trimmed, it usually works ok. If it doesn't, I undo and try again. I have to pause longer over a circle or arc.

[islandmon]

Let me make my point perfectly clear on this issue. As a User since Minicad v1, and also Photoshop v1, Filemaker v1 and many other apps including MS products.

Vectorworks has evolved into the most unstable app. I've ever used ! Also, it is the only program in recent memory that manages to eat it's own unprotected file structure !

The short 'laundry list' from Alanmac is just the tip of the berg.

Read "Death of Vectorworks ?" and run the vectorscript export & import tests. Watch your hard work decompose into chaos from layer to layer, wall to wall, symbol to symbol and file to file.

There's no end to this madness.

VectorWorks corrupts the memory addressing and then pages out the corruption to the disk. Each time you load and save the corrupted addressing becomes more severely outta whack with your intented CAD reality.

Look, the reason that I'm not doing my beloved CAD Architectural work for my high-end clientel, and instead spending inordinate amounts of time writing to this techboard and responding to emails is because ALL my current project files are corrupted !!!!

Even after I totally decomposed them and rebuilt the files layer by layer from tested and clean objects , within a matter of loads & saves the issues started to reappear. This has been the case across ALL my different hardware & systems configurations running different versions of VW on different OS.

It's not you and it's not me ... it's not Photoshop nor Filemaker. Microsoft Word, nor X Plane ... It's not OSX.

There is definitely a MAJOR problem lurking at the very heart of Vectorworks.

It maybe instructive to read what Austin Meyer, Genius dev of X Plane, had to say about coding with C++:

X-Plane 7 is written with ARRAYS AND PROCEDURES.

Now X-Plane 8 is written largely with VECTORS AND OBJECTS.

What's the difference?

X-Plane's language, C++, stores all sorts of data in ARRAYS... lists of numbers that contain data.

For example: the lift of an airfoil... the lift is recorded for each of

3,600 possible angles of attack _one-tenth degree increments for each of the 360 possible degrees angle

of attack, with math to interpolate in between.

But here is the problem: What is X-Plane thinks that the impossible case of 361 degrees angle of attack exsists? Then it will look for the 3610'th index in an array with only 3600 indices.

What happens then? NOBBODY KNOWS. Maybe a computer crash. Maybe a bad flight-model. Maybe nothing. When you go past the maximum allowable array range, all bets are off:

the memory of your computer could be scrambled

who-knows-where and result in a computer crash right at that

nano-second, or maybe two hours later.

This is the achilles heel of the C+ language, and has been for decades:

Going out of array bounds can crash your computer...

and you never know how much later the computer will crash, making it near-impossible to tell where the problem really is,

thus making the problem near-impossible to solve.

Enter Ben Supnik, algorythms expert, who shows me how to use VECTORS.

Vectors are just like arrays, but with one

major difference: WHEN RUNNING X-PLANE WITH MY COMPILER WATCHING THE CODE, THE PROGRAM WILL STOP THE VERY NANOSECOND ANY PART OF THE SIM TRYS TO SO MUCH AS =>LOOK<= OUT OF BOUNDS,

IMMEDIATELY showing me the problem. This means the

achilles heel of C++ is finally armored: any out-of-bounds access is immediatley seen and solved... there are

no "skeletons in the closet" that went out of bounds without me knowing about it. If the program SEEMS to be running

fine, then it really IS running fine. That is priceless, and is of

course integrated into X-Plane 8.00.

As well, UNLIKE arrays, VECTORS can be re-set on-the-fly to ANY SIZE, WITH NO LIMITS EXCEPT THE MEMORY OF YOUR COMPUTER.

What does this mean to us? It means that Ben Supnik can design scenery with as many polygons as he likes... NO LIMITS.

Robin Peel can give as as many airports, NAVAIDS, airways, and fixes as he likes... NO LIMITS. Sergio can give us as many

objects as he can build... NO LIMITS. You can design 3-D cockpits with the new 3-D cockpit technology with as much detail as you can imagine... NO LIMITS.

The other major internal change is I have gone from PROCEDURES to OBJECTS.

What does this mean?

Procedures are the pieces of code that manipulate all the data in the sim.

The other achilles heel of C++ has always been that you can work on a procedure to get it to manage data just

PERFECTLY for a YEAR, and think you have achieved Nirvana, ONLY TO HAVE

ALL YOUR WORK LOST BECAUSE SOME =>OTHER<=

PROCEDURE IS MESSING UP THE DATA YOU WORKED SO HARD TO PERFECT!

Say, for exmaple, I think my lift-finding procedure

has found the perfect lift for an airplane... what good does it do when some OTHER procedure is _accidentally_ MESSING UP

THE LIFT DATA? WE get garbage in the flight model, and that ruins everything.

The solution is OBJECTS, and here is how it works: Each OBJECT is a procedure that HIDES IT'S DATA INSIDE ITSELF

SO NO OTHER PROCEDURE CAN SEE IT! COOL! This way, once I get a procedure to FIND the perfect lift coefficient,

we get to KEEP it... no other procedure can mess it up! AWESOME! THis is done in X-Plane version 8.00 as well.

_________________

That about sums up my thoughts for VectorWorks...

regards,

ejarmstrong

G5, 1gb OSX.3.8, VW/Architect 11.5 Please pardon the following extensive post:

[jan15]

quote:

---

Originally posted by islandmon:

... ALL my current project files are corrupted...

---

That's really shocking.

Does anyone else have this level of problems? I've only had two files corrupted in 10 years.

[ionw]

Jan,

We have had probably 200 in the past 3-4 years. Out of several thousand files I suppose it isn't bad. We noticed a rise in corruption occurences when the drives were getting full. We alos notice that using the built in backup system to save to a different directory was a lifesaver, over 90% of the time people are able to pick up and lose just a couple of operations. (we use # of operations, not minutes as it doesn't interupt your work when it backs up)

my two cents with a little change

ion

[nam]

Ben Supnik?

Robin Peel?

Sergio?

What the heck has this all to do with normal day-to-day use of VectorWorks? As someone who draws for a living, why would you care that multiple exports/imports using VectorScript may cause corruption (see note below)?

We have been involved with the design of many buildings ranging from houses to multi-million dollar resorts using VectorWorks (back to the MiniCAD 4 days). Do we see the occasional corrupt file....sure (anyone using the program intensively would say yes). But overall, the application's stability, usability, and file quality is excellent.

VectorScript was designed as an easy-to-learn, PASCAL-based scripting language for automating processes in VectorWorks. It has grown to be a robust development platform for both NNA and many third-parties. The "Export VectorScript" function has its uses for scripters, primarily to output a non-binary (i.e. text file) version of the drawing, however I am pretty sure that it was never designed to be used for repeated export/import as you have discussed.

Your characterization of VectorWorks as "unstable", "having critical flaws", and that it's "NOT a drawing program but a programming program" just because you are seeing strangeness when attempting things outside the norm is unfair and misleading.

[Geoff McBeath]

Although this thread has turned into strange complaints about many things, there's been very little response about the original post. I've just had a quick look at the scenario as laid out by propstuff. As a user and trainer, my overall opinion is this example could be demonstrated without failures and embarassment. Based on the original post, my view is that the embarassing failures described are a combination of drawing method choices and the unfortunate choice of legacy tools that are leftovers from the old days.

Here are some of the ways I might have done this differently.

>>The other day I sat in front of a class of design students intending to demonstrate using the various Split, Trim, Combine options. Instead, through an increasingly unpleasant 20 minutes, I managed to demonstrate how flakey and unreliable these tools are in VW.

>>A 4 week old Lab of brand new Dells running XP with VW11.1 freshly installed

>>2D resolution set to Very High, Snap radius 1 Pixel.

Snap radius of 1 pixel might be the first potential problem area, especially for new users. It often seems paradoxical to them, as they think that a smaller radius will make them more accurate. In truth, it is more likely that a small radius will make them miss their snaps, as they have to be right on top of the point or they don't get it. It's possible that this setting contributes to some of the problems described later in your description. It is, of course, a personal preference, but we find that the default setting of 5 is a good balance between ease of use and control.

Another possible factor is the Grid constraint. I can imagine a circumstance where having your snap radius at 1 and your Grid snap on could cause you to snap to the grid when you meant to snap to a point. With a larger snap radius, this won't happen, since object snaps take precedence over grid snaps.

>>Demonstrating the Trim tool on the small sector of circle between the tangents reliably deleted ALL the circle insead of trimming it to the tangents. The lines were not snapped to the circle DESPITE having been originated FROM it.

>>Failure 1

>>I explain that despite the intended function, no software is perfect, and that the updated version has improved the trim tool.

>>On many subsequent tries of the same task, on different systems with different versions including VW11.5, the trim tool fails about 40% of the time.

I would not use this tool in doing this demonstration. The message that we deliver in basic VW training is that the Trim Tool is an older tool still available because some long-time users will complain if it's taken out, but that is not one to be considered for most tasks. It's functions have been largely supplanted by the Split Tool, which is far more robust and has better functions. See below for how to use in this context.

>>Next try

>>Using the Split tool to split the circle between the the tangents I explain that we should be able to trim each end of the resulting Arc back to the tangents. The Split tool repeatedly just fails to split the circle.

>>Failure 2

>>I offer the doubtful looking students the explanation that "it usually works". I'm feeling a bit stupid.

On many subsequent tries of the same task on different systems with different versions including VW11.5 the split tool not only fails about 10% of the time, but sometimes actually RESIZED THE RESULTING ARC to, variously, 245, 248, 239.3, etc. On one subsequent retest I discover that the circle that was made by tabbing in 250 was actually 250.02(!?)

>>Eventually I give up and use the Split by line option.

The Split by Line mode is the right way to go in the first place. Split by Point on a circle simply converts it to a 360? arc. This is logical and predictable, but not what I presume you want to do. I have tried but was unable to replicate your failure with this. It could be related to snapping, and a snap on the line or grid instead of the circle when doing the split.

>>Next try

>>I now show them the Combine/Connect tool and explain that it can be used to trim, combine, connect etc.

>>In the third mode I start at the arc on one side and drag to the adjacent tangent.

>>Nothing happens.

>>Try again starting at the tangent and this time it works.

>>Students want to know why it didn't work the first time. I offer weakly that some functions need to be done in a particular order. They have "well how are we supposed to know which?" looks on their faces.

This is how the tool is supposed to work. Tell your students that the way that they can tell which order to do it is to look at the two pieces of geometry you are connecting. If the arc is extended it will continue to curve away from the line, making a combining of them impossible. The line extended will connect to the end of the arc, making a successful combination. I use an example just like yours in our introductory course, and by explaining this logic, everyone gets it, sees it as a feature not a bug, and can avoid problems with this tool in the future.

>>Now the other side. almost NO combination of options will succesfully join the remaining tangent to the curve of the polyline. About 5% success rate there, and no repeatability.

>>Failure 4

I can make this work on our office computers, so I don't know what happened differently for you, but I think it's the wrong method here, because as soon as I do the first combine of line and arc, a polyline is created that already has that final side. It's just not displaying the line. Give yours a fill colour and you'll see what I mean. All that's required is to show that edge using the Reshape Tool.

>>Next try

>>I explain that, as we ultimately want a surface, we can use the surface commands to get the desired outcome.

>>Selecting the Circle and the tangents, I remind them that the Combine into Surface command will use boundary objects to make a new surface. OK, I use that inside the margin of the tangents and circle and make a new "sector" surface, then, I say, that can be added to the original circle with the Add Surface command.

>>Guess what?

>>Failure 5

>>Intsead of adding properly, there is a sliver on only one HALF of what was the margin between the circle and the "sector" surface where the surfaces have not met. The students are now either laughing openly or muttering about what crap this is.

>>I undo back to the original circle and tangents, move the objects and zoom a little to centre them on the screen, remake the sector, and re add it to the circle. >>>>THIS time it works and I have a polyline.

>>"What did you do"? they ask, "why did it work the second time" and not the first?.....................................................

>>Well: WHY?

>>I don't know.

I think this is another part of your "perfect storm". Combine into Surface falls into the same category as the Trim Tool. I tell new users in our courses that it's a 'legacy' tool only, and its functions have been supplanted with the Compose command, which will do this job perfectly (provided, of course, that the geometry is properly snapped). In re-creating your example, Compose works great.

>>Why would repeating the same sequence of construction and use of tools and commands work sometimes and not others?

>>I have subsequently tested this task repeatedly on 6 different combinations of machines, operating systems, and versions of VW including11.5 to try to offer my students an explanation, and the only thing that was repeatable was that sometimes it worked and sometimes it didn't.

>>The split tool failing to split the circle, the tangent snap failing to snap to the circle, the combine connect sometimes joining the tangent to the arc, the erratic surface commands; in this task were all unreliable AT BEST.

>>It's not as if this was a big ask; joining a pair of tangents to an arc is nearly as basic as geometry gets.

>>Why is VW such a flakey piece of software? Or am I misguided; is all CAD software this unreliable?

>>What am I supposed to tell the students?

I have been in your shoes. When things fail during a live demo, it is uncomfortable, and it sounds like you had a particularly rough class that day.

However, although I have often had problem situations shown to me like the one you've described, they are almost always traceable to some problem with method or understanding of the software. I don't know precisely how you drew this thing, but I think you could have done some things here with different methods. Here there is an added component of the problem, legacy tools that in my view should no longer be in the program. Nothing in the manual will tell you which tools to stay away from, but as one instructor to the other, I think that this is the insight we have to add in order to make our courses more worthwhile than simply reading the manual. My experience is that most users are OK with the information that some tools should be avoided in some circumstances, as long as they know it, and don't have to have the frustrating experience you've related.

You close your remarks with "What am I supposed to tell the students?" Well, this is a very manageable drawing problem. If I were in your position, I'd make this example work perfectly, go back and say, "This thing didn't work at all last time. I'm going to go through this again, showing you a much better method."

Geoff McBeath

Resolve Software Solutions

www.resolve.ca

[propstuff]

quote:

---

Originally posted by propstuff:

I have been talking to one of the engineers who responded privately to the problems I uncovered and they have identified at least some of the bugs.

---

Thanks for taking the time to reply Geoff, however it seems that "all" the problems I noted are attributable to bugs in the program which have subsequently been identified, and not the use of the tools.

The failures were due to a combination of tangents failing to recognise that they had points co-incident with the arc/circle, and also the circle being resized by the split tool.

The latter can be observed pretty well 50% of the time on my VW10.5. BTW grid snaps were off.

As far as the order of operation for the combine connect tool, your logic is good, except that I've had it randomly work or not work in either direction. In this case the combine option is supposed to trim back either/both parts to the intersection, so I can't see why it should matter which is selected first. Perhaps I'm wrong? But it certainly works in either direction ...sometimes, and, btw, if the circle is selected first it will not extend away from the line as you suggest but will trim back to the line properly. In fact i just discovered, when it works, an arc that is short of meeting the intersection point with the tangent, will be extended along the arc line till it meets the tangent and will join tangentially. Neat.

Remember I have now done this same sequence nearly 100 times now looking to identify the problems. Stubborn/pigheaded or Committed/ tenacious....is there a difference? :-D

Trim tool vs Split tool?

They do similar but quite different things.

The trimtool trims things back to an intersection which the split tool does not. At best the split tool can keep the part of the object you choose, but that's not "trimming".

Perhaps you meant the Combine/connect tool rather than the split tool? but remember it also failed due to the same "intersection evaluation" bug.

Combine into surface/ compose?

Again similar but quite different.

As you note; the compose command MUST have it's parts touching EXACTLY at the ends to work. (a major source of unreliability in the first iterations of this command). and it converts those objects into another object.

Note; in this example, the tangents and the arc must have already been trimmed back correctly for it to work: precisely what had failed to happen.

On the other hand; the Combine into surface command uses boundary objects (whose ends may touch or not, as long as they overlap) to create a further object.

Quite different you see, and in many ways far more useful.

Any hoo, thanks for your thoughts. With luck we'll see those bugs fixed for the next release and can look forward to a more reliable product.

cheers,

N.

[ 04-01-2005, 02:14 AM: Message edited by: propstuff ]