aoi problem reading stl files

Hello!

I feel extremely stupid today, I have downloaded Art of illusion 2.4.1 running a Java 1.4.2 on suse 10.1 (i also tried it on a 9.3 suse)

The problem is that when I try to open for instance the clamp.stl file that I downloaded I get a message:

An error occured while reading the file:
Not in GZIP format

OK


Anyone knows what is going on????

/Erik

i've gotten the same error... i'm not entirely sure what the deal is. i remedied it by opening the file with blender. obviously not a good solution, but i just wanted to look at a part really quickly.

humm obiously I've been at this before.. I found some .aoi files in my "open recent" menus, that was much better!!

But I am a little surprised, tough .stl was _the_ format for model exchange...

I tried using 2.4.1 some months ago and gave up finally. The release seemed to be more trouble that it's worth. I've stayed with 2.3.1 in the hopes that the next release will be a bit less troublesome.

I think I know what the problem is.. If I recall correctly, the version of AoI that I was working with would also give the same error when trying to open .stl files, but if you instead *import* the .stl file, it works fine. I seem to remember also having to install a plugin to handle stl files, but I can't exactly remember.

Yup, this is a hard one to remember. Even after converting lots .stl files I still forget sometimes and try to open it. Only option for .stl is importing. You can naturally export or save in other formats as you choose. I think Adrian posted in the AOI introduction what addins you need. I may have posted recent info on how to do it relating to the cleanup we did.

Finally got it...

Just select Tools => Scripts and Plugins Manager

and make sure your internet is working (unlike mine ;-)

Then you can download the STL plugin directly from the gui.

I'm running 2.4.1 now btw!

Cheers

Hi Folks,

I think the issue you've identified here indicates a definite improvement that could be made to AOI. I'll look into teaching AOI how to use file associations to try opening files which aren't in the AOI "native" format.

Cheers!
Nik

I installed the STL translator and restarted AOI. I still get the Not in Gzip format error! Do I need to install anything else?

From the previous posts it looks like you need to import rather than open file.

---

[www.hydraraptor.blogspot.com]

Just to be clear:

In AOI, the 'File | Open' option expects only AOI scene files (xxx.aoi). If you want to read/write a file in a different format you currently need to use the 'File | Import' (for read) and 'File | Export' (for write) options.

So, to read an STL file into AOI, you need to open AOI, then select 'File | Import'. The list of available file translators will be displayed in a sub-menu. Choose 'STL', and you will be presented with a window giving you control over the STL import process.

(If STL is not one of the available formats, you need to install the STL plugin using the 'Scripts and Plugins Manager'.)

This process is similar to importing a non-SVG file into InkScape, or a non-OpenOffice file into OpenOffice.

That being said, I have already posted that I think a useful enhancement would be to enable AOI to try an appropriate translator automatically (see following post).


Cheers!
Nik

Hi All,

So, I've implemented a test version of the initial 'auto-import' logic in AOI. With this, when AOI fails to read a file as an AOI scene file, it looks at the filename suffix, and tries to find a 'registered' translator for files associated with that suffix.

It works really well too...

So, now I have an unnamed scene as the result of auto-importing an STL file, and I want to save it.

What behaviour would people prefer?

A. AOI displays a save-as dialog, and forces the file to be saved as an AOI scene;

B. AOI recognises that the file was 'imported', and prompts the user to choose the save format;

C. AOI stores the imported file name and type and automatically saves in the imported format
(With this option, the only way to save an auto-imported file as an AOI scene would be to use the Save-As dialog);

D. Other suggestions??


While you are all contemplating this, I have a further question:

Given that a user has just selected (say) an STL file in the 'File | Open' dialog, and AOI has determined that it has a translator registered for .STL files, should AOI:

A. silently import the STL file with auto-detected settings;

B. display the STL import dialog and allow the user to adjust the import settings manually;

C. other??


Cheers!
Nik.

Edited 1 time(s). Last edit at 07/13/2007 09:25AM by Nik777.

Wow! That sounds like a dramatic improvement you are planning there, Nik!

i think the best behaviour would be B, to detect it, give them the dialog with the suggested settings, and then let the user decide if they want to change anything. (on both opening and saving)

Just download the STL translator and import the file. Later save as a aoi file.

I suspect that the answers to Nik777's questions depend on the intended user population.

If the expected users are all 3D CAD power users, they'll probably want all the import/export dialogs and buttons to appear every time, so they can customise things. If they are novices, they are more likely to want the thing to "just work", and the fewer dialogs they have to see and understand the better. (BTW, even power users may sometimes prefer this approach, such as when under time pressure and needing to import/export a few hundred files before lunch!!)

If AoI needs to cater to both classes of user, then it may be appropriate to set it up to be all automated (minimal additional import/export dialogs) by default, *and* (ugh) to have some sort of option/preference that can be set and saved which then causes it to display the various additional dialogs. This is the classic programmers response to such issues "when it doubt, give the user more options"! It's not always a good idea in reality, of course, because it makes programs more complex, both to learn and use, and to maintain!

One more thing for Nik: While you're in there... adding a way to cause AOI to load a file and then save/export it in another format from the command line would be very handy indeed; in particular being able to tell it to open a .aoi file and export the corresponding .stl file would be most welcome :-)

Jonathan

Hi All,

Thank you all for both your feedback and encouragement.

I had considered the 'user preference' solution. I'll think on it a bit more. The problem I see with the 'smart-silent' approach is that it doesn't actually help eliminate any of the user confusion, and may end up adding to it.

Quote

While you're in there... adding a way to cause AOI to load a file and then save/export it in another format from the command line would be very handy indeed

I've had the initial code, and great future plans, for a command-line interface to AOI for just over a year now. Recently someone asked to take it over (to help them with a different project), so hopefully Claoi (I pronounce it like "Chloe') should be released in a month or so.

Thanks again for the feedback. I'll let you all know how I get on.

Cheers!
Nik.

Nik777 wrote:

> I had considered the 'user preference' solution.
> I'll think on it a bit more. The problem I see
> with the 'smart-silent' approach is that it
> doesn't actually help eliminate any of the user
> confusion, and may end up adding to it.

Well, I was thinking that many such users are at least somewhat comfortable with an office suite. You open a spreadsheet by double clicking on it. You edit it, you print it, you save it and the default file format is a ... spreadsheet :-) Likewise for word processor files, presentation files, etc. This "smart-silent" mode is very like that; open an STL by clicking on it and you can edit it and save it back as an STL. Open a .aoi and you can edit it and save it back as a .aoi. If you want anything different, you use File -> Save As. I know there are inherent differences in what you can store in an STL vs what you can store in an AOI file... but from the perspective of "open it, edit it, save it" (and soon also "print it" to your RepRap !!) this model seems simple and consistent. As long as repeated open/edit/save operations on STL files don't lose accuracy, or something nasty like that, it seems to be a useful way to do things, at least for novices.

> ... hopefully Claoi (I pronounce it like
> "Chloe') should be released in a month or so.

Very cool. Make sure you (or the other developer concerned) announce that here in the forums if you possibly can! One example I want it for is that we store .aoi files in our subversion repository, you could check them out and type make, and (after a slight delay!) get all the STL files generated from them.

Thanks,

Jonathan

i second jonathans request for an AoI command line option. if we had that, we could automate the object release stuff in the same way that we do for the host software, firmware. that would really help us out tremendously.

i'm personally willing to test a beta version if feedback is wanted/useful right now.

Quote

Well, I was thinking that many such users are at least somewhat comfortable with an office suite. You open a spreadsheet by double clicking on it. You edit it, you print it, you save it and the default file format is a ... spreadsheet [...]

As you point out later in your post, there are (significant) differences between what STL and AOI can store in a document. The difference is more like those between an OpenOffice document and unformatted text. If I follow the silent approach then we either risk dropping lots of information when saving silently to STL, or we keep popping up (unexpected) windows warning about "loss of formatting information". Pop-ups are, I think, worse than being explicit.

My current thoughts are:

1. Add a file-format pull-down to the File-open and file-save dialogs (ala OpenOffice).

1a When saving, assume the output format is the same as the input format.
- do not display a pop-up warning of possible information loss if this format is not the AOI format.

2. If a file cannot be read using the user-specified format (including the default AOI format), then an error is displayed allowing the user to try again, or select 'auto-import'. All warnings about possible loss of information are displayed here.

2a 'auto-import' attempts to import the file (based on the filename suffix). If successful, the output format is marked as that format originally selected by the user. This means the default save format will be the same as the user-selected format, as distinct from the actual format of the file.

Note This would allow a user to select the format at (say) .OBJ, auto-import an STL, and then save, which would default to saving as a .OBJ file.

All thoughts and suggestions are most welcome.

Cheers!
Nik

Edited 1 time(s). Last edit at 07/16/2007 10:43PM by Nik777.

Thanks for the encouragemnt for Claoi.

It's been a pet project of mine for a while now (I'm very much a CLI kinda guy anyway (real men don't eat Guishe!)).

I'll code the file-open/file-save changes first, then I'll get the Claoi stuff ready for initial use.

And I'll certainly announce it here on the forums.

Quote

(after a slight delay!)

Yes, sorry about that. My solution for the time the STL translator takes was to put a progress bar into the dialog.

I might look at the performance some day, but there are quite a few projects ahead of it in the work queue

Cheers!
Nik

cool, one of the very unique things about our project is that we are actually designing real objects to be printed with your program. in essence, AoI is our 3D object compiler. it takes the source file (AoI) and transforms it into a binary (STL) that we can then take and print.

one major bottleneck we have right now is the fact that we cant automate that process, which makes it time consuming and generally a PITA. if we could have a way to run AoI from the command line, take a .aoi file and spit out a .stl file, then life, and development would be much easier for both the RepRap project, and the many other projects that will hopefully one day spring from it.

I guess I don't see the problem. It's not much of a PITA to simply highlight the AoI objects that you want to turn into STL's and then export them as STL's, in my experience anyway. I spend about 99% of my time in AoI designing objects and a lot less that 1% turning them into STL files. Am I missing something here?

> ... we are actually designing real objects to be printed with your program ...

Yes. RepRap turns Art Of Illusion into Art of Reality! :-)

Jonathan

Forrest Higgs Wrote:
-------------------------------------------------------
> I guess I don't see the problem. It's not much of
> a PITA to simply highlight the AoI objects that
> you want to turn into STL's and then export them
> as STL's, in my experience anyway. I spend about
> 99% of my time in AoI designing objects and a lot
> less that 1% turning them into STL files. Am I
> missing something here?

yes. the problem comes down to packaging file releases. say you are working on something complicated like darwin or some other project like that. you can either manually export 60 files to STL each and every time you make a new release (testing releases too!) or you can keep track of exactly which files changed from release to release (and risk missing files) both those options are labor intensive. we dont manually compile programs by typing gcc every time, so why do the equivalent with our 3D objects.

the solution is to automate the process and have a program go through all of your files and export them to STL, then package them up in a nice zip file, ready to be uploaded to sourceforge for the masses to download and print. we can (and do) get by with manually exporting these things right now, but in the future it will definitely need to be automated.

Ha! Ok! I think I see where you're going with that.

A long time ago I got a copy of the AoI source just to poke around in and did quite a bit of poking around.

It would seem to me that the way to skin your particular cat would be to strip the routine that reads an AoI format file into the AoI memory structure as well as Nik's routine that writes out an AoI entity in STL format and then set that up as a stand along Java app that you could control fire from a command line. Ideally, you'd want to add a bit of Java and point it at a particular folder and have it convert all of the AoI files in that folder and deposit them in another folder.

The way that the AoI code is put together I doubt that would be a real challenge for somebody with reasonable Java skills. The nice part is that we're getting more and more Java wallahs in RepRap these days so there's probably somebody around that could do it.

The formats on AoI files and STL files haven't changed in a long, long time, so maintenance on such a stand-alone app shouldn't be horrific.

About the only obstacle that I can see would be more organisational than technical. Most of the RepRap entities that make up Darwin and the Mk II are the end result of a rather complicated concatenation of boolean operations. Whereas you only want to convert the final resultant boolean entity into STL if you don't have all of the Euclidean solids that the parts designer used to generate that final boolean you can't really go back and edit it.

Sometime take a look at Adrian's Mk II AoI zip and you can easily see what I mean. There are dozens of Euclidean solids in his zip for every Mk II part that you'd want to print.

Edited 1 time(s). Last edit at 07/17/2007 10:37AM by Forrest Higgs.

Just a quick update to let you know this (and other RepRap projects) have not been forgotten (nor abandonded).

There has been a fair bit of activity with the AOI 2.5 release. I am still dealing with some minor coding for that.

Then I will be able to complete a few things for the benefit of RepRap.

Cheers!
Nik

Yay! Thanks Nik.