Closed hietalajulius closed 3 years ago
On my scene, it prints "No mesh vertex color data found", but the colors actually render just fine.
Ah yeah, that's most likely when loading the control arrow mesh 😅 Agreed that we should only catch the appropriate error there, maybe also that colors would be gotten for the integrated.ply and not others.
Changed the vertex colors to be stored in a matrix vs vector and now checking for colors is explicit vs catching all errors :+1:
Alpha from u_color:![Screenshot from 2021-04-29 10-58-31](https://user-images.githubusercontent.com/4254623/116519195-df244d80-a8d9-11eb-9b83-72115dcb41bd.png)
Alpha from mesh:![Screenshot from 2021-04-29 10-58-29](https://user-images.githubusercontent.com/4254623/116519207-e21f3e00-a8d9-11eb-93a0-94e0f853b437.png)
Here's a proposal for the colored mesh implementation, might be rough around the edges. Things to point out/address/agree:
fs_mesh_uniform
fs_mesh_colors
) and programs (colorProgram
uniformProgram
) inmesh_view
. Thefs_mesh_colors.sc
still takes its alpha value fromu_color
. Is this approach sensible overall? This does not address the fact yet that maybe the shaders should only be compiled once (translate does that too now), but maybe worth a separate PR.ColoredMesh
etc class. This assumes that whether colors are available in the mesh should (?) be determined during runtime (for example the bunny.ply fixture does not have colors but probably nice not to crash because of that).object->mesh->colorsFromFile
inmesh_view
might be a bit so and so, the approach accessing that state in a "view" should get clarity once we lock more details on the architecture