it took 1 user to report each bug, 1 developer to recognize and "fix" it.
In case of 3460978 really there were no bug at all, just a false bug report -
the reporter did not provide a test model file and when "confronted" by me in bug report comments retracted his claim.
In case of 3429812 it seems the original bug was genuine, but so is the side-effect of the fix.
If the correct route is to file a new bug report, referencing the incorrectly fixed one as the cause of the problem -
I'll do just that.
As a side note - there seems to be not that many users here on the forums, so it is strange to expect that the effects of the bugs will result in many posts.
But effects of 3460978 resulted in complaints at https://sourceforge.net/projects/assimp/forums/forum/817654/topic/6057622
In that thread you mention "a couple of users" who wanted the change.
As I have already told you, the 3460978 bug reporter was not that sure what he really wanted,
so that may be just 1 person (please, give a reference to his complaint).
In any case, me and Duarte Peixinho from that thread also make "a couple of users".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please, revisit bug report 57 (https://sourceforge.net/p/assimp/bugs/57/), former 3460978.
I believe that was a false alarm, fixed in haste with no useful and some harmful effects.
People are complaining about the effects of the evil fix (https://sourceforge.net/p/assimp/discussion/817654/thread/1292c7c3/), but are ignored.
Sincerely, Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please check the github-page, we just have released 3.1 . Unfortunately we haven't released the pre-build binaries here. I will release the source package today.
Kimmi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the problem I complain about was not affected by the release.
Let me remind you: someone wrote a baseless complaint, some developer applied an ugly fix (I believe he just did not concentrate on Assimp at that moment) - and no developer can be bothered to look into that since.
The details are in the bug report 57, but what I ask for boils down to removing from ObjFileParser.cpp of the "Each material request a new object" section, since the design of Assimp demands that material change can trigger creation of a new Mesh, not a new Model.
Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the name may be misleading, since the initial complaint about 3429812 fix has been satisfied. On the other hand, if the replacement code is considered poor by the developers (not elimination of an error, but a workaround, for example), the name of the bug remains correct (in line with existence of bug 67 https://sourceforge.net/p/assimp/bugs/67/ )
Sincerely, Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you're right, I missed this one, sorry for that. I will try to bring it into the next bugfix release.
But itt seems you did not.
Let me remind you: someone wrote a baseless complaint, some developer applied an ugly fix (I believe he just did not concentrate on Assimp at that moment) - and no developer can be bothered to look into that since.
The details are in the bug report 57, but what I ask for boils down to removing from ObjFileParser.cpp of the "Each material request a new object" section, since the design of Assimp demands that material change can trigger creation of a new Mesh, not a new Model.
Dear Developers,
that bugs were fixed with negative side effects,
that are described in my comments to corresponding bug reports.
Please, consider reversing or changing the fixes.
Sincerely, Michail
Dear Developers,
I reiterate
> that bugs were fixed with negative side effects,
> that are described in my comments to corresponding bug reports.
Please, now that some activity seems to resume after the 3.0 release, consider reversing or changing the fixes.
Sincerely, Michail
How much people have recocnized the same negative side effects?
Kimmi
Dear Kimmi,
it took 1 user to report each bug, 1 developer to recognize and "fix" it.
In case of 3460978 really there were no bug at all, just a false bug report -
the reporter did not provide a test model file and when "confronted" by me in bug report comments retracted his claim.
In case of 3429812 it seems the original bug was genuine, but so is the side-effect of the fix.
If the correct route is to file a new bug report, referencing the incorrectly fixed one as the cause of the problem -
I'll do just that.
As a side note - there seems to be not that many users here on the forums, so it is strange to expect that the effects of the bugs will result in many posts.
But effects of 3460978 resulted in complaints at
https://sourceforge.net/projects/assimp/forums/forum/817654/topic/6057622
In that thread you mention "a couple of users" who wanted the change.
As I have already told you, the 3460978 bug reporter was not that sure what he really wanted,
so that may be just 1 person (please, give a reference to his complaint).
In any case, me and Duarte Peixinho from that thread also make "a couple of users".
Bug reporting is not a popularity contest. I'm going to nudge Aramis again, he wrote the current triangulation. Thanks for the test data!
Of course not. But if I get the number of recocnitions I can priorize it much easily. Special with the time I currently have.
Kimmi
Dear Developers,
please, revisit bug report 57 (https://sourceforge.net/p/assimp/bugs/57/), former 3460978.
I believe that was a false alarm, fixed in haste with no useful and some harmful effects.
People are complaining about the effects of the evil fix (https://sourceforge.net/p/assimp/discussion/817654/thread/1292c7c3/), but are ignored.
Sincerely, Michail
HI,
thanks for the hint, again :-(. We will find a way. See: https://github.com/assimp/assimp/issues/173
Kimmi
Dear Kimmi,
given that on 2014-02-28 you wrote:
We are planing to release a new version in the next weeks.
Now it may be a right time to deliver on your promise to find a way to revisit bug report 57 (and reverse a harmful fix for a nonexistent bug).
Michail
Hi,
please check the github-page, we just have released 3.1 . Unfortunately we haven't released the pre-build binaries here. I will release the source package today.
Kimmi
Dear Kimmi,
the problem I complain about was not affected by the release.
Let me remind you: someone wrote a baseless complaint, some developer applied an ugly fix (I believe he just did not concentrate on Assimp at that moment) - and no developer can be bothered to look into that since.
The details are in the bug report 57, but what I ask for boils down to removing from ObjFileParser.cpp of the "Each material request a new object" section, since the design of Assimp demands that material change can trigger creation of a new Mesh, not a new Model.
Michail
Dear Kimmi,
as a side note: the original fix for bug 3429812, that broke things badly, has since been replaced by other code. (See https://sourceforge.net/p/assimp/discussion/817654/thread/9cbc5b0c/ for a bug discussion likely reflecting the effect of the replacement.)
So the name may be misleading, since the initial complaint about 3429812 fix has been satisfied. On the other hand, if the replacement code is considered poor by the developers (not elimination of an error, but a workaround, for example), the name of the bug remains correct (in line with existence of bug 67 https://sourceforge.net/p/assimp/bugs/67/ )
Sincerely, Michail
Hi,m
you're right, I missed this one, sorry for that. I will try to bring it into the next bugfix release. feel free to offer a pull request.
Kimmi
Dear Kimmi,
you wrote:
But itt seems you did not.
Let me remind you: someone wrote a baseless complaint, some developer applied an ugly fix (I believe he just did not concentrate on Assimp at that moment) - and no developer can be bothered to look into that since.
The details are in the bug report 57, but what I ask for boils down to removing from ObjFileParser.cpp of the "Each material request a new object" section, since the design of Assimp demands that material change can trigger creation of a new Mesh, not a new Model.
Please, revisit bug report 57 (https://sourceforge.net/p/assimp/bugs/57/)
Sincerely, Michail