[cad-linux] Re: Some comments
- From: Kim Lux <lux@xxxxxxxxxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: 17 Jan 2003 08:04:24 -0700
Comments below. I have not read through all the posts yet.
Kim
On Fri, 2003-01-17 at 01:22, Andrew Lowe wrote:
> Hi people,
> Some comments after reading through the latest batch of
> posts:
>
> 2D Vs 3D
> Don't even consider doing 2D if you want a decent "general
> purpose" CAD package. If you have a 3D code base, it is very easy
> to include functionality that will lock one of the axis to 0.0 so that it
> "looks", ie you can't rotate around all three axes, 2D. You can't do
> the reverse if you only have a 2D code base.
I agree with what is being said here. Unfortunately, I think that
eliminates half the code from our list of candidates. Some of the
candidates were started as "my own better 2D drafting package" and are
not extensible to doing anything in 3D. I think that QCad is the most
obvious example of this, but I would have to look at it to be sure.
> Text Vs binary
> There is no problem with using binary IF THE FILE
> FORMAT IS PUBLISHED. Yes you are correct in that you can't edit a
> binary file in a text editor, you use a hex editor for that, but to a CAD
> manager the concept of some drongo firing up Vi/Emacs/Nano/Pico
> to "fix a problem with a drawing", is just about enough to induce a
> heart attack.
But yet doing so in a text file is possible. I've done a lot of system
design and ANYTHING that speeds debugging and development is a good
thing: asserts, log files, text based storage files, etc. If we built
on a binary file, we'd have to build a reader/troubleshooter for it. I
guess you don't "have to", but as soon as a user gets a "I can't read
this file error" someone has to produce a tool to debug it.
> A point that must be considered when choosing a file format
> is if the system will be memory based, like AutoCAD, or file based,
> like MicroStation. If it is file based, then the only option is to use
> binary, it is much faster.
The only option ? Why so ?
>
> MySQL
> Use a database interface such as ODBC/JDBC so that the
> user can decide what database they want to use. I don't think it is up
> to "us" to decide if the user is going to use
> MySQL/Oracle/Postgres/Interbase/Firebird/.../..../, use an interface
> and the user can decide
There are interfaces more modern that ODBC. I think that Postgres and
MySQL both have SQL interfaces. Do we really want to use a database to
store the data ? My thought is no because it isn't going to be easily
exportable to other processes. For example, some of us want to have CAM
functionality. For such it would be nice if the format was compatible
with other drawing packages so that we can start on the CAM stuff while
the CAD part is still being worked on.
> Vector Vs Object
> You need both of these. You can't draw objects without
> vectors.....oh bugga, I had something deep and meaningful for this
> bit but I just forgot it :(
I don't have any experience in this area.
> Cascade
> Open Cascade is a set of libraries, not an appliation. You
> have to build all of the menu, mouse, layers etc etc yourself. A lot of
> the stuff needed for a CAD system is there, but you need a lot more
> for UI
That is a good thing in my mind. Actually, that is pretty much exactly
what we are looking for as far as I can tell. Is it 3D ?
> VRML
> It is NOT suitable to use as a file format for a CAD system.
> Forget you ever heard of it in this context
I'm glad we have your expertise in the group.
>
> Regards,
> Andrew Lowe
--
Kim Lux <lux@xxxxxxxxxxxxxxxxxxx>
Other related posts:
