RE: Potentially out-of-date work.

[Sailsman63]

Hi.

Just a warning that I started to work on the STL-translator last December from 3b2099a. I'm afraid that I have edited the code so heavily that it will not be possible (or at least resonable) to rebase that branch into any changes done to the master after that. So far I have 13 commits, with deprecation fixes included (9th commit in my branch).

Sadly I have had AoI pretty much on hold lately. The edition is working but it is in a state, that I would feel very uncomfortable publishing. I may have some time to work on it next week though.

Originally posted by @peteihis in https://github.com/ArtOfIllusion/STLTranslator/issues/3#issuecomment-1049506882

[Sailsman63]

Well, I'd be willing to try to run the rebase. (It seems to be a bit of a specialty of mine) If you'd like me to try, please post what you have as a PR.

This is why small, compact PRs are preferred.

[peteihis]

I this case small PRs would not have worksed, it would have been in constant unfinished state for a very long time. so let's see. I probably can not stop you from trying but honestly I'd find it hard to see any point in attempting rebase any more..... Anyway I already have that particular issue covered.

I was considering 'PR-ing' at some point just to keep everybody posted but I felt (and still feel) uncomfortable about the mess it is and ... well ... here we are.

justWait(indefinite)

[peteihis]

Just a small update:

Some time ago I started to recreate the the thing form scratch and I got farther faster than with all I spent time on before. I've got the basic functionality of import working but a lot is still missing, like view fitting, error messages, import reports, translations.... I'm also thinking about adding a scaling option, which I really missed, when I used AoI professionally the last time (but first things first).

Now there are (will be) dedicated dialogs for both import and export, instead of refurbishing the same one and having the code do the slalom between opposite functions. The importer and exporter will also be in separate classes and so far there is a separate STL-reader class that only delivers the "raw triangles" (and hopefully any possible meta data) to the importer, which then constructs the TriangleMesh(es). -- And I think that I can make the importer recognize solids that have vertices in shared positions, at least in most cases. (The traditional way is to assume that same position means same vertex and that is not always the case and a perfectly good export usually fails at import in those cases.)

Of course separating the mesh source data generation from file reading slows the import down quite a bit, but it makes many other things much easier.

I'm just wondering why I or anybody else did not do it this way in the first place.... But here we go. Snail speed but we do!

EDIT: Those progress bars are currently called readBar, processBar and funBar ... So at the moment the last one is not there for any reason ....

[Sailsman63]

I started to recreate the the thing form scratch

As in, re-implement the entire plugin from the ground up?

I think that I can make the importer recognize solids that have vertices in shared positions, at least in most cases. (The traditional way is to assume that same position means same vertex and that is not always the case and a perfectly good export usually fails at import in those cases.)

These unstructured triangle representations are often referred to as "Triangle Soup", and I've looked into doing a separate library specifically for taking a "soup" and returning a valid mesh or set of mesh segments. It's a bit of a hard problem.

[peteihis]

As in, re-implement the entire plugin from the ground up?

Yes. Trying anything else, all you get is old...

Started from both ends of the code, creating a reader that only reads the triangles, where the code is raked out from the existing one, and building a dialog, where things are lined up and clearly grouped. I'm getting to be somewhat happy with how the plugin and the import side work. Once I'm happy with those, I'll start with the export. -- Better to sort out the principles while there is less code floating around.

"Triangle Soup"

I was not planning on sieving soup.... The idea is that, when several objects are exported into one binary file they are still deconstructed there one after one. So, the import code keeps track of open edges and at the moment there are none, that object is ready and the importer starts to build a new one. The check does not even seem to slow the mesh parsing down so much, that you would notice, as long as you only check the open edges. (OTOH re-checking every edge after every added face, soon enough, became a "grains of rice on a chessboard problem.")

So far I haven't had a test case with multiple solids in one list, but reading a single object, the checker method, called isClosed() reported "true" exactly, when it was supposed to. :)

[Sailsman63]

Ahh... Closed surfaces are a simpler problem than the full "Triangle Soup" situation.

re-checking every edge after every added face, soon enough, became a "grains of rice on a chessboard problem."

You might want to parse the entire file into an array or similar, and then do the mesh construction as a separate pass. Reading from a file piecemeal is a recipe for slow code.

[peteihis]

You might want to parse the entire file into an array or similar, and then do the mesh construction as a separate pass.

That's what I did. :) And the same will have to be happen to the opposite direction with the export.