Edit by copying the objects in a new file not all were rendered. Edit 2 The problem continues. See my next post. Edit 3 Sorry for canceling my first post, when I thought I got the problems fixed ...
Last edit: Konrad W. 2023-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Luke S. for answering so fast!
I created the objects with extracted poses and modified them with PME to get the needed parts. Therefore I used "thicken mesh by facenormals" then the knife tool in PME, "open seams" and "connect open points" commands (hope I translated this correctly) and changed the layered textures by "faces".
At a second view not all objects were rendered, after I had copied them in a new file (Screenshot_02_ 2023-07-17). After that I copied all the other objects in that same file, too. It came out, that now the render inverted the situation. (See Screenshot_02_2023-07-16.png and Screenshot_03_ 2023-07-17.png)
I try to append the older file with only the partly renderable objects. Edit
No importers, no script involved. Now I am continuously working with AoI 3.2.0 only. But I created the doublebass years ago, with AoI 2.9.2, I think, and worked it over with AoI 3.0.1, as far as I remember. Edit 2
I only tried to import the objects as "Wavefront to PolyMesh" into a new instance of a second AoI 3.2.0 installation, which dropped the error line of Screenshot_03_2023-07-16
I'll have to look into the "Magically disappearing objects" thing a little later - That might require some experimentation.
Regarding the .obj import error: was the .obj originally created with AOI? If so, from a polymesh or from a triangle mesh? Does it import cleanly into the trimesh style (built-in importer)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I developed the doublebass object in AoI with the PME and didn't ever change it to a trimesh, because it was said, that PME does this automatically for rendering. So I have no idea, wether the build-in importer would import it cleanly. For further work I tried to substitute the not working parts with new ones, I could get from the old model before it became an actor. So I copied the old doublebass object into the file with the animation. But the render didn't add this object too. (see left pic)
I also checked out what happens, if a renderable object is copied in a new instance of AoI that already contains an object that stayed not renderable in the new instance: It made the added object invisible in the render too. (See right pic)
To me it seems therefore the complete file is corrupted by something instead of the few objects. I'm hoping to find a way to save the work of the last 6 Month for bringing the filmproject closer to its completion yet.
I try to post the original file now ... full of hope ... but it is to large for upload here. If you need it to investigate, please contact me again by mail.
Thank you very much Maksim Khramov for finding out this workaround! It seems in fact to be valid even after bringing in the new (unsmothed) datas in the complete (old) scenery renderable. Great! I can go on working without loosing half a year of animation! :-) Thank you so much!!!!
Last edit: Konrad W. 2023-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I developed the doublebass object in AoI with the PME and didn't ever change it to a trimesh, because it was said, that PME does this automatically for rendering.
You are not supposed to convert a PolyMesh into a Triangle Mesh - that much is right, but PolyMesh does not "automatically create a TriangleMesh". Instead all the renderable object types (PolyMesh, TriangleMesh, SplineMesh, Cube, Sphere, Cylinder...) can produce a RenderingMesh that consists of triangles. The more the mesh is smoothed the more there are triangles. Rendering triangles have a lot of properties that the model geometry does not need.
To make things even more complicated, the Rendering meshes may be generated in different ways for interactive (modelling time) use and ray-tracing rendering of images:
Primitive objects use rendering meshes only during modelling. For ray-tracing rendering they use ray-tracing primitives (eg. RTSphere) so that they are rendered with the exact correct mathematical surface instead of triangles.
PolyMesh has a multi step smoothing process for ray-tracing rendering. It first generates a "QuadMesh" out of the geometry and then subdivides that into the final RenderingMesh.
And now we are getting closer to the problem.
The root cause here seems to be a combination of (and there is not smooth way of saying this) bad model quality and a point in the QuadMesh code that can not quite handle it.
Some of the edges of the problem objects look very messy to me and sometimes I could not tell what edge is connected to what in there. There seem to be collapsed and badly twisted polygons that probably create a mathematically impossible situation somewhere along the process. I tested this by cutting the wrinkled areas off some of the disappearing objects and they started to appear in the rendering. -- Only missing a piece, of course.
The attached picture is of the first object. I did the the same cut to both of the corners and it started to appear on the rendering.
In the QM code the error appears every time on the same line, 1191. There it calls a function previousVertex() (or something like that) directly in line, sending the result to an array as an index -- and in these cases the the index is -1, which is a impossible value to an array index. Even weirder, it seems to always be "-1 of 4001". This looks like it would require pretty detailed digging, but the fix might eventually be fairly simple .
Scene level changes to the Double Bass pieces do not get saved. After save and reopen the pieces are always set hidden and they have returned to their last coordinates. Save does not report any errors though. This is the case also with the pieces that can be rendered.
When I tested to convert some of the pieces into TriangeMesh form, the conversion did happen, but after saving, reopening and opening in editor, there are extra forms on them. In the case I looked at, the pieces had developed a very large "fractal" of the vertices. I was able to remove most of the fractal portion but then there were vertices that were not connected to the model at all and at least one that had no coordinates, appearing always at the left top corner of the view.
The above was done in AoI 3.2.0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Pete, for investing your time and skills to my problem, too!
Thank you also for adjusting and clearing my misunderstandings and lacks of knowlege.
You are right: a proper mesh does really not look like this over 10 years old one, I've modelled as a newbe to AoI. But all in all it seemed (and was for a long time) sufficient to the needs it was constructed for at first (a finally never finished still life with music instruments).
Thank you, AoI!
After starting the animation project with Klaus B., 7 years earlier from now, my laziness distracted me from revising the many bad parts of the mesh, because it rendered anyway. I just went on working with it until few days ago AoI said "Here is the essentially end to your experiments!"
Well, this might happen, if amateurs like myself, become misleaded to do things they really don't understand with an impatient desire, whipped up by a program like AoI ;-).
Many thanks to all of you for your help once more!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my laziness distracted me from revising the many bad parts of the mesh, because it rendered anyway.
"If it works don't fix it..." :D There really should not be a reason why the models wouldn't work any more.
Actually this RenderingMesh business is even more complicated that I thought. PME provides two ways of generating a RM. One through QuadMesh and one directly from PME (or so it seems).
What I could learn from the pieces so far is that the PolyMeshes seem to be logically intact. -- Matching numbers of vertices and edges for each face, no vertices used twice in on polygon ... but something goes wrong in the process of generating the derived meshes. Some of the pieces can not produce a QuadMesh and therefore a QuadCase RenderinMesh either but can produce the "old fashioned" RenderingMesh. Some the other way around. A problem with either of these seems to have the piece disappear from ray-tracing.
The mesh generation processes seem to have a kind of a built in system to catch mismatches but unfortunately there is are no routines to handle the information. What I'd like to see is that when there is an error, the process would just leave a hole in that spot an move to the next one instead of terminating the RM or QM generation entirely.
Last edit: Pete 2023-07-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"If it works don't fix it..." :D
Sorry, no, that really isn't my ambition ;-)
I'm very appreciating to participate in and profit by your knowleges and abilities :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"If it works don't fix it..." :D
Sorry, no, that really isn't my ambition ;-)
I'm very appreciating to participate in and profit by your knowleges and abilities :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try with the attached PolyMesh plugin. (Copy/move your current one somewhere safe first and put this one into your ArtOfIllusion/Plugins.)
The fix is about, what I said earlier about finding mismatches but not having a way to handle them. -- I still don't know what caused the problem but now it is (at least should be) recognized and handled.
in a couple of places in the QM smoothing algorithm . So it was a kind of half way done: The -1 already stands for not finding a proper result but that case was not handled in the calling part.
I'll need to take a closer look at the environment there, but I'll try to make it a PR in GitHub soonish. I'm not sure what kind of a condition my Git repositories are at the moment though...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so much, Pete, for this super fast awesome magic of yours! I tried the new PolyMesh.jar with the original "smoothed" file and it worked perfectly, as to be seen in the attached Render. Also copying into other files and rendering there works correctely! Great to know, that there are helpers like you to find here. Thank you Pete, thank you Luke S. and thank you Maksim Khramov!
Also copying into other files and rendering there works correctely!
What did you mean by this? You only needed to place the PolyMesh.jar to your Plugins folder once and it works with all the .aoi-files you handle in that Art of Illusion. -- Or are you using several installations of AoI?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using one AoI installation only. For animation I always create a separate file with only the necessary parts and some lowpoly dummies. When animation is done I copy it into the file, which contains all the objects of the final set. So the testing renders run faster. Of course you are right: Changeing the jar means the same for all files opened with. But after I had tested this badly for my second post here, I wanted to be shure that really all my AoI problems were gone from your wizardry, before answering here :-). Thank you very much once more!
Btw: You naturally are enlisted in the credits of this filmingproject yet, like the other wonderful helpers here and the father of AoI, Peter Eastman.
Last edit: Konrad W. 2023-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ Luke S: I pushed a fix into my Git fork but I did not PR it yet. I'm hoping to catch the actual glitch that causes the problem not just to patch it in the 'after math'. So far I have found that in some rare cases when a PolyMesh.Wvertex is converted into a QuadMesh.QuadVertex 3 or 4 vertex edges can become some 17000 vertex edges (typically the total amount of edges in the object + a few more).
EDITED: Still not sure of it all -->
The face number, the dummy edges are expected to belong to is not changing and when getPreviousVertex() goes to work, it naturally can not find vertices of edges that are not really connected to it.
I have managed to narrow the possibilities down so much that the error (or one error) must be in the QuadMesh.getVertexEdges() method. It uses while loops to count the connected edges, but somehow it fails to stop, when there should be no more edges to add.
Another question is where did the not-connected face come from? I was not able to find anything like disconnected vertices or other logical fails in the PolyMesh-objects, so I'd expect to find the origin of that somewhere in the same neighborhood with the edge count issue.
Now I'll need to do some code formatting. François has used a more compact style, than I'm used to. I'd expect a visually clearer structure to help to understand the logic a bit easier.
Last edit: Pete 2023-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So far I have found that in some rare cases when a PolyMesh.Wvertex is converted into a QuadMesh.QuadVertex 3 or 4 vertex edges can become some 17000 vertex edges (typically the total amount of edges in the object + a few more).
Okay, that would be interesting. Please look into documenting what kind of circumstances create these issues. Have you noticed any commonality between these kind of cases?
I'll need to do some code formatting. François has used a more compact style, than I'm used to. I'd expect a visually clearer structure to help to understand the logic a bit easier.
Please do this as a separate pass and commit before trying to make functional changes. I've reviewed some of the PolyMesh source files, and I'm not sure quite what you mean here. Quadmesh has some long if ()... else if ()... else if () chains that could probably be made more expressive, but it has some of the more consistently formatted code in the plugin base.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please look into documenting what kind of circumstances create these issues. Have you noticed any commonality between these kind of cases?
So far I don't even properly understand the process and I have no idea what triggers the problem .... There seem to be a couple of different ways it appears though. But I can tell that some parts here could take a redesign. I get the feeling that this design is a kind of unfinished.
Please do this as a separate pass and commit
That was the plan. The code is pretty consistent but here and there a bit messy in my eyes. Just what you say about the else ifs... :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the not connected faces (and points) of the objects may be helpful to know the genesis of these: I took several copies of the original "doublebass" object, one for each piece I needed. In these copies then I canceled those parts of the Mesh I would not need in the present copy. I opended some edges as seams and extruded the remaining parts in negative facenormals direction for the "new" object to keep the "outer" shape of it. In a second step 5 objects were then copied again and newly splitted by using the knife tool of PME, especially close to those parts which are containing the bad parts of the original mesh I started with. I simply lost overview whether I had cancelled every face or point I wouldn't need. Edit: The open edges of the meshes were closed by connecting points.
Last edit: Konrad W. 2023-07-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those things sound like pretty normal things to do. I wrote a couple of scripts to study the mesh and at least the scripts did not find anything logically wrong with the meshes I has a look at. The scripts did not check any geometrical conditions like sharp of inverted edges though.
The problem then occurs somewhere in the smoothing process in a sequence that again works with logical rules only, just checking what is connected where. The thing that causes the problem must be somewhere before that point and it may be of geometrical nature. It just may be than there is not much that can be done to it but to keep the filters that I added. I'll keep tracking it back a bit more. The difficulty is that I have no idea what I'm looking for.
In the code it looks like François had been aware that something like this could happen because the code was already built to notice the problem. It just did not handle it, which after all was an easy thing to add.
Last edit: Pete 2023-07-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a longer look at the code last night and it felt like I had ran into a very unfinished construction site. I had the code "sprinkle breadcrumbs" behind, so I could follow where it has been and it turns out that especially in QuadMesh there are parts that are never used, but I can not necessarily tell if they are development branches or abandoned code. Though some test bits have been commented out entirely so they might have been the next development phase. Also, there are quite a few debugging lines both in PM and QM and both, active and commented out.
Looking at the QM code I get the feeling that it may not be the most effective kind of code but in the other hand mesh smoothing is complex and all the possible combinations of user definitions need to be taken notice of.
So finding the actual glitch in the code will now have to go into the long list of things to do someday.... -- Some subtle cues though seem to imply, that there might be "NaN-vectors" involved... (Meaning, there is a division by zero somewhere resulting NaN as a coordinate value ... If it is that, it at least seems to be well contained and not polluting the entire model, as I recall happening in another case some year ago.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Edit by copying the objects in a new file not all were rendered.
Edit 2 The problem continues. See my next post.
Edit 3 Sorry for canceling my first post, when I thought I got the problems fixed ...
Last edit: Konrad W. 2023-07-17
Were your objects created in an unusual way? One of the less-used importers? Generated by script?
Were you trading files between different versions of AOI?
Last edit: Luke S 2023-07-17
Thank you Luke S. for answering so fast!
I created the objects with extracted poses and modified them with PME to get the needed parts. Therefore I used "thicken mesh by facenormals" then the knife tool in PME, "open seams" and "connect open points" commands (hope I translated this correctly) and changed the layered textures by "faces".
At a second view not all objects were rendered, after I had copied them in a new file (Screenshot_02_ 2023-07-17). After that I copied all the other objects in that same file, too. It came out, that now the render inverted the situation. (See Screenshot_02_2023-07-16.png and Screenshot_03_ 2023-07-17.png)
I try to append the older file with only the partly renderable objects.
Edit
No importers, no script involved. Now I am continuously working with AoI 3.2.0 only. But I created the doublebass years ago, with AoI 2.9.2, I think, and worked it over with AoI 3.0.1, as far as I remember.
Edit 2
I only tried to import the objects as "Wavefront to PolyMesh" into a new instance of a second AoI 3.2.0 installation, which dropped the error line of Screenshot_03_2023-07-16
Last edit: Konrad W. 2023-07-17
I'll have to look into the "Magically disappearing objects" thing a little later - That might require some experimentation.
Regarding the .obj import error: was the .obj originally created with AOI? If so, from a polymesh or from a triangle mesh? Does it import cleanly into the trimesh style (built-in importer)?
I developed the doublebass object in AoI with the PME and didn't ever change it to a trimesh, because it was said, that PME does this automatically for rendering. So I have no idea, wether the build-in importer would import it cleanly. For further work I tried to substitute the not working parts with new ones, I could get from the old model before it became an actor. So I copied the old doublebass object into the file with the animation. But the render didn't add this object too. (see left pic)
I also checked out what happens, if a renderable object is copied in a new instance of AoI that already contains an object that stayed not renderable in the new instance: It made the added object invisible in the render too. (See right pic)
To me it seems therefore the complete file is corrupted by something instead of the few objects. I'm hoping to find a way to save the work of the last 6 Month for bringing the filmproject closer to its completion yet.
I try to post the original file now ... full of hope ... but it is to large for upload here. If you need it to investigate, please contact me again by mail.
Last edit: Konrad W. 2023-07-17
Probably this is a workaround....
If change Polymesh objects Smoothing from Approximating to None, the objects starts to render
Thank you very much Maksim Khramov for finding out this workaround! It seems in fact to be valid even after bringing in the new (unsmothed) datas in the complete (old) scenery renderable. Great! I can go on working without loosing half a year of animation! :-) Thank you so much!!!!
Last edit: Konrad W. 2023-07-18
You are not supposed to convert a PolyMesh into a Triangle Mesh - that much is right, but PolyMesh does not "automatically create a TriangleMesh". Instead all the renderable object types (PolyMesh, TriangleMesh, SplineMesh, Cube, Sphere, Cylinder...) can produce a RenderingMesh that consists of triangles. The more the mesh is smoothed the more there are triangles. Rendering triangles have a lot of properties that the model geometry does not need.
To make things even more complicated, the Rendering meshes may be generated in different ways for interactive (modelling time) use and ray-tracing rendering of images:
And now we are getting closer to the problem.
The root cause here seems to be a combination of (and there is not smooth way of saying this) bad model quality and a point in the QuadMesh code that can not quite handle it.
Some of the edges of the problem objects look very messy to me and sometimes I could not tell what edge is connected to what in there. There seem to be collapsed and badly twisted polygons that probably create a mathematically impossible situation somewhere along the process. I tested this by cutting the wrinkled areas off some of the disappearing objects and they started to appear in the rendering. -- Only missing a piece, of course.
The attached picture is of the first object. I did the the same cut to both of the corners and it started to appear on the rendering.
In the QM code the error appears every time on the same line, 1191. There it calls a function
previousVertex()(or something like that) directly in line, sending the result to an array as an index -- and in these cases the the index is -1, which is a impossible value to an array index. Even weirder, it seems to always be "-1 of 4001". This looks like it would require pretty detailed digging, but the fix might eventually be fairly simple .EDIT: Forgot the picture... Added.
Last edit: Pete 2023-07-20
Some testing:
Scene level changes to the Double Bass pieces do not get saved. After save and reopen the pieces are always set hidden and they have returned to their last coordinates. Save does not report any errors though. This is the case also with the pieces that can be rendered.
When I tested to convert some of the pieces into TriangeMesh form, the conversion did happen, but after saving, reopening and opening in editor, there are extra forms on them. In the case I looked at, the pieces had developed a very large "fractal" of the vertices. I was able to remove most of the fractal portion but then there were vertices that were not connected to the model at all and at least one that had no coordinates, appearing always at the left top corner of the view.
The above was done in AoI 3.2.0
Thank you Pete, for investing your time and skills to my problem, too!
Thank you also for adjusting and clearing my misunderstandings and lacks of knowlege.
You are right: a proper mesh does really not look like this over 10 years old one, I've modelled as a newbe to AoI. But all in all it seemed (and was for a long time) sufficient to the needs it was constructed for at first (a finally never finished still life with music instruments).
Thank you, AoI!
After starting the animation project with Klaus B., 7 years earlier from now, my laziness distracted me from revising the many bad parts of the mesh, because it rendered anyway. I just went on working with it until few days ago AoI said "Here is the essentially end to your experiments!"
Well, this might happen, if amateurs like myself, become misleaded to do things they really don't understand with an impatient desire, whipped up by a program like AoI ;-).
Many thanks to all of you for your help once more!
"If it works don't fix it..." :D There really should not be a reason why the models wouldn't work any more.
Actually this RenderingMesh business is even more complicated that I thought. PME provides two ways of generating a RM. One through QuadMesh and one directly from PME (or so it seems).
What I could learn from the pieces so far is that the PolyMeshes seem to be logically intact. -- Matching numbers of vertices and edges for each face, no vertices used twice in on polygon ... but something goes wrong in the process of generating the derived meshes. Some of the pieces can not produce a QuadMesh and therefore a QuadCase RenderinMesh either but can produce the "old fashioned" RenderingMesh. Some the other way around. A problem with either of these seems to have the piece disappear from ray-tracing.
The mesh generation processes seem to have a kind of a built in system to catch mismatches but unfortunately there is are no routines to handle the information. What I'd like to see is that when there is an error, the process would just leave a hole in that spot an move to the next one instead of terminating the RM or QM generation entirely.
Last edit: Pete 2023-07-21
"If it works don't fix it..." :D
Sorry, no, that really isn't my ambition ;-)
I'm very appreciating to participate in and profit by your knowleges and abilities :-)
"If it works don't fix it..." :D
Sorry, no, that really isn't my ambition ;-)
I'm very appreciating to participate in and profit by your knowleges and abilities :-)
I think I got it!
Try with the attached PolyMesh plugin. (Copy/move your current one somewhere safe first and put this one into your ArtOfIllusion/Plugins.)
The fix is about, what I said earlier about finding mismatches but not having a way to handle them. -- I still don't know what caused the problem but now it is (at least should be) recognized and handled.
Let me know it it works!
EDIT: - edit withdrawn -
Last edit: Pete 2023-07-22
Thank you for looking into this, Pete! I honestly haven't had a chance to do much of anything with AOI over the last few days.
How big a change did it take?
Actually only
in a couple of places in the QM smoothing algorithm . So it was a kind of half way done: The -1 already stands for not finding a proper result but that case was not handled in the calling part.
I'll need to take a closer look at the environment there, but I'll try to make it a PR in GitHub soonish. I'm not sure what kind of a condition my Git repositories are at the moment though...
Thank you so much, Pete, for this super fast awesome magic of yours! I tried the new PolyMesh.jar with the original "smoothed" file and it worked perfectly, as to be seen in the attached Render. Also copying into other files and rendering there works correctely! Great to know, that there are helpers like you to find here. Thank you Pete, thank you Luke S. and thank you Maksim Khramov!
I'm glad it worked, but:
What did you mean by this? You only needed to place the PolyMesh.jar to your Plugins folder once and it works with all the .aoi-files you handle in that Art of Illusion. -- Or are you using several installations of AoI?
I'm using one AoI installation only. For animation I always create a separate file with only the necessary parts and some lowpoly dummies. When animation is done I copy it into the file, which contains all the objects of the final set. So the testing renders run faster. Of course you are right: Changeing the jar means the same for all files opened with. But after I had tested this badly for my second post here, I wanted to be shure that really all my AoI problems were gone from your wizardry, before answering here :-). Thank you very much once more!
Btw: You naturally are enlisted in the credits of this filmingproject yet, like the other wonderful helpers here and the father of AoI, Peter Eastman.
Last edit: Konrad W. 2023-07-23
OK and thanks. :)
@ Luke S: I pushed a fix into my Git fork but I did not PR it yet. I'm hoping to catch the actual glitch that causes the problem not just to patch it in the 'after math'. So far I have found that in some rare cases when a
PolyMesh.Wvertexis converted into aQuadMesh.QuadVertex3 or 4 vertex edges can become some 17000 vertex edges (typically the total amount of edges in the object + a few more).EDITED: Still not sure of it all -->
The face number, the dummy edges are expected to belong to is not changing and when
getPreviousVertex()goes to work, it naturally can not find vertices of edges that are not really connected to it.I have managed to narrow the possibilities down so much that the error (or one error) must be in the
QuadMesh.getVertexEdges()method. It uses while loops to count the connected edges, but somehow it fails to stop, when there should be no more edges to add.Another question is where did the not-connected face come from? I was not able to find anything like disconnected vertices or other logical fails in the PolyMesh-objects, so I'd expect to find the origin of that somewhere in the same neighborhood with the edge count issue.
Now I'll need to do some code formatting. François has used a more compact style, than I'm used to. I'd expect a visually clearer structure to help to understand the logic a bit easier.
Last edit: Pete 2023-07-23
Okay, that would be interesting. Please look into documenting what kind of circumstances create these issues. Have you noticed any commonality between these kind of cases?
Please do this as a separate pass and commit before trying to make functional changes. I've reviewed some of the PolyMesh source files, and I'm not sure quite what you mean here.
Quadmeshhas some longif ()... else if ()... else if ()chains that could probably be made more expressive, but it has some of the more consistently formatted code in the plugin base.So far I don't even properly understand the process and I have no idea what triggers the problem .... There seem to be a couple of different ways it appears though. But I can tell that some parts here could take a redesign. I get the feeling that this design is a kind of unfinished.
That was the plan. The code is pretty consistent but here and there a bit messy in my eyes. Just what you say about the else ifs... :)
For the not connected faces (and points) of the objects may be helpful to know the genesis of these: I took several copies of the original "doublebass" object, one for each piece I needed. In these copies then I canceled those parts of the Mesh I would not need in the present copy. I opended some edges as seams and extruded the remaining parts in negative facenormals direction for the "new" object to keep the "outer" shape of it. In a second step 5 objects were then copied again and newly splitted by using the knife tool of PME, especially close to those parts which are containing the bad parts of the original mesh I started with. I simply lost overview whether I had cancelled every face or point I wouldn't need.
Edit: The open edges of the meshes were closed by connecting points.
Last edit: Konrad W. 2023-07-24
Those things sound like pretty normal things to do. I wrote a couple of scripts to study the mesh and at least the scripts did not find anything logically wrong with the meshes I has a look at. The scripts did not check any geometrical conditions like sharp of inverted edges though.
The problem then occurs somewhere in the smoothing process in a sequence that again works with logical rules only, just checking what is connected where. The thing that causes the problem must be somewhere before that point and it may be of geometrical nature. It just may be than there is not much that can be done to it but to keep the filters that I added. I'll keep tracking it back a bit more. The difficulty is that I have no idea what I'm looking for.
In the code it looks like François had been aware that something like this could happen because the code was already built to notice the problem. It just did not handle it, which after all was an easy thing to add.
Last edit: Pete 2023-07-25
I PR:ed the fix in GitHub.
I had a longer look at the code last night and it felt like I had ran into a very unfinished construction site. I had the code "sprinkle breadcrumbs" behind, so I could follow where it has been and it turns out that especially in QuadMesh there are parts that are never used, but I can not necessarily tell if they are development branches or abandoned code. Though some test bits have been commented out entirely so they might have been the next development phase. Also, there are quite a few debugging lines both in PM and QM and both, active and commented out.
Looking at the QM code I get the feeling that it may not be the most effective kind of code but in the other hand mesh smoothing is complex and all the possible combinations of user definitions need to be taken notice of.
So finding the actual glitch in the code will now have to go into the long list of things to do someday.... -- Some subtle cues though seem to imply, that there might be "NaN-vectors" involved... (Meaning, there is a division by zero somewhere resulting NaN as a coordinate value ... If it is that, it at least seems to be well contained and not polluting the entire model, as I recall happening in another case some year ago.)