why same look and feel?

"yogesh" wrote

You have a lot of questions on how CADs are build, Yogesh... Want to make a new one ?

CADs are similar for the same reason that a car is similar to another car : innovation is (usually) an incremental process in which competitors improve an existing product by taking good ideas from the competition or from the same research work... Besides, learning time is an important factor in user cost, so any user interface (UI) should be as intuitive as possible to reduce it where "intuitive" generally means "as close as possible to other software's UI..

Remember that a "standard" UI might be significantly different from an "optimal" UI . The best story I have is the QWERTY keyboard, which was designed to SLOW DOWN the pace you could type on mechanical typewriters, to prevent the hammers to collide while typing. There would be much more efficient keyboard layouts today, but training time makes them commercialy unviable

So if you intend to write a new CAD, you should probably stick as much as possible to the UI of existing ones.

I think I-DEAS users who have tried their hand at UG NX would argue with the "almost-same terminology and look-n-feel interface".

Go back and look at the UG Museum.

Some of the CAD packages were started from Hanratty code, Computervison, Unigraphics, Anvil, AD2000, AutoTrol, etc. A few were started from scratch, Intergraph EMS, Applicon, Ideas, CATIA, CADAM, and late to the game Pro/E. After these were established, then came the Windows interface systems: SolidWorks, SolidEdge, and the CAM programs. A lot has changed in the past

23 years since the PC appeared on the market and even more has changed since NT4.0.

One reason the new Windows systems look the same is that they all use the MS API for the GUI. It has significantly reduced the cost of developing a system if you can use canned routines for the GUI. The other thing that has helped these systems is that they bought the solid modeling kernel instead of developing their own.

Most of the systems I mentioned have been merged with other systems. UGS owns the Parasolid modeling kernel used in SolidEdge, SolidWorks and Unigraphics. They also have purchased over the years Applicon, which had earlier merged with Applicon, Ideas and Intergraph's CAD business, SolidEdge and EMS. Pro/E bought a good share of their market when they bought Computervision. Most of the company I work for was Computervision, so we are now using Pro/E. We still have a large share of UG seats.

Really? Why's that? Is I-DEAS end-of-lifed yet?

Oh by the way isn't SolidWorks older than SolidEdge? Anybody talk about Ir> > I think I-DEAS users who have tried their hand at UG NX would argue

2+2=4

y=mx+b

If someone visited us from another planet our initial communication would be in some form of graphical mathematics.

It all probably has to end up looking very familiar - because IT IS.

No, but it's coming. "Do you hear that sound, Mr. Anderson? It is the sound of inevitabtility".

The last release of I-DEAS, I-DEAS NX 12, will be released in the latter half of 2005. After that, I-DEAS users are expected to migrate to UG NX 3 (or later) before 2008, when I-DEAS support is scheduled to end.

I-DEAS and UG will be basically interoperable as far as data goes by I-DEAS 12. Interface and functionality-wise, the I-DEAS philosophy is basically being scrapped in favor of the UG model. At least that's what the users are seeing so far.

SolidEdge and SW were being develped roughly at the same time. I was under the impression that SE started first. Integraph botched the first release of SE (missed release dates etc) and SW came out with a working piece of software almost a year earlier. Note I said "working."

The reason behind constantly asking you about CAD,parametric design and other related questions is... The person under whom I am completing my project is very much against using drafting packages as he thinks now a days all the *CA-Design* package produce drafting as a biproduct so there is no need to learn the drafting packages as such. and I also followed his views till some days back.But it's very hard to understand the parametric and feature desing concepts without not knowing the principles of *CADrafting* as in *CADesign* literature also the limitations of drafting package are referred while explaining the above terms..So I was under lot of confusion whenever he was refering to the terms like constraint based and other terms.So I started learning autocad by my own and now I have almost a mature view of the terms used in Design and Drafting.It is a sort of revealation to me now as I studied the CAdesign packages first , then learned drafting packages and now studying both with historical perspective in mind.

while working on solidworks,catia,UG,Ideas and Proe I observed following things. all the packages except I-DEAS used the sketcher and datum plane concept.? and also IDEAS seems to be more easy than any other packages.? eg. How to draw a through or blind hole starting from one vertex of a cube and diagonally cutting the cube or how to draw a hole on the cylindrical surface of a cylinder.? In Ideas you can rotate or move the reference planes but I have not seen this facility in SW or CATIA? How to do the above things in other packages?

regards, Yogesh Joshi

I-deas started out as a menu based system. This was pre Master Series code. SDRC spent a lot of money and time developing their current interface. It, even today, is a damn good, well thought out interface.

y=mx+b?

One of the ways to express a straight line.

After you've established the context "Hey, look, they're showing us pi," decided on a base... Then you need to start constructing sentences to learn/teach grammar.

In England we are taught it as: y=mx+c

Seems like we immediately have a deviation from 'same look and feel'.

Your mentor is correct in the vision, however the reality today falls quite short of the mark.

The key problem area lies in communicating the design intent outside the modeling system. Very few MCAD systems today support the elements needed to properly represent design intent outside of the 2D drawing context. Notably, I-deas has this in the form of PMI data that exists as fully 3D model annotations that can include most common design intent representations directly on the model. (ie: tolerance, GD&T, Manufacturing notes & such..)

Those systems with this capability still only address half of the problem. Viewing this data outside the system is problematic in that either a license of the system is needed to directly use the data, or the data must be exported to either a neutral format (VRML, for example), or a semi-neutral format for use with view/markup software of some sort.

Other issues involve access to the data in many different settings.

3D representations can be viewed and printed, but still require heavy resources to actually move about as easily as 2D representations do. This can sharply limit what data people have access to, particularly when they are working off-site away from the master data repository.

Having said that, many 2D techniques such as layouts can continue to be useful in the 3D context when used as the basis for associative models.

These basic problems, combined with the lack of appropriate features and problematic translation of even basic features between systems are the primary drivers behind ongoing 2D work today.

For some problems, creative feature based tolerancing can go a long way toward addressing the communications issues, however geometry translation can still be an issue in many cases.

I agree with the core idea that drafting packages should see less use, but we have another basic problem to solve (assuming the above can be reasonably addressed. That problem is compute power. The CPU's of today cannot easily manupulate full parametric, feature-based model representations easily. The bottlenecks of both computer power and RAM to hold the result limit what can be done on a PC, while more expensive UNIX systems can hold the datasets, their CPU power is lacking and they are expensive.

The mostly sequential design of most MCAD packages today also prevent multi-threading, and or clustering from addressing the compute side of things, at least where MCAD is concerned. (Analysis tends to benefit greatly from at least the clustering technologies today.)

On the PC, the win32 OS places a constraint on RAM as well. Linux holds some promise in this area, but few systems have ports at this time able to really take advantage of the additional addressing capability. (Also PC hardware vendors largely target the win32 OS, for good reason, making this even more of a niche approach for MCAD at this time.

Personally, I am not sure the parametric systems will ever get there. Variational systems exhibit strong potential in this area, but they are not the majority at this time. (I-deas being the most variational one out there, but with strong parametric leanings at this time.)

Both of these will eventually get addressed one way or another, but until that time we will continue to be limited on model size. Most systems today employ clever (and some not so clever) schemes to enable the user to easily address parts of the model as needed for authoring or changes.

While these limits are in place, 2D methods may continue to provide enough benefit to justify their ongoing use for some time yet.

(snip)

I-deas does use the sketcher concept, though it does have both 2D and

3D representations, making things difficult to nail down. A datum plane is pretty much equal to an I-deas reference plane and or coordinate system.

An I-deas sketch plane can be a reference plane, solid model face, or just a set of points in space the user can directly manupulate in a non-parametric way.

(snip)

No disagreement here :)

The difference lies in the constraint model used. Strictly parametric systems basically require that everything be associated, or built off of, a few primary data points, such as a base coordinate system, or set of planes.

If you want to rotate a reference plane (datum) in these systems, you must build that capability into the model in advance. (Violates Doug's rule of CAD.) Another option would be to redefine the references used to construct the plane at a later time. (Pro/e, for example.)

Both options demand, from the user, either advance knowledge of the model and its potential changes, or in depth knowledge of both the system and the particular model representation of the model at hand, in order for the user to make the appropriate changes.

I-deas will allow both the parametric model, or a hybrid approach to be used. This is hard to explain, without writing a short book...

It works like this:

Anything you build associative to something else that is a part of the model definition, and is itself associative to the primary coordinate systems will act as parametric things do. The system will make the appropriate changes when requested. The definition itself captures design intent along the way.

Anything you define in a non-associative way, such as via cursor pick, or via the transform commands, will be associative in every way except for the actual transform data. (You can think of this as keyed in data generally not allowed in strictly parametric systems. Generally, these methods fail to capture design intent in the expected way.

So, if you were to build a loft, for example, using the strictly parametric model, you would have to first define a bunch of planes to sketch on, then the sketches, then the loft. Each part of the loft could be changed according to the flexibility for change built into the loft.

You could also just build a bunch of sketches in space, or import them

--it makes no difference, then build the loft. When changes are made, you would be in charge of the spatial location of the loft sketches, while I-deas would take care of the rest. Assuming the sketches were built in an associative way, that is...

If they were imported, for example, the entire loft would require manual modification not too different from the older non-parametric systems, yet parametric features could be built onto that same loft that would respond as expected to reasonable manual changes.

So, I-deas is a hybrid modeler in that it can be used in a highly parametric way, but that requirement is not enforced on the user. While this does make some things easier (like assembly, and use of outside model data as the basis for in-system parametric models), it can cause a lot of problems for the user, unless the underlying concepts are well understood.

Hats off to you doug for such an elaborative reply.!!!!

regds, Yogesh Joshi

I believe there are two reasons why CAD systems are starting to look more alike:

1.) "Convergence". In naturalist terms, this means that similar problems will evolve similar solutions. All CAD programs are addressing the same basic problem, so it is natural for them to evolve similar solutions.

2.) Calculated marketing. It is easier to convince a customer to switch to your product if the customer can immediately see similarities.

Consider also the FEA scene. Many different FEA packages use common interfaces such as FEMAP and PATRAN. This allows for common interfaces even though the underlying analysis code is drastically different.

You are welcome. I had a bit of free time and some interest in the subject. Personally, I wish the MCAD industry today would give these basic issues greater consideration beyond the simple product differentiation we see today...

We might actually get more done.

Hah!! Yeah, maybe?

Anyhow, Doug, well written!

Yogesh owes you big time!! ;^)

..

Doug D>

One arbitrary squiggle on a page is as good as the next.

Well, that is the beauty of USENET. Despite the noise, what comes around goes around. I have gotten a few pretty nice replies in my time when I needed them, so... there you go!