Fixed handling of PLY with vertex colors as uchar #1441
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
added 5 commits
November 17, 2023 07:29
Matching the normalization of integral types to what Blender does. e.g. int8 is divided by 127, uint8 is divided by 255, etc. https://github.com/blender/blender/blob/01a2bd03695f217616acc2581fe8746f5cd226d7/source/blender/io/ply/importer/ply_import_data.cc#L104 https://github.com/blender/blender/blob/01a2bd03695f217616acc2581fe8746f5cd226d7/source/blender/io/ply/intern/ply_data.hh#L16
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.
When a PLY model has vertex colors, they're typically saved as uchar rather than float properties.
For example, exporting a mesh with vertex colors from Blender will write it with uchar red, green, blue, and alpha properties.
Currently, Yocto is reading colors by casting to float without dividing uchar by 255. So the colors come out wrong.
This patch changes the logic to ensure that when colors are read, it will normalize any integral type to a floating point value. I didn't really find anything in PLY spec that defines the "right" way to normalize the various integral types, so this is just a best guess (that happens to work well for uint8). I can try to simplify this patch if we don't want to do general normalization and just handle uint8.
I created a PLY in Blender to test this, with a sample scene (materials5).
This is what the render looks like before the patch:
And this is after:
