Why the debate about software, as opposed to file type?

Hi, I'm new around here. I'm just curious about the discussion taking place with regard to what modelling software to use with RepRap. From what I understand STL files are not ideal because they're relatively dumb objects and that using a native file of some app, such as AoL, provides some advantage when printing 3D objects. Am I on the right path? If so, what exactly is the advantage, in terms of outcomes?

And why is it a discussion about application alternatives rather than file type alternatives? Are there no suitable alternative file types?

What about IFC (Industry Foundation Classes) files? Does anyone know much about these and their suitably or not with regard to the RepRap project?

Edit: corrected name of IFC files

Edited 2 time(s). Last edit at 07/06/2008 06:51PM by Christiaan.

Christiaan Wrote:
-------------------------------------------------------
> And why is it a discussion about application
> alternatives rather than file type alternatives?
> Are there no suitable alternative file types?

Not really. At least not really that are common to a lot of both open source and commercial modeling apps.

The advantage of lots of people using the same open source software for RepRapping is that it's easier for us to share designs with each-other and for objects to evolve as people find ways to improve them. Each CAD software has its own native file format (am I right here?), so in order to share and edit files most efficiently, it would be nice if we all huddled around a single piece of software. That said, everyone is free to use whichever software they use, and can publish the results in STL format. The only downside to this is it's a little more difficult for others to edit and improve the design.

Andromodon Wrote:
-------------------------------------------------------
> The advantage of lots of people using the same
> open source software for RepRapping is that it's
> easier for us to share designs with each-other and
> for objects to evolve as people find ways to
> improve them.

But it's not the software that's providing this advantage, it's the common file type. This is fundamentally a problem of file type, not modelling software.

The use of AoL seems to me to be a solution to the immediate problem that there appears to be no suitable cross platform file type, which is fine in the short term but in the long term the much better solution would surely be a common file type independent of any particular end-user software.

What if a much easier to use 3D app comes along but is incompatible with AoL? You'll have a lot of inertia behind AoL and it will be difficult to change programs. This will slow innovation and tie people to inferior end-user software.

Furthermore there's already people out there (amateurs, semi-pros and pros) who use other programs. Asking them to learn another program is also a barrier to entry.


> Each CAD software has its own
> native file format (am I right here?), so in order
> to share and edit files most efficiently, it would
> be nice if we all huddled around a single piece of
> software.

Yes and no. Yes, but there is a new file type called IFC, as mentioned above, which is focussed on interoperability in the building industry, with regard to Building Information Modelling (BIM). Check it out:
[en.wikipedia.org]

Now, I don't know enough to know if this file type is technically suitable, but I'm sure there are people here who could tell us.

And if it is technically suitable, or if some other file type is found to be technically suitable, then one possible solution might be to push for AoL to support this file type (even in a limited way). If that can be achieved then a bunch of barriers to entry can be dismantled, and without throwing away AoL or some other app as the current solution to the immediate problem.

> That said, everyone is free to use
> whichever software they use, and can publish the
> results in STL format. The only downside to this
> is it's a little more difficult for others to edit
> and improve the design.

Well, as evidenced by the solution (get everyone to use the same software), this is no small downside.

When I see a consistent misspelling of the acronym for Art of Illusion, viz, AOL, I am left to wonder if many of the worthies posting to the tsunami of criticism of AoI have even a minimal acquaintance with it.

Christiaan Wrote:
-------------------------------------------------------
> ...It's not the software that's providing this
> advantage, it's the common file type.

You're absolutely right. A common file format would be ideal. If a common file format can be achieved that saves all of useful data, I'm all for it.


> What if a much easier to use 3D app comes along
> but is incompatible with AoL?

Since both pieces of software are open source, and each of the file formats are openly documented, someone would write a program to convert from one file type to another. This could be run in batch (bash script, anyone? ) on the entire library of parts, and voila, we could shift our momentum behind that newer, better software.

> Furthermore there's already people out there
> (amateurs, semi-pros and pros) who use other
> programs. Asking them to learn another program is
> also a barrier to entry.

Barriers to entry are bad, but it's been my experience that once you learn one of a genre of programs (i.e. web browser), it's easy to learn others of the genre. Sure, menus may be in a slightly different spot, but if both programs operate with the same basic structure, the transition should be smooth.

> And if it is technically suitable, or if some
> other file type is found to be technically
> suitable, then one possible solution might be to
> push for AoL to support this file type (even in a
> limited way).

Sounds good.

> Well, as evidenced by the solution (get everyone
> to use the same software), this is no small
> downside.

I think the RepRap community can give (and is currently giving) people the freedom to use whatever CAD program they wish while simultaneously suggesting the use of one program. In this way, liberty is preserved, and the community can still aptly share the experience and knowledge gained using CAD program x to model RepRapable 3D parts.

All in all, I think we're mostly in agreement. Thanks for your posts!

Christiaan Wrote:
-------------------------------------------------------
> What about IFC (Industry Foundation Classes)
> files? Does anyone know much about these and their
> suitably or not with regard to the RepRap
> project?

Judging from the description found on Wikipedia and the list of applications that support it, I can say that IFC will almost certainly not work for our purposes. There are several of those that I know for a fact have no 3D capability at all.

Out of formats currently in use, the only open one I'm aware of that even comes close to our needs is STEP, but I'm led to understand that it's a rather cumbersome standard.

Forrest Higgs Wrote:
-------------------------------------------------------
> When I see a consistent misspelling of the acronym
> for Art of Illusion, viz, AOL, I am left to wonder
> if many of the worthies posting to the tsunami of
> criticism of AoI have even a minimal acquaintance
> with it.

I don't have any acquaintance with AoI (sorry for the misspelling), and nor do I need to to make the argument I'm making. If you take another look at what I've written you'll see that I don't, in fact, criticise AoI.

Edited 3 time(s). Last edit at 07/08/2008 03:22AM by Christiaan.

Kyle Corbitt Wrote:
-------------------------------------------------------
> Christiaan Wrote:
> --------------------------------------------------
> -----
> > What about IFC (Industry Foundation Classes)
> > files? Does anyone know much about these and
> their
> > suitably or not with regard to the RepRap
> > project?
>
> Judging from the description found on Wikipedia
> and the list of applications that support it, I
> can say that IFC will almost certainly not work
> for our purposes. There are several of those that
> I know for a fact have no 3D capability at all.
>
> Out of formats currently in use, the only open one
> I'm aware of that even comes close to our needs is
> STEP, but I'm led to understand that it's a rather
> cumbersome standard.

Yes, the focus of IFC is information as I understand it, rather than detailed 3D representation. However, I just don't know.

This might also be of interest, which points out that several of the resource definitions have been adapted from the STEP standard:
[www.aecbytes.com]

Kyle Corbitt Wrote:
> Out of formats currently in use, the only open one
> I'm aware of that even comes close to our needs is
> STEP, but I'm led to understand that it's a rather
> cumbersome standard.

Cumbersome for the end user or the developer?

Quote

Cumbersome for the end user or the developer?

Having had a quick browse through some STEP information, I'd definitely say 'the developer'. It is a pretty complex standard, even if you're only implementing a tiny part of it. It does look like an ideal sort of format, as it is pretty encompassing.

Good as it is, it requires a few fairly skilled developers to implement it, not just for reprap but for some suitable open source modelling tool as well. And I don't necessarily see that happening any time soon, not without someone unexpectedly keen popping out of the woodwork, or the donation of a significant sum of money to fund somebody's work in that direction

STL is dead simple. You can write an STL parser in your language of choice in a few hours, max. Adding sanity-checks and model-fixes and slicing in the manner of the reprap host is only a few days more... it is all simple, sensible stuff.

This is where the strength of STL lies, and why there are plenty of tools which support it.

But don't let me discourage you from writing something more powerful and expressive!

Christiaan Wrote:
-------------------------------------------------------

> This might also be of interest, which points out
> that several of the resource definitions have been
> adapted from the STEP standard:
> [www.aecbytes.com]

I read through it and didn't find any mention of any 3D at all, either explicitly or implicitly. And it wouldn't make much sense in that sort of standard anyway.


> [is STEP] cumbersome for the end user or the developer?

The developer mainly. However, I've never seen an implementation of it that gives the user the rich information about a model necessary to reverse an operation, for example. My understanding of the format (although I haven't really studied it, just played around with it a bit) is that it still describes a static solid, not the sequence of operations taken to obtain that solid. It's better than STL in that it's not rasterized, so a round hole is a round hole and not a nearly-round collection of triangles, but it's still not optimal. A hole that passes through two plates in a STEP file shows up as two holes, while it would ideally be described as a single one.

Kyle,

I know I'm starting to sound as if I have a stake in this system's success (I don't), but BRL-CAD's native format fulfills the ideal you describe, which, among many other interesting features, makes it in my opinion an ideal choice for the reprap standard. Writing converters to/from it is a straightforward and well-documented process, with examples for many existing formats (including STL) and even extremely well commented C frameworks for writing new conversion tools. To aid this is an extremely thorough set of C libraries for working with its file format, as well as a somewhat human-readable ASCII version of the native format which can be converted to and from the native binary format with no information loss. As with most C libraries, it is straightforward to wrap these for access from most existing programming languages, and if this is infeasible or undesired, manual parsing of the ASCII version of the format should be relatively trivial for most tasks. Finally, as well as supporting true CSG (objects defined by boolean operations on primitives), the BRL-CAD format has support for arbitrary plaintext metadata to be associated with individual objects, making it easy to extend for future reprap-specific data such as build material.

Ralith Wrote:
-------------------------------------------------------
> Kyle,
>
> I know I'm starting to sound as if I have a stake
> in this system's success (I don't), but BRL-CAD's
> native format fulfills the ideal you describe,
> which, among many other interesting features,
> makes it in my opinion an ideal choice for the
> reprap standard. Writing converters to/from it is
> a straightforward and well-documented process,
> with examples for many existing formats (including
> STL) and even extremely well commented C
> frameworks for writing new conversion tools. To
> aid this is an extremely thorough set of C
> libraries for working with its file format, as
> well as a somewhat human-readable ASCII version of
> the native format which can be converted to and
> from the native binary format with no information
> loss. As with most C libraries, it is
> straightforward to wrap these for access from most
> existing programming languages, and if this is
> infeasible or undesired, manual parsing of the
> ASCII version of the format should be relatively
> trivial for most tasks. Finally, as well as
> supporting true CSG (objects defined by boolean
> operations on primitives), the BRL-CAD format has
> support for arbitrary plaintext metadata to be
> associated with individual objects, making it easy
> to extend for future reprap-specific data such as
> build material.


Actually, I was reading the BRL-CAD wiki earlier today and I noticed that. That's very exciting! It will take a bit more investigation to determine whether this is an appropriate format as-is (I'm particularly interested in whether it keeps track of all the primitives/booleans used to produce the final product, or takes undesirable shortcuts), but my suspicion is that it will work just fine! And they claim to have over 30 translators already available, including an IGES one, which is awesome as well! I even see that adding a STEP translator is on their priority list, but IGES serves much the same purpose in a practical sense.

More than 30? Wow. I didn't realize they'd gone *that* far. I guess that just shows how simple their editing libs makes adding new convertors. Or maybe how dedicated their developers are. Or maybe they've just gotten really good at writing parsers?

Judging from my experiences in the tutorials, the format stores *everything*; at no point is there any simplification done, because, at least so far as I've tested, there is no point at which you can't go back and edit the original primitives that make up the parts that make up the final assembly.

Ralith Wrote:
-------------------------------------------------------
> More than 30? Wow. I didn't realize they'd gone
> *that* far. I guess that just shows how simple
> their editing libs makes adding new convertors. Or
> maybe how dedicated their developers are. Or maybe
> they've just gotten really good at writing
> parsers?
>
> Judging from my experiences in the tutorials, the
> format stores *everything*; at no point is there
> any simplification done, because, at least so far
> as I've tested, there is no point at which you
> can't go back and edit the original primitives
> that make up the parts that make up the final
> assembly.


As a completely new user, in your estimation how long does it take to get from 0 to creating boolean-derived objects following the tutorials with the current low-level interface? I'd love to give this program more of a try, but I'm a bit strapped for time in the next few weeks.

I've put in quite a bit of time with other CAD programs and use vim as my primary editor at work every day, so I've got a bit of experience with the old school as well .

As a completely new user with similar oldschool experience (this is what'll probably save you, as the editor, although it has gui bits for most things, is really meant to be controlled with textual commands), it took me about an hour's continuous work (I have to approximate here cuz I was switching to and from other stuff constantly) to make it through the extremely clear tutorials in the Introduction to MGED pdf available here [brlcad.org] . It's easy to apply the techniques you learn in tutorials one through five (altogether about 45 paper pages, mostly taken up by example images and helpful diagrams) to creating your own complex objects, and what hasn't been taught to you yet through those tutorials you can usually work out by referring to the MGED Reference Card available here [brlcad.org] . A high level of productivity will, as with most oldschool things, probably simply be a matter of accustoming yourself to the system with a couple simple projects.