CoCreate User Forum  

Go Back   CoCreate User Forum > Applications > CoCreate Modeling

Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
  #16  
Old 05-22-2007, 03:57 PM
Steve Steve is offline
Registered User
 
Join Date: Mar 2003
Location: Alabama
Posts: 309
Re: OneSpace vs. SolidWorks

Marten:

Quote:
With history based modeling you have to think hard all the time, when you are creating a model. You have to think: how would this model be changed in the future, because if you don't build the model in an appropriate way, it will be harder to modify. This won't be a big problem for easy parts, but it will be a big problem with complex machines.[
Actually, your thought process should be like that of anyone who is considering the fit, form, and function of a part they are designing: "What relationships are important about this particular geometric feature?

Yes, this takes careful thought with the creation of each feature - as it should if you are a careful engineer. Not a single face exists on a part without a purpose, or you would not have put it on there. Why not capture what that purpose was?

Quote:
For example: you model a flat metal part of 500 mm long. Then you add 5 holes evenly divided, in a linear direction. Which design rules do you add here? Is the line of holes always centered to the model, or is it always on the same distance to one side? How many holes are needed? When I make the part 1000 mm long, do I still need 5 holes, or do I need more? When you are creating the part, you can't answer these questions, because you don't know how the part will change in the future.
It isn't so important how the part will change in the future, but rather, what is the current design intent.

If your design intent is to have 5 holes evenly divided along the length of the part, you parametrically establish that sort of pattern so that no matter how the part length changes, you will always have 5 holes evenly divded in that linear direction.

If your design intent is that the holes need to be centered to the model, then you establish that relationship.

If your design intent is that the holes need to be on the same distance to one side, then you establish that relationship.

If you don't know how many holes are needed if the part grows in length, then you have an engineering problem, not a CAD problem. Once you have determined the engineering requirement, then you can set up your model so that when the part is, say, less than 1000mm long you have 5 holes, and if it is over 1000mm you get 6. Or you can even set up a relationship to drive the hole array to achieve a certain "negative area" - the amount of open area the holes are required to provide based on the number of holes present and their size.

If you can't answer these questions at any particular time in the design - NO PROBLEM - you don't HAVE TO. Many parametric, history-based software packages such as Solid Edge, Solid Works, and others don't require the constraining of sketch geometry in any way. The point here is not that you have to create design relationships in your geometry, the point is that you can. I tend to lock things down just as soon as I am able. Why? Because I can forget about them from then on and they will take care of themselves.

Quote:
How these holes are positioned, and how many you need depend on how you are going to modify it.
Absolutely, 100% incorrect. How these holes are positioned, and how many you need depends on engineering requirements, and is completely unrelated to the CAD software. The point here is that once you have defined the engineering requirements, parametric software allows you to capture those requirements.

Quote:
Where is your 'advantage' of the history in the model? It did take more time to add the rules, and now you even have to dig into the models history to find out how you can modify to get what you want.
Well, the way I see it, it's the "pay me once now or pay me forever" problem. You can either take the time to codify the engineering requirements once such that the geometry flexes while obeying those requirements, or you, and every future designer can manually maintain those relationships with every model change forevermore.

Quote:
But you aren't finished yet. After you have modified the model, you have to check if other parts didn't modify in an unexpected way. The part that is bolted to this model, did it stretch when you stretched the model, or did it move, or didn't it get changed in any way while it should?
Certainly it is true that if the engineering requirements were not correctly codified in the model it will not flex properly automatically. Of course it is also true that without the ability to capture engineering requirements at all your model will never flex properly automatically.

Quote:
All this burden is even more restricting when you are designing completely new machines, where you don't exactly know how it will look and function. You will likely change a lot during the design process, and you constantly need to think about the design-rules, even if you don't know (yet) what they are. And because it is a history based modeler, you have to invest the time.
As I said above, many parametric modelers today do not require creating design rules. In this regard they will function much like CoCreate - you just leave off the parameters. Yes, the history aspect of the model means that some features may be dependent on previous features and this can be annoying during editing of the model. The good news is you can generally re-order features fairly easily.

Quote:
Now another example. You created an assembly a while ago, and now need to create something similar, but nonetheless different. If you use this model in a history based system, you also 'inherit' the design-rules a.k.a. history. For this new assembly, these design-rules probably don't apply, but you still have to study them and modify them in order to modify to model the way you like.
Yes, this is true, and logical. If new design requirements are in play, then the geometry will need to be modified to obey the new requirements.

Quote:
n your post, you have the example of the cylinder where a taper is applied to. In order to modify the diameter in the history-based system, you have to know how the model was created, or you have to study the history to find out. Is the conical face created by a taper, or is it created by revolving a cross-section?
No you don't. You just double click on the geometry right on the screen, and the appropriate dimensions light up right there for you to edit. You can instantly see whether you are dealing with a taper or a revolved section, and, either way, directly edit the taper angle or the underlying untapered feature.

Quote:
In OneSpaceDesigner you need a few commands to do this. The offset-command can be enhanced in order to make this easier, but you definitely don't need to do trigonometry accomplish it. (You can un-taper, change diameter, re-taper or you can draw the new diameter on a workplane and offset the face while using measure to determine the distance.) It's not as hard as you pretend.
It is exactly as hard as I "pretend". If you want to change the basic diameter of a tapered cylinder in CoCreate you have two options: Untaper the cylinder, change the cylinder diameter, and then taper it back, or do trigonometry to determine the normal offset. Drawing a circle on a workplane normal to the cylinder axis will not help you because measuring the distance from the conical base to the circle will not give you the normal offset required to hit that circle. Deleting the taper (untapering the cylinder) and reapplying it is not as efficient as simply directly editing the underlying basic diameter, not to mention all the drafting havoc you create for dimensions and such that were tied to the taper.

And the heck of it is, this is a trivial example of the problem. Try modeling up injection-molded or cast parts of any complexity at all and then have a need to go back and modify the underlying basic cavity sizes that have all been lost under drafts and blends and you will find yourself pulling your hair out. I know from experience.

Quote:
A history-based system tells you precisely what feature is failing down the history-path. The versions of SolidWorks I used didn't tell you why that particular feature failed either.
I've never used SolidWorks, so I can't speak to it. But in both Pro/Engineer and Solid Edge, when a feature fails, it usually provides some diagnostic information as to what is causing it to fail. At the very least, though, even if you want to follow the hack-and-slash method of deleting problem features rather than fixing them, like you have to do in OneSpace Designer, at least you know which features to delete.

(continued)
Reply With Quote
  #17  
Old 05-22-2007, 03:58 PM
Steve Steve is offline
Registered User
 
Join Date: Mar 2003
Location: Alabama
Posts: 309
Re: OneSpace vs. SolidWorks

(continued)


Quote:
The only feature which will fail is the 'feature' (=face(s)) you are working on.
I have not found this to be the case. Often when attempting to edit existing drafts or tapers, especially on heavily drafted and tapered parts, such as with cast or molded parts, the system is simply unable to compute a solution. Often it is not the faces you are working with that are causing the problem, it is neighboring geometry that is affected. But the software provides no clue as to what or where the problem area is. Eventually you get an eye for complicated intersections of surfaces on the model and you figure out what you need to cut away from the model in order to edit it, but what a depressing way to model. Basically you get to delete faces until the geometry is simplified enough to make your intended change, and then you get to recreate what you deleted to get it back in its previous state.

Yes, sometimes you have to do this in a history-based system, also, but at least you know which ones to delete.

Quote:
The fact that the software has got a history isn't the reason why the software can or cannot tell the user why a feature creation/modification fails.
The history tree is precisely how the software can tell the user what feature(s) have failed, and the lack of a history tree is precisely why boolean modelers have no clue as to what is failing - they only know there is a mathematical error in attempting to describe the geometry as a whole.

Quote:
With a history-based modeler, you are more of a programmer than an engineer.
I agree with this, but see this as a benefit. It makes engineers think about and document the engineering requirements of the geometry, which is a good thing.

Steve
Reply With Quote
  #18  
Old 05-22-2007, 04:00 PM
Steve Steve is offline
Registered User
 
Join Date: Mar 2003
Location: Alabama
Posts: 309
Re: OneSpace vs. SolidWorks

John:

Quote:
I think it is important to point out that OneSpace Modeling does provide the option of adding some design intent or more "intelligence" to 3D models. You do not have to define your design intent, but you can.

The optional Parametrics module can be used to define relationships between elements (faces, edges, etc.) within a part. For example you can specify that a hole should be a certain distance from a face and that relationship will be maintained as you modify the part. You can move the hole relative to the face by editing the relation.
The parametrics module in OneSpace Designer is so weak that you are limited in the parameters you can apply. The tapered cylinder example is a classic, trivial example of the shortcoming. If you have relatively primitive geometry, with lots of planar faces and edges for applying parameters to, then you may have some success with them. But if your parts are drafted and radiused, the theoretical intersections you would like to dimension to don't exist as far as the modeler is concerned, and you can't apply parameters to control them.

Not only this, but the parametrics in OSD are pretty much an all-or-nothing proposition. Unlike feature-based modelers, where you can simply click on a feature and the relevant parameters will light up on-demand, with OSD they are always visible. Yes, there is a browser window you can use to turn off and on individual parameters but unless you have given meaningful descriptions to each parameter it is difficult to tell in the browser which parameters go with which feature(s) on the model.

I found the parametrics so cumbersome to use that I, a parametric freak, gave up using them in OSD.

Ron:

Quote:
I find it very interesting that these folks, with their background and understanding of history and parametrics based MCAD system, chose to create essentiallly another "dynamic modeling" MCAD system.
I'm not surprised at all, especially after watching their webcast debut. Basically their market studies have indicated that 4/5 of potential CAD users can't figure out how to use embedded logic in 3D models. So they are going after that segment of the market with a less sophisticated, easier to understand CAD tool. There's no doubt or argument that Boolean CAD tools are simpler to use than parametric ones. It's a question of power. My guess is that companies like CoCreate and SpaceClaim have found that the power-user market segment is effectively saturated. So they're going after the users who don't presently want, need, or understand how to embed logic into their designs. Unfortunately, eventually you reach the point where you do want to embed logic into your design, just like they did back in, oh, 1992 or so, and you find the limitation of Boolean CAD software.

Steve
Reply With Quote
  #19  
Old 06-03-2007, 06:22 AM
Marten Marten is offline
Registered User
 
Join Date: Feb 2006
Location: Tilburg, The Netherlands
Posts: 139
Re: OneSpace vs. SolidWorks

Well, the post just keep getting longer:-) But hey, it keeps you busy.


You make it sound like dynamic modelers are designed stupidly, and are only for the engineering underclass. Well, I certainly don't agree with that. Both history based systems, and dynamic systems have their advantages/disadvantages (don't know why you call it boolean. It's definitely not just on/off). You just can't say one is a better technique, and the other is just for the stupid users. In some situations history based can be useful, and in others dynamic is.
I do think dynamic systems are more productive and faster for most mechanical cad areas.


If you look at One Space, it to has some history added where it makes sense. Blends for example are history features. When you modify the geometry, it will temporarily remove the history, and then re-apply it. Even your taper-example can be added while keeping the history. (I looked at it further, and found you can add a taper as a feature. Then, you can suppress the taper, modify the cylinder-diameter, and re-enable the taper).
But all those history / features never become a burden. If you modify the geometry in a way which breaks the history, it will simply be removed. You don't get an error telling you this feature can't be created anymore.


Quote:
As I said above, many parametric modelers today do not require creating design rules.

Maybe you can show me how, but I have never seen this in a history based modeler. If you have a model without constraints, you cannot change it without constraining it. I have never seen it without having to manually remove the constraints/history (which you won't do, because it takes extra time). In my opinion, it is fair to say that, in history based modelers, you are required to have history. It is not an option, or a choice.


About the design intent.
With the history based approach, you don't just capture design intent. You capture how the model is created. With that, you sure can add design intent, but that is definitely not the only thing you add. History based is not the same thing as parametric! One Space has a parametric module, but in my opinion, it's just there to be able to say it's there. But when it has a nice implementation, I would still only use it in special cases.


Quote:
It isn't so important how the part will change in the future, but rather, what is the current design intent.

Well, the current design intent is the model. If you want to document your design intent/choices, you should just document them (and only the relevant ones).
If you enforce all your design choices, you make it important how the part will change in the future. If you change your model, it means that your design intent has changed. So your enforced design intent probably doesn't apply any more. As soon as you change your design, the engineer that changes the design is responsible for the new design. And remember, in a history-based system, you have to add the enforced constraints. So, when you don't care about how the part can be changed in the future (for example, because your part will be manufactured only once and you don't want or have the time to think about how your part should be changed in the future), you will end up with a model which will most likely have wrongly defined constraints. Because you have to create those constraints, you will end up with a model which behaves unexpectedly when changed, and is harder to change, because you have to find out how it is created. Adding “good” parametrics (as far as that's possible) takes a lot of time. Not everyone can invest that much time in a model. It's not: if your smart enough, you would add them. You should also take time into account. If time wasn't a problem, you would also always calculate the minimum material required to meet the strength requirements. However, not everybody has the time to do it. It's sometimes much faster and cheaper to just over-dimension.


Another problem with your statements about design intent and engineering requirements is, that many cad users often only have functional requirements for the machine/product they are designing. So, because the end-product isn't completely clear yet, those engineering requirements are not defined completely. Many of the engineering choices change very often during such design process. During this design process, it would constantly take a lot of time to put all the possible constraints into place, and then, when you think: “Oh, I can do it better this way”, those constraints make it harder to change your design.
Yes, it would be nice to be able to add some of your design choices into your model as constraints, but only when it can be done after you completed your design or part of your design, and when it's easy to remove all of them (and still be able to modify your model).


Quote:
Not a single face exists on a part without a purpose, or you would not have put it on there
Well, of course, but many of those reasons/choices are trivial, so why capture those? It takes time to put them there, and it takes time to modify them when your design changes. And because they are obvious, it is a waste of time imho.


Again, this discussion about adding design intent has nothing to do with being a history based or a dynamic modeler. It is just about being able to add parametrics to your model. History based systems by definition allow (and even require) you to add parametrics, but that doesn't mean that you have to be history based to be able to add them to. CoCreate could add good parametric abilities in Designer, but you have to see this as an extra feature which can be added to the software. It's not that high on my list of enhancement requests btw.
One thing that's absolutely clear to me, is that it should be optional to add those parameters.

Then there is the discussion about history based vs dynamic.

I think history based approach can have some advantages. In some cases it allows you to easily change your model where, with dynamic modeling, it's easier to just rebuild (part of) the model. I believe you are in the business creating plastics moulds or something? I can imagine that history based can have advantages, because you constantly work with those tapered faces. I think that when you work with not that many parts, and have complex parts (to create), and where the design is pretty stable (ie. won't change that much), it can be useful to have a history. However, if you are working with many parts or change your design frequently, or where most parts are fairly simple (and thus easy to manufacture; where the complexity is in the combination of these simple parts) I think dynamic modeling has many advantages. The few cases where history would help to easily modify? Well, to bad. Not that big of a deal. I think this is true for a very big part of the industry which manufactures machines.

Tapered cylinder

One last remark about the tapered cylinder:
Yes, you can measure the distance. Because measuring the distance from the conical face to the circle will give you the normal offset required. The normal is the shortest distance to the circle, and that's exactly what's measured when measuring the distance between the conical face and the circle. Also, if you un-taper, modify and re-taper, you will not mess with dimensions in annotation when you just modify the face. You will only get problems in annotation when you remove the face (for example with mill) and then recreate the taper.
But hey, CoCreate did listen to you and created a taper-feature. It would be nice if they also created a “suppress taper” command in the right-mouse menu in the structure browser, but that will be easy to create in lisp if they don't.


I'm curious what you think about this little bit of history in OSD

With kind regards,


Marten Verhoeven
Reply With Quote
  #20  
Old 06-04-2007, 02:09 PM
phamil1 phamil1 is offline
Registered User
 
Join Date: Aug 2005
Location: Fort Collins, CO
Posts: 46
Re: OneSpace vs. SolidWorks

This is such a fun topic; I can’t resist making this post even longer. J

There are many terms flying around here that I think are being abused. How about a little history (no pun intended) lesson on 3D modeling? It all started ….. now I am going to show my age ( And I know there are others out there that are as old as me that can correct my mistakes here.)

Back when 3D CAD first came into existence, there were several basic technologies that were used.
  • Octree - a tree data structure in which each internal node has up to eight children. Octrees are most often used to partition a three dimensional space by recursively subdividing it into eight octants
  • Faceted – models are made up of straight lines and flat surfaces. Facets can be refined to improve accuracy of the model.
  • Constructive Solid Geometry (CSG) - constructive solid geometry allows a modeler to create a complex surface or object by using Boolean operators to combine objects. Often CSG presents a model or surface that appears visually complex, but is actually little more than cleverly combined or de-combined objects.
  • Boundary Representation (B-Rep) - a method for representing shapes using the limits. A solid is represented as a collection of connected surface elements, the boundary between solid and non-solid.
Most 3D CAD systems today are still based on these same technologies. Facet modeling is very common and use in 3D graphics for many systems that require less accurate models, such as 3D games and entertainment, geography related applications and imaging systems. You will no longer find facet geometry engines in today’s mechanical CAD systems. The accuracy is just not high enough. However all mechanical CAD systems do use faceted representations of the geometry for viewing the model.

CSG, in it purest form is no longer used in mechanical CAD. The last systems to use this technology was I-deas from SDRC and Catia. The issue with pure CSG was the low accuracy of the primitives and the limited set of primitives. Models were constructed by applying these primitives to the model with 1 of 3 Boolean operators: union, intersection and difference. There is one very important component of CSG, however, that is still in use today and that is the “structure” or “tree” of primitives and Boolean operations. The basis of today’s “history trees”.

B-Rep is by far the most accurate technology for representing 3D geometry, and is used in all modern CAD systems today. It was first used commercially in a geometry kernel called Romulus. The Romulus geometry kernel was used in several 3D modeling systems in the 70’s and 80’s: Anvil, Graphtec, ME30, Unigraphics and a few others. Many of the people that helped develop Romulus came together again to develop ACIS. This geometry kernel is in wide-spread use in many of today’s modern 3D systems. Romulus was also the forerunner to Parasolid. Another geometry kernel that is in wide-spread use today. In the early days, B-Rep modeling gave us accuracy, but developing and modify models was very difficult. Many time we resorted to creating primitives and performing Booleans on the model just to make a simple change. This was termed “explicit modeling”, and was somewhat painful and time consuming.

So where does “history” and “non-history” fit into all of this? Well both are based on technologies above.

History-based modeling.
  • The most common technology used in today’s CAD systems
  • Often, and incorrectly referred to as parametric modeling
  • Should be referred to as hybrid modeling
  • The steps/operations that are used to create the model are captured in a structured tree (CSG)
  • Structure tree implies a parent child relationship. All modeling steps must be recorded and related.
  • Modeling steps are based on a 2D sketch or a 3D feature and may add or remove material from the solid model
  • Sketches, parent/child relationships, geometry relationships and constraints are remembered and tracked in history to allow for modification
  • Interaction with the model is on the structure level, not geometry level
  • Hybrid: CSG with B-Rep Booleans
  • Facets are used for display
Non-history-based modeling
  • The most common technology used in the early days of CAD.
  • Emerging today in a new and dynamic form
  • Often referred to as: Explicit modeling, direct modeling, dynamic modeling, constraint free modeling
  • Interaction with the model is on the geometry level
  • B-Rep Booleans
  • Facets are used for display
So:
  • Both are Boolean based
  • Both are B-rep
  • Both can be “parametric”.
    • “histoy based” still provides the simplest method of applying intelligence to the model, although this is quickly changing. I think this is where SpaceClaim is headed. Whoever figures out how to quickly, and easily add intelligence to 3D, without the dreaded parent/child issues is going to win big in the future of CAD.
  • The only significant difference is that “history based” has the parent/child (CSG) relationship, (very old technology – by the way). And, this is NOT optional in history-based modeling ... and not available in "non-history-based"
So What?

Well, you just have to decide what is best for you. I am familiar with one company that is a leader in innovation in their industry and they don’t use CAD, except to finally document what the designers design. It’s fascinating and reminds me of the good old days. I personally think we waist way too much time messing with our CAD systems rather than designing and inventing stuff. This seems to be especially true with history-based modeling users. It’s like a kid with a Rubik’s Cube. For pity sakes, peal the stickers off and move on.
__________________
Paul Hamilton
Technical Sales Manager (PTC)
http://p-hamilton.blogspot.com
Reply With Quote
  #21  
Old 06-05-2007, 10:30 AM
John Scheffel's Avatar
John Scheffel John Scheffel is offline
Administrator
 
Join Date: Sep 2002
Location: San Jose, CA
Posts: 1,288
Re: OneSpace vs. SolidWorks

Very nice informative post Paul.

It reminded me of when we first started using CATIA at IBM. The beginner training we received did not include any details on the underlying CSG tree and how to properly manage it. The result was what we started calling the "CSG vine". If you looked at the CSG tree for most of the models that new users created, it was basically one long branch of sequential one at a time operations. This made future modifications difficult. As I learned more about CATIA and how you should use it to create a proper CSG tree, I remember thinking that it was unfortunate that designers had to think about what CATIA was doing under the covers in order to use it effectively. When I moved to HP and started learning an early version of SolidDesigner, it was a pleasant surprise to discover that I no longer had to worry about the CSG tree.
__________________
John Scheffel
Reply With Quote
  #22  
Old 06-06-2007, 07:15 AM
phamil1 phamil1 is offline
Registered User
 
Join Date: Aug 2005
Location: Fort Collins, CO
Posts: 46
Re: OneSpace vs. SolidWorks

Thanks John.

I received a few questions about which modelers fit where. I think this is close, unless things have changed recently:

Hybrid Modelers:
ProEngineer, SolidWorks, Solidedge, NX, UGS, Caita, IronCAD, Inventor, Alibre, … and a lot of others
B-Rep Modelers:
OneSpace Modeling, SpaceClaim, Kubotek
__________________
Paul Hamilton
Technical Sales Manager (PTC)
http://p-hamilton.blogspot.com
Reply With Quote
  #23  
Old 06-07-2007, 03:53 PM
folini's Avatar
folini folini is offline
Registered User
 
Join Date: Jun 2007
Location: San Francisco, CA
Posts: 2
Post Re: OneSpace vs. SolidWorks

Thank you Ron Keeley for quoting my blog (about SpaceClaim).

In order to understand better how SpaceClaim is different from traditional parametric-feature-based system I invited Howie Markson of SpaceClaim for an interview. I asked very specific questions trying to get as much info as i could from him. I think the interview can help to better understand this new product and the company strategy.

Anyway, if you are interested, the complete interview is available on (my) Novedge blog.

Franco Folini
Reply With Quote
  #24  
Old 06-07-2007, 11:26 PM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: OneSpace vs. SolidWorks

When reading their blog, just keep in mind that Novedge is a software reseller/distributor who does not sell CoCreate products, but products for several other competitive CAD markets - at least as far as I can tell (correct me if I'm wrong).

Claus
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #25  
Old 06-11-2007, 09:49 AM
folini's Avatar
folini folini is offline
Registered User
 
Join Date: Jun 2007
Location: San Francisco, CA
Posts: 2
Post Re: OneSpace vs. SolidWorks

Claus,
thank you for your note, you are right about Novedge.
I would like to add that we do NOT sell SpaceClaim, SolidWorks and CoCreate. IMHO this put us in a "almost" neutral position when talking (or writing) about those CAD systems.

Franco

Last edited by folini; 06-11-2007 at 09:50 AM. Reason: fix
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 11:06 AM.



Hosted by SureServer    Forums   Modeling FAQ   Macro Site   Vendor/Contractors   Software Resellers   CoCreate   Gallery   Home   Board Members   Regional User Groups  By-Laws  

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.