On May 8, 4:21 am, jon_banquer <jon_banq...@[EMAIL PROTECTED]
> wrote:
> http://www.x3dmedia.com/
>
> "Synchronous Technology: part II
>
> posted by al dean
>
> I've been plugging through everything I've learned so far about
> Synchronous Technology, so here it is. The essential difference
> between Synchronous Technology and other systems out there that many
> are comparing it with (let's be frank, that's SpaceClaim, CoCreate and
> to a much less extent, IronCAD), is not so much the ability to
> interact directly with geometry, but rather the manner in which you
> add intelligence to your 3D product model.
>
> When we design a product, we have two things in mind. What it looks
> like, whether in terms of aesthetic quality, but also that it need to
> fit and provide a certain function, and that's often governed by form
> - after all, parts need to interact with those around them. But
> alongside this, you also need to be able to specify how a product is
> formed. Rough dimensions don't cut it, you need to be able to tie
> information down, lock it out and ensure that the geometry you create
> fulfills a need, for function and performance.
>
> In traditional history based systems, the latter part is much easier,
> as you are defining geometry from a very root level, which captures
> your design intent - but only just. the fact that you often have to
> add excessive dimensions and constraints at a feature/sketch level,
> means that the process is counter intuitive. In other words, history-
> based modeling is too over burdened.
>
> What it DOES give you is the ability to add a lot of intelligence, so
> design change can be automated, dimensions and constraints interlinks
> between sketches, features, parts and sub-assemblies. But the end
> result is a dataset that's horrendously complex and effecting even a
> small change can result in a parametric nightmare that take herculean
> effort to resolve - and in many cases, user remodel from scratch just
> to avoid it.
>
> Direct Editing applications (such as CoCreate and SpaceClaim), work
> from the other end, where you play with the geometry and the
> constraints you apply (be they dynamically input, or more commonly,
> just a case of drag and drop geometry) are not maintained and stored.
> So, you can add dimensions if you need to, but they can't be
> maintained and commonly accessed at a later date.
>
> What Siemens has done is develop an architecture in which you can mix
> and match both. you can play with geometry to get it into shape, to
> ensure that the rough state of your model is how you want it. you can
> make changes very quickly indeed, by using inferred relation****ps,
> dynamic detection of 'informal' topology relation****ps - such as
> concentricity, parallelism, perpendicularity. this just enables to you
> edit the geometry and topology very quickly. But the trick is that
> when time comes to lock down feature size, dimensions, constraints,
> you can do is, just as you do already BUT, you can maintain them.
> Dimensions remain consistent, are stored and accessible, features are
> maintained, in respect to the dimensions, rules, constraints you
> provide.
>
> But
>
> They are applied after the geometry has been built - and this is key.
> you design, then you engineer. For me, the most interesting
> illustration i could find is the one shown here. its a model with
> parametric dimensions, but one that's fully constrained - but the
> difference is that the ONLY dimensions, parameters and constraint you
> create, are the im****tant ones - that, is the crux of the point and
> key to understanding what Siemens have developed.
>
> Its a complex thought process to figure this out, with over 20 years
> of parametric, history-based modeling that the majority of us are
> familiar with and it'll take time to settle and learn more."
>
> Jon Banquer
> San Diego, CA
Cool! Did you sign your PO for it yet?
|
