Hi margelo Team,
I’ve been experimenting with adding VRM / VRMA support to react-native-filament and wanted to share a proof-of-concept I’ve been working on:
🔗 Proposal & Demo: https://github.com/CS6/react-native-filament-VRM
Just a heads-up: This is an AI-assisted prototype meant for discussion, not a production-ready PR!!!!!!!
If the maintainers and the community are interested in pursuing this, I am more than willing to invest my time into developing this as an official/community addon.
I would love to do this under your guidance and architecture guidelines to ensure the code aligns perfectly with the project's standards and long-term vision.
I’m opening this to kickstart a conversation about the architectural direction. Specifically, should VRM support be built directly into the core package, or should we expose lower-level APIs so it can live in a separate addon? Since this implementation required some changes to the core (like native/C++ bridge access for Filament material texture transform metadata), I'd love to get your thoughts before turning this into a real PR.
To show what's possible, the current demo (using official sample assets) already covers a wide range of features:
VRM 0.x / 1.0 humanoid & VRMA animation retargeting
External glTF/GLB animations with explicit humanoid mapping
VRM expressions (morph targets, VRM 1.0 material color/texture transform binds)
Override rules (overrideBlink, etc.) and LookAt behavior
VRMC_node_constraint and VRMC_springBone physics
Material fallbacks for unsupported VRM/MToon paths
Looking forward to hearing your feedback and finding the best way to approach this!
Hi margelo Team,
I’ve been experimenting with adding VRM / VRMA support to react-native-filament and wanted to share a proof-of-concept I’ve been working on:
🔗 Proposal & Demo: https://github.com/CS6/react-native-filament-VRM
Just a heads-up: This is an AI-assisted prototype meant for discussion, not a production-ready PR!!!!!!!
If the maintainers and the community are interested in pursuing this, I am more than willing to invest my time into developing this as an official/community addon.
I would love to do this under your guidance and architecture guidelines to ensure the code aligns perfectly with the project's standards and long-term vision.
I’m opening this to kickstart a conversation about the architectural direction. Specifically, should VRM support be built directly into the core package, or should we expose lower-level APIs so it can live in a separate addon? Since this implementation required some changes to the core (like native/C++ bridge access for Filament material texture transform metadata), I'd love to get your thoughts before turning this into a real PR.
To show what's possible, the current demo (using official sample assets) already covers a wide range of features:
VRM 0.x / 1.0 humanoid & VRMA animation retargeting
External glTF/GLB animations with explicit humanoid mapping
VRM expressions (morph targets, VRM 1.0 material color/texture transform binds)
Override rules (overrideBlink, etc.) and LookAt behavior
VRMC_node_constraint and VRMC_springBone physics
Material fallbacks for unsupported VRM/MToon paths
Looking forward to hearing your feedback and finding the best way to approach this!