Thanks and congrats for the last release. I´m currently working on a local Spanish language guide about using AoI for 3D printing, and a few questions came to mind while editing it:
1) I had Oracle Java JRE 8.xx (latest 1.8.0_281) preinstalled before installing AoI. Are you aware of any issues with the latest OpenJDK builds? (Java 11 and above). For instance Azul Systems offers OpenJDK 15 (Java 15) for Windows. I wonder if, moving forward, I´d be better recommending OpenJDK. Do you pack any JRE with the Windows installer of AOI?. In that case the point is moot.
2) Despite being released in 2021, the Splash Screen shows "(c) 2020" FYI / FWIW. If the last release was released January 2021, it should show 2021, IMHO. You might want to fix that (yeah, nitpicker me :)
3) Instead of installing to the system PROGRAM FILES folder (c:\program files) it installs into c:\users\my user\programs\ArtOfillusion. WHY??? it's the only program installed in that folder. This on 32bit Spanish language Win10 Pro 1909.
4) I'm unable to import any STL from thingiverse. The STLImport plug-in just sits there showing a moving progress bar and NOTHING HAPPENS. I have checked on the plugins subfolder and I have STLtranslator-2_5.jar. I guess that's the latest? Thanks for any help with this... which is my most pressing issue ATM...
5) the whole plugins manager is dog-slow. Maybe there would be a way to fetch a single compressed "index" file, generated server side? it looks as if it's currently doing all sequentially parsing results from a web server..
Like a said, not to rain on your parade, and congrats on this release....
Just my two cents worth...
FC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
okay, time to answer myself and save someone else some trouble.
The issue was that I manually downloaded what looked like the newest file, the one at the top of the listing. But it wasn't. I got the STL plugin version 2.5 when the latest is 2.7, dated 2013...
Now I'm able to open a STL file, with tons of ugly warnings (are these necessary? those will scare the sh-t out of the newcomers...)
(See Attached Error Listing)
MOD EDIT: I've moved the error listing to another file to keep this thread readable.
THREE ANNOYANCES:
1. The file dialog does NOT remember the last opened folder location, it always starts from my home user folder, which would be OK on Linux but is HORRIBLE in Windows (nobody uses the home folder in Windows, there is DESKTOP inside it, it should detect if it's running on Windows and either remember the last opened folder and save it to some internal INI file/config, OR default to the windows DESKTOP folder.
After showing all the above uglyness in the STL import dialog, the progress bar stays at the 1% done. In fact it completed the importing, so why doesn't it move further to 100%? I'm left wondering if something failed miserably, but lo and behold, there is the 3D model, so it succeded! so why does the progress bar makes me think it hasn't?
The model loads and shows correctly, but in a grossly over-zoomed view (if it were a face it'd be inside the nose). Can't AOI "zoom out" by default when importing a new model, to show it completely?
I can do that manually, I figured out, by going to the edit window, clicking on View-Fit to All
and then going to the camera view and repeating the process, View-> Fit to All.
Why isnt' there a way to automete this? The defaults are ridiculous.
Imagine if this were Word, and you loaded a letter and it defaulted to a full-screen zoomed-in view of the letter "g", and only after manually zooming out you realized it's "g" from "good day" in a sentence, in a paragraph, on a business letter.
Oh wait, there is a fourth annoyance...
The model shows a grid, but the grid is too small, less than 1/10th of the displayed model.
I wonder if this is a bug, and if so how to fix this. I can share the source STL if Peter or others want to test what I mean...
and a FIFTH annoyance:
I go to the menus, File->Close. It gives me the usual warnings about if I want to save the file and so on...
...and it closes the currently opened file AND THE PROGRAM DOWN with it.
File-> Close does not mean EXIT THE PROGRAM. It should keep running, I just want to load another file... then I have to restart the program.
In its current state, I cannot recommend AOI for 3D printing at all. But I want to...
Help me ID the bugs and help me to help you fix these...
I'm anxiously awaiting for Peter's views on this...
Just for the record, here is how I expect a modern app to show the model after it has loaded (in this case, imported). I had to manually tweak the zoom values on each window....
As I recall the .stl-importer was written by Nik, who rarely visits these sites nowadays.
For now I'll leave questions on your first post to others but a few comments.
The .stl-import:
I'm not sure why the programmer, found it important to list the numerical errors -- I suppose the list might help to track down problem in some cases, but please, avoid posting listings like is as text. Put them into attachments. You made your point. :)
There are the "center" and "frame" checkboxes on the UI.
Checking "frame" should fit the object to the screen(s), but I'm not actually sure if it does that any more as the view manipulation system of AoI has been entirely renewed since the stl-importer was written. However this is easy: Move the mouse on the object list and center-click on the new object . That is the built-in quick way to fit the active view to an object or a selection of objects.
I was just recently using the stl-importer and I think that the "center"function actually does just the opposite. It seems to bring the imported object away from the center the same amount it should move to the center.
And further more, by default AoI sets smoothing of TriangleMeshes to "Shading" and as the edge smoothing is "1.0" by default, AoI tries to render the imported object as if it consisted of curved surfaces. At least for anything technical that usually looks weird. The manual fix, of course, is to open the mesh for editing and set Mesh / Smoothing Method to None.
Also one problem, that I found with, ascii .stl is that the importer did not get past "end object" tags with an object name included. When I manually removed the names I got all.
... And it could name the imported objects with the names from the file instead of "Object something". :)
I have been thinking that I'd like to do those/some fixes to the importer. Those should not be a very big job, but so far that has been somewhere on my already excessive to-do-list for now... Having a couple of more programmers in the group would not hurt at all...
The file dialog does NOT remember the last opened folder location
Most of AoI UI remembers nothing. I could not agree more that this should have been taken care of 20 year ago.
File-> Close does not mean EXIT THE PROGRAM
Exactly. And it does not: In AoI it closes only the scene window that you use it on. If it is the last one open, then it exists the program too.
You can open several .aoi files into the same session. They all just open into their own windows, which is different from most other 3D software but at least MS-Office programs do that.
For example to copy objects from one scene to another, you need to open the files (except for the first one open) from the File menu to keep them inside the same session.
If you use the Start icon you'll start a new Java session and they are not aware of each others.
-- Just those this time, you had more but It's getting late on this side of the Earth --
Last edit: Pete 2021-02-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the general questions in your first post:
I would currently recommend Java 8 or 11 from www.adoptopenjdk.net. These are both stable, LTS (Long Term Support) builds. Anything newer is likely to have some back-compatibility issues.
Official OpenJDK builds, including some later java 8 builds, have been having some odd binary compatibility issues with native libraries, such as the OpenGL video card bindings.
We have not tested with Azul Systems. If you choose to try them out, please let us know how it goes.
We do not currently pack an included JRE, as that would be an additional ~100 MB or so.
Splash screen Copyright was last updated with some of the last functional changes, late in 2020. All tweaking in the weeks leading up to the final release were in how we built the packaging which did not seem to indicate an update to the date.
Frankly, I'd like to be able to change this, but it would require some significant restructuring in certain areas. We had some long-awaited bugfixes that I was not willing to put on hold for another 6-12 mo project. The reason that it is the way that it currently is: C:\Program Files is a privileged location. As things stand, you need Admin permission to write to it or any of it's subfolders. This would mean running in elevated mode for:
Installing or updating Plugins
Writing new scripts
Writing textures and materials to the library
Running in elevated mode all the time is bad for several reasons, not least of which is that scripts or plugins can literally try to do anything that the program system access allows, including potentially deleting or altering system-critical files.
Will address separately
I agree. Trouble is, this means re-writing the entire manager system, - Which needs to be done anyway - and that will be a significant project.
Last edit: Luke S 2021-02-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The reason that it is the way that it currently is: C:\Program Files is a privileged location. As things stand, you need Admin permission to write to it or any of it's subfolders"
How does VUZE, the bittorrent desktop app which is also Java based, manage this? I never got any system dialogs to update the program, and I know it doesn´t run with elevated privileges.
Something tells me that your rationale about this is wrong.
".This would mean running in elevated mode for:
Installing or updating Plugins
Writing new scripts
Writing textures and materials to the library"
Shouldn´t these things be in Application Data which is a subfolder on the users folder, rather than inside the program folder?
"Running in elevated mode all the time is bad for several reasons, not least of which is that scripts or plugins can literally try to do anything that the program system access allows, including potentially deleting or altering system-critical files."
Of course I don´t advocate that. See above.
Hope this helps...
FC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the STL importer plugin... I told Peter that due to the surge in popularity of 3D Printers many and many users will come to AoI expecting being able to edit STL files for 3D printing...
Would it be possible to package the latest STL importer (STLTranslator-2_7.jar) by default with the installer? Its only 27 KBytes... That would lower the barrier of entry for 3D printing model usage.
Peter told me he was "only tangentially involved in AoI development nowadays" and that it was better if I took discussion to the forums, which I´m doing right now :)
I also tried emaling the STL importer plugin source author Nik Trevallyn-Jones at the only email address I could find of him (nik777 at users.sourceforge.net, so far without answer.
Does anyone have a different contact email address of him you could share with me?. Off-list if you prefer. My email is everywhere if you google my name... ( f.(my last name)... at gmail dot com).
I already found that the STLTranslator$2.class and STLTrnaslator$3.class is where the text box and buttons are created... but without the source I could only patch the binaries...
Thanks in advance.
FC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps this will shed some light on what the plugin is doing when reading to calculate the warnings threshold?
"tolerance" is defined below...
public class STLTranslator implements Plugin, Translator {
public static final int EXPORT = 0;
public static final int IMPORT = 1;
public double surfError = 0.05D;
public double tolerance = 0.0D;
public int decimal = 12;
public boolean ignoreError = false;
Just a heads up: Nik is also only "Tangentially Involved" with AOI at this point. I haven't heard from him in about a year or more. (He does occasionally drop in when one of his pet projects comes up, but that is rare.)
STLTranslator source is available on the (https://sourceforge.net/projects/aoisp/files/)[AOISP project files page.]
Errors on import: These are due to floating point rounding errors. The importer is doing some math to make sure that the faces that it reads point in the same direction that the file says they should, and it's freaking out when it expected 1.0 and got 0.999999999999999999. This is probably due to the exporter that generated that file using a different bitwidth of floating point number than the AOI Importer library does. The tolerance should actually be calculated during the check. Should be an easy fix.
File Dialog Location Defaults/Memory: Definitely a known limitation that I want to fix. We need to design what the interface for a "remembered locations" version should look like, as there is no standard component for that. As a recovering Windows user (I now have a penguin infestation) I'm a little leery of defaulting to Desktop\, as I always hated saving things there.
I'll have to look into the progress bar situation. Not sure what's going on there.
Should probably update the post-import zoom to us the "Fit to" functions. If the plugin is doing something custom here, it's out of date
Grids: Do need a re-work including auto-scaled spacing, but that's another project. The Perspective mode grid covers an area of 20X20 units, and currently cannot change. Some files have very crazy scales. I'm not sure of what your sample file is, but I'm guessing that it may have been saved with the idea that 1 unit = 0.5mm or so?
Program Closing on close of last file: AOI currently does not have the concept of being open without having an open scene. This is mostly a holdover from a time when that was a much more common approach. Perhaps worth considering for the future, but will not be a simple change.
Including STLTranslator in the core package: Ehhh.... Its not so much the size. I would have two negative effects:
It adds menu options and UI clutter for users that don't need this support. Not much in this case, but over time and many plugins, it adds up
It ties the translator to AOI's release cycle, which is fairly slow. The next AOI release is probably several months, if not more than a year, away. On the other hand, if the basic issues are as simple as they appear on the surface, we could have an updated STLTranslator within a couple of weeks. (No promises, but at least its within the realm of possibility.)
Up a few posts, you said you would like to help fix some of these bugs. Were you thinking of actually working on the code?
- If so, great! Let me know what you need to get started.
- If not, that's fine too. Interested users with a set of things they really want to see fixed are a great motivator, and can provide a lot of help as we test the changes that we make.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ahh... Somewhere along the line, the project got in the habit of naming plugin binaries by the version of AOI that they were compiled against, rather than the actual plugin version. That is a habit that I'm trying to break.
Seems that the most recent version that we have binary for is 1.21, which is just a recompile of 1.2, which was just a few tweaks for API compatibility with AOI 2.6. Unfortunately, we don't have the source for those changes. I suspect that they will be fairly simple to replicate, though.
TLDR; Starting from the 1.1 source is the way to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RE: VUZE updates: I'm not sure what they are up to, as I've never used them. Do they even do auto-updates? Did the original install require UAC? (The "Allow this program to make changes to your computer" dialog) Do you typically use your Admin account as your user account?
We did do some testing during the 3.2 leadup, and it definitely didn't work with normal access.
APPDATA folder?
Good question. We would definitely need to do some restructuring to support that, as currently AOI is hard-coded to expect these things in a specific location in relation to the main program. I did do a spike development a few months ago to try this out, and getting it right is... not as simple as it sounds.
Going with APPDATA also means that these updates are only available to the user who installed them. While multi-user windows systems in the minority, we do need to decide how we want to handle that...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fernando, if you're still watching, I've started cleaning up the STL plugin code. Was the actual STL file something that could be shared? It would be nice to have a real world dataset to work against.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fernando, if you're still watching, I've started cleaning up the STL plugin
code. Was the actual STL file something that could be shared? It would be
nice to have a real world dataset to work against.
Sorry, missed this one.
Yes, I´m here.
The STL is available publicly, it´s this one....
Got back to the STL plugin just now. A finding and a couple of questions:
The existing code already scales the face-normal error checking. It makes an order-of-magnitude check determined by the value of error tolerance set in the GUI.
I have not been able to reproduce the 1% progress bar behavior. My test files so far have all only shown a non-numeric "Working" bar - just drifts back and forth - which disappears when the import is complete. I then get a "Done" button to dismiss the dialog after reviewing the facet-normal errors.
Can someone (Pete?) verify that they are getting %progress bar on Windows?
Does the bar freeze at 1% or some other inappropriate amount?
I also have found that the view-centering code is, indeed, doing very out-of-date things. It's actually moving the SceneCamera around, which does not affect most views at all. Should be a simple fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doing a little digging on STL as a format, I find that we are one of the very few STL readers that bother with checking the normal. Wikipedia actually calls the plugin out as something of an outlier here. Does anyone see a reason to continue this? STL is really just a triangle-soup format, and AOI can't use the normals even if they are deliberately repurposed for shading.
The actual errors, at least in the files I've worked with so far, are due to the format using 32-bit FP, while AOI's Vec3 is based on doubles (64-bit)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was wondering if the 'maxDecimalDigits' setting had any effect on the normals error checking but it does not.
Anyway, I'd say, keep the feature but give it an actual meaning.
STL itself is a very simple format but even with that new programmes sometimes get bright ideas that are entirely wrong (like putting localization into the ASCII-STL format, I have seen that happen) and it is not that uncommon, that there are mistakes in triangulation for a variety of reasons that I can not start to imagine. Even at the moment I use a tool that messes up normal directions in an otherwise brilliant onscreen triangualtion on curved surfaces. And that software is one of the oldest in the market.
Obviously the single/double error could be ignored but instead I'd suggest to notify the user when significant errors are found. What is significant then? Some tolerance in degrees maybe? Or at the very least, when the marked normal direction is entirely inside out (it just might be that it is the triangle that is inside out, not the pre-defined normal). And possibly the list of errors should not be always shown. I'd put it a bit deeper in the UI, so the user could view a report if the importer reports a potential problem.
I've got a couple of other notes/wishes/bugs. I'll be back with those. :)
Last edit: Pete 2021-10-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When that line comes up an error message dialog appears and while it is shown the proggressbar is pumping green.... When I close the error message, the import terminates, the progress bar stops with just a very short blue mark on the left and the first object in the file appears on the screen.
If I change all "endsolid" lines to read just "endsolid", then all objects will be read. The PB still seems to be used in undefined mode (or what ever the mode is called again...)
And all the imported objects are named "object-0". The least I'd expect would be to use the name of the import file and accending numbering, but depending on the source, each object may also have a name. In the case above the name was only a number though the parts were named in the CAD. It' be nice if the plugun could use the known and otherwise generate unique ones.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Obviously the single/double error could be ignored but instead I'd suggest to notify the user when significant errors are found. What is significant then? Some tolerance in degrees maybe?
This is sort of what it's supposed to be doing. The sensitivity is adjusted based on MaxError, but it scales with the length of the component.
I have a case where the progress bar appears in undefined mode and finally end up showin about one pixel of progress.
Does this happen with all named objects, or just with certain characters in the name?
Do you get a proper progress bar on files without object names?
And all the imported objects are named "object-0".
I'll put it on the list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does this happen with all named objects, or just with certain characters in the name?
With some characters, it turns out. The 'invalid token' number is the ASCII number of the "wrong" character: 58 for colon, 47 for slash.... But strangely the same text in the beginning of each solid is not a problem.
Do you get a proper progress bar on files without object names?
I haven't paid attention to that before and this time my test files were pretty light, but it always looked like the pulsing type of progress bar while it was active.
If I get this right the issue is a combination of a few things:
A line beginning "solid" is expected to continue with a name for the solid but the name is expected to be in quotes.
If there is no name in quotes then the object should be named "Object-" + number. Unfortunately the number ("count") is declared 0 every time the part of the code is called.
"wordChars" are defined on lines 541 through 549 but the character set is a bit limited and the :\/!? ... don't belong to the set.
A line beginning "endsolid" is expected to end there and go to the next line.
So to improve I'd:
Define '!','~' as wordChars. So basically everything that is not a control character. I guess it would not hurt if things like !,@ and % were readable.
Add the extended ASCII characters to the list as well. Strictly speaking, this is not original ASCII any more but for example € and the old European variants of characters would then be included.
And I'd get rid of the requirement to have the name in quotes.
At least Wikipedia does not even mention using quotes but "endsolid" should be followed by "name". I have never found anywhere the original STL-spec, just descriptions of it, which gives it a kind of "folkloreish" feel ... :)
EDIT: The wordChars.
Last edit: Pete 2021-10-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not seeing precedent for the quotes either. Also, we do need to accept the endsolid name lines.
Are some of your more interesting name characters, such as :/ being exported by other programs, or are they files that you had created in some other way? I'm not seeing precedent either way on that.
I'm not sure that adding extended ASCII is a good idea. It might cause incompatibilities with other programs, which kind of defeats the purpose.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That was my current work CAD. They write the entire file path for name. (Also it only exports ASCII STL, not binary at all. A bit of a dinosaur for a software, I dare say... ... and I have.)
I'm not sure that adding extended ASCII is a good idea.
I don't see the ability to handle a wider character set in the input as a potential compatibility problem. On the contrary. Instead it's the output we should be careful with, but as I did some testing a couple of things came up:
In it's current form the AoI exporter happily writes äs and ös into the object name, but it can not read them back. (Another vote to add the extended set to reading: There is no way of knowing what any software may allow to write.)
AoI exports two (and probably more) objects into one "solid". This is wrong. The combined solid gets the name of the first one. The dinosaur-of-a-CAD separates the two volumes of the solid into "PART1" and "PART2" and names the assembly by the filename. Obviously the volume separation is a post processing step. AoI naturally reads it all into one object.
And the dinosaur did not stumble into ö-letters in the object name, though it probably did not handle it at all. Their idea of tackling compatibility issues, I guess.
It might be a bit of extra trouble to code but to us "unamerican" users it would be friendly to notify if exported object names contain extended ASCII characters in output. Some importers might be tolerant/ignorant to those and some not so much. One possibility would be to add a user selection to enable/disable extended ASCII in export. Even further, if the user chooses not to allow eA, it might be a nice idea to have a replacement map that changes all ä å á into a (those do exist) but thinking of the amount of work it needs...
Last edit: Pete 2021-10-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info. Some good points here, but also some follow-up questions:
I'd be okay with extended read support, but what qualifies as Extended ASCII? (That's not an official spec name) I'd imagine probably ISO 8859-1 or Windows-1252 (AKA US-ASCII), and one of these may, in fact, have been what 3D Systems was using when they defined the format.
The "Combined parts" thing may be the exporter getting ahead of itself. Binary STL does not support multiple parts, weirdly enough. The exporter may need to be split a bit further up the process.
There are several existing ways to map accented Latin characters to their unaccented base. Probably were we really need to sanitize, though, is unicode characters that are not in the ASCII zone at all. Should the export just fail with a warning, or should it silently discard the unsupported characters?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So ASCII or US-ASCII = printable characters from #0 to #127 and Extended ASCII, #128 to #255 what ever they might be in any system. I suppose there should be a system level way to deal with unknown characters in input? Or are there hidden traps in there?
unicode characters that are not in the ASCII zone at all.
You're right. Other than Latin based characters in object names would probably not work too well. One way to handle it would be to replace the non ASCII characters with something safe like the ¤-sign but if everything were named, say in Japanese, that would not really work. In that case I'd probably go with "Object_x" for all the exported content. But that is two different approaches. I think one should be enough (unless there is a simple solution, that can analyze the names and decide for each object name individually, at hand).
Should the export just fail with a warning, or should it silently discard the unsupported characters
It should definitely perform the export (or import) even with "funny" characters in names. Anybody should have the freedom to name their work in their own language and object names are not an actual technical feature. Of course it would be polite to notify the user when something has been renamed but I would not give that a very high priority. Usually it is just done when necessary.
One way to handle (Ext ASCII) characters, that I have seen, was to replace each #128+ character with its HEX code. "Pyörä" (Wheel) became "PyF6rE4". -- Seriously? I'd rather just read weird letters and in this case, I'm very sure, the outcome would have been correct without the replacement.
Binary STL does not support multiple parts, weirdly enough.
That is weird. Makes me wonder... But it is an ancient format and AFAIK the development was never taken to the level it was originally planned.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
Thanks and congrats for the last release. I´m currently working on a local Spanish language guide about using AoI for 3D printing, and a few questions came to mind while editing it:
1) I had Oracle Java JRE 8.xx (latest 1.8.0_281) preinstalled before installing AoI. Are you aware of any issues with the latest OpenJDK builds? (Java 11 and above). For instance Azul Systems offers OpenJDK 15 (Java 15) for Windows. I wonder if, moving forward, I´d be better recommending OpenJDK. Do you pack any JRE with the Windows installer of AOI?. In that case the point is moot.
2) Despite being released in 2021, the Splash Screen shows "(c) 2020" FYI / FWIW. If the last release was released January 2021, it should show 2021, IMHO. You might want to fix that (yeah, nitpicker me :)
3) Instead of installing to the system PROGRAM FILES folder (c:\program files) it installs into c:\users\my user\programs\ArtOfillusion. WHY??? it's the only program installed in that folder. This on 32bit Spanish language Win10 Pro 1909.
4) I'm unable to import any STL from thingiverse. The STLImport plug-in just sits there showing a moving progress bar and NOTHING HAPPENS. I have checked on the plugins subfolder and I have STLtranslator-2_5.jar. I guess that's the latest? Thanks for any help with this... which is my most pressing issue ATM...
5) the whole plugins manager is dog-slow. Maybe there would be a way to fetch a single compressed "index" file, generated server side? it looks as if it's currently doing all sequentially parsing results from a web server..
Like a said, not to rain on your parade, and congrats on this release....
Just my two cents worth...
FC
okay, time to answer myself and save someone else some trouble.
The issue was that I manually downloaded what looked like the newest file, the one at the top of the listing. But it wasn't. I got the STL plugin version 2.5 when the latest is 2.7, dated 2013...
Now I'm able to open a STL file, with tons of ugly warnings (are these necessary? those will scare the sh-t out of the newcomers...)
(See Attached Error Listing)
MOD EDIT: I've moved the error listing to another file to keep this thread readable.
THREE ANNOYANCES:
1. The file dialog does NOT remember the last opened folder location, it always starts from my home user folder, which would be OK on Linux but is HORRIBLE in Windows (nobody uses the home folder in Windows, there is DESKTOP inside it, it should detect if it's running on Windows and either remember the last opened folder and save it to some internal INI file/config, OR default to the windows DESKTOP folder.
After showing all the above uglyness in the STL import dialog, the progress bar stays at the 1% done. In fact it completed the importing, so why doesn't it move further to 100%? I'm left wondering if something failed miserably, but lo and behold, there is the 3D model, so it succeded! so why does the progress bar makes me think it hasn't?
The model loads and shows correctly, but in a grossly over-zoomed view (if it were a face it'd be inside the nose). Can't AOI "zoom out" by default when importing a new model, to show it completely?
I can do that manually, I figured out, by going to the edit window, clicking on View-Fit to All
and then going to the camera view and repeating the process, View-> Fit to All.
Why isnt' there a way to automete this? The defaults are ridiculous.
Imagine if this were Word, and you loaded a letter and it defaulted to a full-screen zoomed-in view of the letter "g", and only after manually zooming out you realized it's "g" from "good day" in a sentence, in a paragraph, on a business letter.
Oh wait, there is a fourth annoyance...
The model shows a grid, but the grid is too small, less than 1/10th of the displayed model.
I wonder if this is a bug, and if so how to fix this. I can share the source STL if Peter or others want to test what I mean...
and a FIFTH annoyance:
I go to the menus, File->Close. It gives me the usual warnings about if I want to save the file and so on...
...and it closes the currently opened file AND THE PROGRAM DOWN with it.
File-> Close does not mean EXIT THE PROGRAM. It should keep running, I just want to load another file... then I have to restart the program.
In its current state, I cannot recommend AOI for 3D printing at all. But I want to...
Help me ID the bugs and help me to help you fix these...
I'm anxiously awaiting for Peter's views on this...
Just my $0.02.
FC
Last edit: Luke S 2021-02-24
Just for the record, here is how I expect a modern app to show the model after it has loaded (in this case, imported). I had to manually tweak the zoom values on each window....
I suppose it should be possible to automate this?
Last edit: Fernando Cassia 2021-02-23
Hi. I don't disagree at all....
As I recall the .stl-importer was written by Nik, who rarely visits these sites nowadays.
For now I'll leave questions on your first post to others but a few comments.
The .stl-import:
I'm not sure why the programmer, found it important to list the numerical errors -- I suppose the list might help to track down problem in some cases, but please, avoid posting listings like is as text. Put them into attachments. You made your point. :)
There are the "center" and "frame" checkboxes on the UI.
Checking "frame" should fit the object to the screen(s), but I'm not actually sure if it does that any more as the view manipulation system of AoI has been entirely renewed since the stl-importer was written. However this is easy: Move the mouse on the object list and center-click on the new object . That is the built-in quick way to fit the active view to an object or a selection of objects.
I was just recently using the stl-importer and I think that the "center"function actually does just the opposite. It seems to bring the imported object away from the center the same amount it should move to the center.
And further more, by default AoI sets smoothing of TriangleMeshes to "Shading" and as the edge smoothing is "1.0" by default, AoI tries to render the imported object as if it consisted of curved surfaces. At least for anything technical that usually looks weird. The manual fix, of course, is to open the mesh for editing and set Mesh / Smoothing Method to None.
Also one problem, that I found with, ascii .stl is that the importer did not get past "end object" tags with an object name included. When I manually removed the names I got all.
... And it could name the imported objects with the names from the file instead of "Object something". :)
I have been thinking that I'd like to do those/some fixes to the importer. Those should not be a very big job, but so far that has been somewhere on my already excessive to-do-list for now... Having a couple of more programmers in the group would not hurt at all...
Most of AoI UI remembers nothing. I could not agree more that this should have been taken care of 20 year ago.
Exactly. And it does not: In AoI it closes only the scene window that you use it on. If it is the last one open, then it exists the program too.
-- Just those this time, you had more but It's getting late on this side of the Earth --
Last edit: Pete 2021-02-23
Thank you very much for your feedback!
Regarding the general questions in your first post:
C:\Program Filesis a privileged location. As things stand, you need Admin permission to write to it or any of it's subfolders. This would mean running in elevated mode for:Last edit: Luke S 2021-02-24
"The reason that it is the way that it currently is: C:\Program Files is a privileged location. As things stand, you need Admin permission to write to it or any of it's subfolders"
How does VUZE, the bittorrent desktop app which is also Java based, manage this? I never got any system dialogs to update the program, and I know it doesn´t run with elevated privileges.
Something tells me that your rationale about this is wrong.
".This would mean running in elevated mode for:
Installing or updating Plugins
Writing new scripts
Writing textures and materials to the library"
Shouldn´t these things be in Application Data which is a subfolder on the users folder, rather than inside the program folder?
https://www.howtogeek.com/318177/what-is-the-appdata-folder-in-windows/
"Running in elevated mode all the time is bad for several reasons, not least of which is that scripts or plugins can literally try to do anything that the program system access allows, including potentially deleting or altering system-critical files."
Of course I don´t advocate that. See above.
Hope this helps...
FC
Thanks Luke,
About the STL importer plugin... I told Peter that due to the surge in popularity of 3D Printers many and many users will come to AoI expecting being able to edit STL files for 3D printing...
Would it be possible to package the latest STL importer (STLTranslator-2_7.jar) by default with the installer? Its only 27 KBytes... That would lower the barrier of entry for 3D printing model usage.
Peter told me he was "only tangentially involved in AoI development nowadays" and that it was better if I took discussion to the forums, which I´m doing right now :)
I also tried emaling the STL importer plugin source author Nik Trevallyn-Jones at the only email address I could find of him (nik777 at users.sourceforge.net, so far without answer.
Does anyone have a different contact email address of him you could share with me?. Off-list if you prefer. My email is everywhere if you google my name... ( f.(my last name)... at gmail dot com).
I already found that the STLTranslator$2.class and STLTrnaslator$3.class is where the text box and buttons are created... but without the source I could only patch the binaries...
Thanks in advance.
FC
Perhaps this will shed some light on what the plugin is doing when reading to calculate the warnings threshold?
"tolerance" is defined below...
public class STLTranslator implements Plugin, Translator {
public static final int EXPORT = 0;
public static final int IMPORT = 1;
public double surfError = 0.05D;
public double tolerance = 0.0D;
public int decimal = 12;
public boolean ignoreError = false;
FC
Just a heads up: Nik is also only "Tangentially Involved" with AOI at this point. I haven't heard from him in about a year or more. (He does occasionally drop in when one of his pet projects comes up, but that is rare.)
STLTranslator source is available on the (https://sourceforge.net/projects/aoisp/files/)[AOISP project files page.]
1.0and got0.999999999999999999. This is probably due to the exporter that generated that file using a different bitwidth of floating point number than the AOI Importer library does. The tolerance should actually be calculated during the check. Should be an easy fix.Desktop\, as I always hated saving things there.Up a few posts, you said you would like to help fix some of these bugs. Were you thinking of actually working on the code?
- If so, great! Let me know what you need to get started.
- If not, that's fine too. Interested users with a set of things they really want to see fixed are a great motivator, and can provide a lot of help as we test the changes that we make.
Luke,
Thanks for your continued support. You said "STLTranslator source is available on (https://sourceforge.net/projects/aoisp/files/)"
I see only version 1.1. there.
The latest binary Jar is v2.7
I am confused now... :)
FC
Ahh... Somewhere along the line, the project got in the habit of naming plugin binaries by the version of AOI that they were compiled against, rather than the actual plugin version. That is a habit that I'm trying to break.
Seems that the most recent version that we have binary for is 1.21, which is just a recompile of 1.2, which was just a few tweaks for API compatibility with AOI 2.6. Unfortunately, we don't have the source for those changes. I suspect that they will be fairly simple to replicate, though.
TLDR; Starting from the 1.1 source is the way to go.
^^^^
RE: VUZE updates: I'm not sure what they are up to, as I've never used them. Do they even do auto-updates? Did the original install require UAC? (The "Allow this program to make changes to your computer" dialog) Do you typically use your Admin account as your user account?
We did do some testing during the 3.2 leadup, and it definitely didn't work with normal access.
Good question. We would definitely need to do some restructuring to support that, as currently AOI is hard-coded to expect these things in a specific location in relation to the main program. I did do a spike development a few months ago to try this out, and getting it right is... not as simple as it sounds.
Going with
APPDATAalso means that these updates are only available to the user who installed them. While multi-user windows systems in the minority, we do need to decide how we want to handle that...Fernando, if you're still watching, I've started cleaning up the STL plugin code. Was the actual STL file something that could be shared? It would be nice to have a real world dataset to work against.
On 08/04/2021, Luke S ljsails@users.sourceforge.net wrote:
Sorry, missed this one.
Yes, I´m here.
The STL is available publicly, it´s this one....
https://www.thingiverse.com/thing:2120591
FC
Got back to the STL plugin just now. A finding and a couple of questions:
I also have found that the view-centering code is, indeed, doing very out-of-date things. It's actually moving the
SceneCameraaround, which does not affect most views at all. Should be a simple fix.Doing a little digging on STL as a format, I find that we are one of the very few STL readers that bother with checking the normal. Wikipedia actually calls the plugin out as something of an outlier here. Does anyone see a reason to continue this? STL is really just a triangle-soup format, and AOI can't use the normals even if they are deliberately repurposed for shading.
The actual errors, at least in the files I've worked with so far, are due to the format using 32-bit FP, while AOI's
Vec3is based on doubles (64-bit)I was wondering if the 'maxDecimalDigits' setting had any effect on the normals error checking but it does not.
Anyway, I'd say, keep the feature but give it an actual meaning.
STL itself is a very simple format but even with that new programmes sometimes get bright ideas that are entirely wrong (like putting localization into the ASCII-STL format, I have seen that happen) and it is not that uncommon, that there are mistakes in triangulation for a variety of reasons that I can not start to imagine. Even at the moment I use a tool that messes up normal directions in an otherwise brilliant onscreen triangualtion on curved surfaces. And that software is one of the oldest in the market.
Obviously the single/double error could be ignored but instead I'd suggest to notify the user when significant errors are found. What is significant then? Some tolerance in degrees maybe? Or at the very least, when the marked normal direction is entirely inside out (it just might be that it is the triangle that is inside out, not the pre-defined normal). And possibly the list of errors should not be always shown. I'd put it a bit deeper in the UI, so the user could view a report if the importer reports a potential problem.
I've got a couple of other notes/wishes/bugs. I'll be back with those. :)
Last edit: Pete 2021-10-11
I have a case where the progress bar appears in undefined mode and finally end up showin about one pixel of progress.
What happens is that the ASCII importer can not get past a line like,
When that line comes up an error message dialog appears and while it is shown the proggressbar is pumping green.... When I close the error message, the import terminates, the progress bar stops with just a very short blue mark on the left and the first object in the file appears on the screen.
If I change all "endsolid" lines to read just "endsolid", then all objects will be read. The PB still seems to be used in undefined mode (or what ever the mode is called again...)
And all the imported objects are named "object-0". The least I'd expect would be to use the name of the import file and accending numbering, but depending on the source, each object may also have a name. In the case above the name was only a number though the parts were named in the CAD. It' be nice if the plugun could use the known and otherwise generate unique ones.
This is sort of what it's supposed to be doing. The sensitivity is adjusted based on
MaxError, but it scales with the length of the component.Does this happen with all named objects, or just with certain characters in the name?
Do you get a proper progress bar on files without object names?
I'll put it on the list.
With some characters, it turns out. The 'invalid token' number is the ASCII number of the "wrong" character: 58 for colon, 47 for slash.... But strangely the same text in the beginning of each solid is not a problem.
I haven't paid attention to that before and this time my test files were pretty light, but it always looked like the pulsing type of progress bar while it was active.
I was curious about what is in the code, so....
If I get this right the issue is a combination of a few things:
:\/!? ...don't belong to the set.So to improve I'd:
'!','~'as wordChars. So basically everything that is not a control character. I guess it would not hurt if things like !,@ and % were readable.At least Wikipedia does not even mention using quotes but "endsolid" should be followed by "name". I have never found anywhere the original STL-spec, just descriptions of it, which gives it a kind of "folkloreish" feel ... :)
EDIT: The wordChars.
Last edit: Pete 2021-10-12
I'm not seeing precedent for the quotes either. Also, we do need to accept the endsolid name lines.
:/being exported by other programs, or are they files that you had created in some other way? I'm not seeing precedent either way on that.That was my current work CAD. They write the entire file path for name. (Also it only exports ASCII STL, not binary at all. A bit of a dinosaur for a software, I dare say... ... and I have.)
I don't see the ability to handle a wider character set in the input as a potential compatibility problem. On the contrary. Instead it's the output we should be careful with, but as I did some testing a couple of things came up:
It might be a bit of extra trouble to code but to us "unamerican" users it would be friendly to notify if exported object names contain extended ASCII characters in output. Some importers might be tolerant/ignorant to those and some not so much. One possibility would be to add a user selection to enable/disable extended ASCII in export. Even further, if the user chooses not to allow eA, it might be a nice idea to have a replacement map that changes all
ä å áintoa(those do exist) but thinking of the amount of work it needs...Last edit: Pete 2021-10-13
Thanks for the info. Some good points here, but also some follow-up questions:
I was reading this page, when I wrote that. https://www.ascii-code.com/
So ASCII or US-ASCII = printable characters from #0 to #127 and Extended ASCII, #128 to #255 what ever they might be in any system. I suppose there should be a system level way to deal with unknown characters in input? Or are there hidden traps in there?
You're right. Other than Latin based characters in object names would probably not work too well. One way to handle it would be to replace the non ASCII characters with something safe like the ¤-sign but if everything were named, say in Japanese, that would not really work. In that case I'd probably go with "Object_x" for all the exported content. But that is two different approaches. I think one should be enough (unless there is a simple solution, that can analyze the names and decide for each object name individually, at hand).
It should definitely perform the export (or import) even with "funny" characters in names. Anybody should have the freedom to name their work in their own language and object names are not an actual technical feature. Of course it would be polite to notify the user when something has been renamed but I would not give that a very high priority. Usually it is just done when necessary.
One way to handle (Ext ASCII) characters, that I have seen, was to replace each #128+ character with its HEX code. "Pyörä" (Wheel) became "PyF6rE4". -- Seriously? I'd rather just read weird letters and in this case, I'm very sure, the outcome would have been correct without the replacement.
That is weird. Makes me wonder... But it is an ancient format and AFAIK the development was never taken to the level it was originally planned.