You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would be a good first step to writing mesh upload code totally independent of the viewer, allowing prototyping of new importer features like glTF support (via https://github.com/SaladDais/impasse,) as well as file watchers for the local mesh feature.
Having code to allow round-tripping LLMesh -> Collada -> LLMesh is probably the easiest way to ensure we haven't gotten confused about LLMesh or Collada semantics in our import code.
We should make an example .dae that uses joint positions, vertex weights, multiple materials and multiple instances of the same mesh data, and then log the LLMesh-serialized version the viewer's uploader sends off to make sure that:
Our own conversion code gives the same result as the viewer when converting the .dae to LLMesh (assuming no normal or LoD generation)
Our LLMesh upload data -> Collada converter generates a .dae that's semantically equivalent to the original input .dae
The text was updated successfully, but these errors were encountered:
There's a basic version of LLMesh -> Collada in https://github.com/SaladDais/Hippolyzer/blob/master/hippolyzer/lib/base/colladatools.py, and I have a very very basic version of .fbx and .gltf -> LLMesh conversion and upload using assimp working in a local branch. Upload of basic mesh without rigging from .fbx seems to mostly work, with UVs and normals correctly handled.
Still need to figure out the exact deal with the transforms SL does on mesh data on upload, even with my mesh manually resized to fit within a 1m cubed bounding box I'm still getting slightly different results than SL's uploader. Will start to add round-tripping tests once I've figured that out.
This would be a good first step to writing mesh upload code totally independent of the viewer, allowing prototyping of new importer features like glTF support (via https://github.com/SaladDais/impasse,) as well as file watchers for the local mesh feature.
Having code to allow round-tripping LLMesh -> Collada -> LLMesh is probably the easiest way to ensure we haven't gotten confused about LLMesh or Collada semantics in our import code.
We should make an example .dae that uses joint positions, vertex weights, multiple materials and multiple instances of the same mesh data, and then log the LLMesh-serialized version the viewer's uploader sends off to make sure that:
.dae
to LLMesh (assuming no normal or LoD generation).dae
that's semantically equivalent to the original input.dae
The text was updated successfully, but these errors were encountered: