Collada bug #31
Merged
Collada bug #31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As a newbie to Kotlin, kotlin-graphics/assimp, and Assimp in general, any guidance on what is needed, how things are done, is appreciated.
commit 301d1ae
Repair readMaterialLibrary's handling of duplicate names.
The native Assimp's ColladaParser::ReadMaterialLibrary has, to my mind, an excessive use of high power machinery obscuring both the intent and the actual action. The initial translation to Kotlin missed a bit of syntactic cleverness, resulting in an array bounds exception. If three Collada elements have name="Mary", the action is to name the material library entries "Mary, "Mary 1", and "Mary 2".
Test by manually editing a Collada .dae file and just duplicate one of the
elements.
commit 15bae11
Repair fallback texture CHANNEL guess.
This failure was exposed by a Collada file that actually fell to this fallback calculation of the texture channel number. But the coding resulted in the ASCII code for
'0'.
commit 2ff8c85
Propagate Collada import failure info through to user as importer.errorString.
The exception thrown because of a duplicate resulted in readFile returning scene=null, but then getErrorString() returned "", and calling from Java invoked under NetBeans, the traceback did not appear anywhere obvious. Even though that exception is now quieted, tracking it down revealed that any unexpected exception in the Collada loader would be caught in BaseImporter where the exception's message was passed to the logger but not copied through to Importer.errorString where the user could get it.
My solution is to catch unexpected exceptions in the Collada loader and pass on a message that at least indicates where in the input the problem occurred, and then to put the resulting message where it gets copied to where the user expects a problem report. Checking other exceptions, from Collada loader or elsewhere, seems futile, not not on board with the directive to to the right thing with correct input and spend no significant effort on verifying compliance of the input data.