[cad-linux] Re: CAD with server/client architecture
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Tue, 13 May 2003 11:28:10 -0500
> The following was supposedly scribed by
> Vishal A. Belsare
> on Tuesday 13 May 2003 07:42 am:
>I do believe that it would help to take the idea to programmers on other
>lists, who specialize in graphics, computational geometry, optimization.
>The software engineering way is the right way, get to drafting
>specs. formally.
>
>One might as well call in specialists of each component which *could* play a
>part in the scheme of things. Input from potential users (civil / mech /
>struct / hvac / arch engg)
>Would surely enjoy this getting to some *real activity* than discussions.
I've only got the one paper so far, but will have time to come up with some
more writing and summary of the ideas kicking around on the list in the next
couple of days. I think diagrams will help layout the plan, so I'm working
on a few of those as well.
I've been told before that achieving a universal parametric design system is
not a technical barrier, and I believe that. The barrier lies with
purchasing and planning decisions made by cad managers, architects,
engineers. The barrier is partly in the way people are used to working and
and also in the way they respond to market and other pressure. But, I
believe that a properly implemented technical solution can break down all of
the other barriers. If the benefits are overwhelming, the momentum will be
there and the course of events will follow. The same has been shown by the
progress of Linux, which has very little market strategy, but is taking over
on technical merit.
>Our / my main
>goal ---> create a AEC package that can be altered, added to, and refined by
>Architects.
I think the bulk of contribution in this area will be architects providing
incentive for changes and additions to the system. With open source, you pay
with code or money. Both get the job done. Providing a scripting or macro
interface would likely be the most accessible by architects, but their
ability to hire someone to implement their idea is a strong argument for use
of an open source system.
>You cannot talk about core extensibility of the functionality of any
>software if the intial representation is a rigid & monolithic.
The "toolbox" approach would be one of the technical benefits with this
system. The design of the core should be flexible enough to allow multiple
programs (with different data requirements) to connect to it and work
together.
>10. an open-source file format (like IFC) and an open source AEC package
>would help the AEC industry as a whole, and that many people would be
>willing to use it.
Yes, but an open-source, universal engineering database system would have
benefits above and beyond those provided by a standard file format (such as
preventing the format from being subverted by closed-source extensions.)
>Stimulus : IMO (today), spatial visualization is best accomplished with
>SketchUp or a sign pen on trace.
>Response : Conceptual or schematic design are just starting points for such
>software Robert. The scope is far more that this. Of course, I agree with
>you that getting a workable 2D CAD system is of immediate concern,...
>An *extensible* representation system which can capture more enriched data
>sets at a later point in time should be a good step.
I think the toolbox approach would allow conceptual sketches to be refined and
used as reference points for more complex software. Use the best tool for
each task: 2D cad for sketching and roughing-out footprints, "artistic" mesh
modelers for spacial conceptualization, and fully parametric systems for
engineering, analysis, and fabrication. A drafting program would not need to
be aware of the rest of the system in order to implement a sketcher (though
it could be helped by some awareness, it is still just for drawing.) Layout
of construction documents and detailing would be facilitated by a link from
the parametric world back to the sheet of paper, but this is really nothing
more than a snapshot of the model (associative dimensions are good, but are
not currently used because of the difficulty of maintaining them in a
parametric development process.)
>If only the representation of information be kept flexible, extensible, most
>goals should be achievable with efforts pouring from domain experts of all
>fields related. f.e if our representation mechanism represents material
>properties alongwith geometry, it becomes possible to use that data in an
>integrated manner with a thermal performance or structural analysis module.
I think modularity of the database would be key to implementing this,
especially when you have multiple disciplines working in multiple offices.
Locking, permissions, and revision control would be among the benefits
provided by this system which would give incentive to move to/program for it.
--Eric
Other related posts:
