dev2 three.json SkinnedMesh loading w.i.p. #79
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.
WIP for implementing #78 - see motivation and info about the test for this etc. there.
Not ready to merge but am opening for discussion.
Had to disable material setting in
EC_Mesh_ThreeJs
as it overrode the material from the three.jsonI think overall with the current
EC_Mesh_ThreeJs
implementation, the skeleton & material ref handling codes there, there's a bit of a conflict with the three json (and gltf and others) mesh format where the same file includes skels and animations.dev2
EC_Mesh_ThreeJs
is written for Ogre assets where those are separate. Thus much of the EC impl is dealing with loading those other files and applying them etc.If we recommend use of Three assets, and don't even have the Ogre asset loading available, one way would be indeed to just remove those parts that overwrite the loaded material now. But that may make things difficult for where Ogre assets are used so perhaps what's needed is to make
EC_Mesh_ThreeJs
somehow work for both cases: not overwrite with default white when the mesh already has the correct material.I'll check if can do that next but am open for other ideas too. If this one EC impl becomes too complex while handling both cases, perhaps the Ogre things could be moved to some
EC_Mesh_ThreeJsFromOgreAssets
class or so. But perhaps a simple check for existing material does it simply enough.Also, the animation data seemed to be lost somewhere -- am not sure if that's due to the ancient three.js in dev2 still (r62 vs 72dev with which have tested the deer export now otherwise) or if something in the loading & ec mechanism still overrides that.