The current glTF loader in Babylon Lite always loads and decodes resources using browser APIs (fetch, Blob, and createImageBitmap).
This works well on the Web, but it also assumes that resources are addressable through URLs that can be fetched. On platforms such as React Native (or Expo), local assets are often represented by platform-specific asset objects rather than directly fetchable URLs. Likewise, image decoding may already be provided by a native pipeline instead of going through Blob and createImageBitmap().
I’m currently testing Babylon Lite with React Native and need to customize these parts of the loader.
Before implementing anything, I’d like to ask what the preferred direction would be.
Would you prefer:
-
adding small extension points (for example for resource loading and/or image decoding) while keeping the default Web behavior unchanged; or
-
keeping the loader Web-specific and expecting platforms to maintain their own fork or custom loader?
I’d be happy to submit a PR if the first approach aligns with the project’s goals.
@Deltakosh This isn’t exactly a native question. It’s more a Lite glTF loader extensibility question. I’m assuming we are talking about using react-native-webgpu.
Maybe @ryantrem has thoughts on this.
We are working on Babylon Lite with Babylon Native and thus Babylon React Native but this is a different solution than using react-native-webgpu.
WebGPU is increasingly being used outside of browsers as well (React Native, Flutter experiments, native applications built on Dawn/wgpu, etc.), where these browser APIs may not be the most appropriate integration points.
One reason I’m asking is that this isn’t my first attempt to use Babylon in a non-browser WebGPU environment.
In the past, I tried using Babylon.js in a similar context, but I found that it essentially operated in one of two modes: browser or Babylon Native. Each mode has its own assumptions and internal behavior, but those behaviors aren’t really configurable from the outside.
As an application developer, there isn’t much opportunity to customize these decisions without modifying engine code.
That’s why I’m wondering whether Babylon Lite could expose a few small extension points instead of assuming a specific platform. My goal isn’t to make Lite React Native-specific, but to make it easier to integrate with any WebGPU runtime that isn’t running in a browser while keeping the current browser implementation as the default.
Well, WebGPU itself is already a browser-centric API. If having an implementation in React Native is the solution for that Lite API dependency, then it seems reasonable that the solution for those smaller cases would be the same - implement a React Native module that provides those APIs. It seems like what you might be suggesting when you say “extension points” is effectively a thin abstraction over things like fetch etc. That is architecturally quite different from just implementing the WebAPI (eg WebGPU) in the target environment (eg React Native). If you are going to provide a custom implementation anyway, why not just implement the WebAPI, which can also benefit the whole React Native community? The other issue with abstractions is that they tend to add layers that can negatively impact perf and bundle size.
Thank you very much for all your replies. They gave me a lot to think about.
After considering the different approaches, I’ve come to the conclusion that asset loading is really something that should be implemented by the target platform.
It’s not just about filling in a few missing Web APIs (which isn’t always possible with Expo anyway). It also involves the whole asset pipeline: resource loading, image decoding (JPEG, PNG), texture transcoding (KTX2/Basis), mesh decompression (Draco, Meshopt), and potentially other platform-specific optimizations.
Given that, I think the best approach for my use case is to build a dedicated loader outside of Babylon Lite, rather than trying to extend the Lite loader to support these platform-specific concerns.
Thanks again for taking the time to discuss this with me and for sharing your perspective.