Show HN: Thermion, an open source 3D rendering toolkit for Flutter and/or Dart (thermion.dev)
This came about when I needed a 3D renderer for a Flutter app[0] I was building. At the time, the only off-the-shelf option was to embed Unity, which wasn't ideal for a few reasons - unstable build process, compositing and transparency issues, and licensing uncertainty, just to name a few. In any event, frankensteining Unity (C#) together with Flutter (Dart) didn't seem like a great solution.
After browsing for alternative renderers, I discovered Filament[1], an open-source, cross-platform Physically Based Rendering engine from Google. I initially only wrote some simple bindings to embed Filament inside a Flutter Android/iOS app, but have since added more functionality, and have expanded this to cover Windows, MacOS and Web (there was Linux support at one point, too, but I haven't been keeping up with it I'm afraid).
Last week I published the first Thermion release to pub.dev[2], and with that milestone it seemed a good time to share with HN. This is also a call for contributors if anyone wants to help[3].
Some examples:
- A live DartPad playground so you can try the Dart-only (i.e. non-Flutter version) of Thermion in browser (Chrome only for now). https://dartpad.thermion.dev
- My personal website, where I added an interactive clone of myself https://nick-fisher.com
- Prouder (a Flutter app from one of the Thermion contributors) https://apps.apple.com/us/app/prouder/id6498891289 https://play.google.com/store/apps/details?id=se.prouder.app https://prouder.se/
Happy to share more details if anyone is interested!
[1] https://github.com/google/filament
25 comments
[ 2.0 ms ] story [ 68.0 ms ] threadIt actually worked fine with early versions (>= 3.16), but I've recently switched to Dart's native-assets system for building/linking the C++ libraries, which isn't yet considered stable. However, it's working fine on the latest master and it makes managing the build system (and publishing the pub.dev) so much easier, which is why I made the move.
you have to spend a lot of time deciding which state management to use theres a lot of packages you have to choose from and it was exhausting
this looks like it could produce smooth 3d experience but i ended up using babylon.js with electron
I've heard that react-three-fiber lets you build ThreeJS into React Native apps, though? So that may be changing. I'll need to check it out first-hand and see if that's the case.
I think we'll just have to agree to disagree on Flutter, I'm a big fan :)
sure I appreciate native compilation, flutter does achieve that tough problem quite well but coming from JS world, its like, man do i have to redo the gymnastics all over again?
so going in my attitude wasn't great I admit but so far babylonjs/electron/REI seems to provide good enough 3D performance even though on older computers it stutters
i think one promising vector is if you can turn JS devs like me into generating flutter projects. that would dramatically lower the barrier.
I have the hardest time figuring out whether I should use Kotlin, Dart/Flutter, or React for building an iOS and Android app. I don't care about the GUI part, but I want easy access to all APIs (like Health Kit, Health Connect, sensors) and relatively stress-free development. When I was learning Flutter a few years ago, it was very frustrating because its documentation and username were scant and scarce. Is it better nowadays?
To me, state management is a non-issue - there's a built-in option (StatefulWidget/setState), various third party (Riverpod/Provider/etc), and enough basic SDK components (ValueNotifier/StreamBuilder/etc) to roll your own (which is my preference).
https://stackoverflow.com/questions/tagged/flutter?tab=Newes...
But I take that as an indicator of popularity, not a serious problem with the project. If there were truly fundamental issues, there wouldn't be as many issues raised because noone would be using it :)
I was really glad that I found this toolkit just before we released our app. We were previously relying on Google's other 3D viewer (because of course they have two), model-viewer, embedded in a web view.
Thermion has solved a lot of the problems we had with the old web view solution, (performance issues, load times, transparency, etc.) so I'm happy to contribute back to the project in any way I can!
Do you see the same at https://nick-fisher.com?
I'm on chrome for mac os on macbook air m2
The author shared his answer to this on Reddit a while back [1]. Basically, the primary reason this exists is because the first party solution isn't available yet (without compiling the engine yourself). And Thermion doesn't rely on Flutter at all.
[1] https://www.reddit.com/r/FlutterDev/comments/1digpot/comment...
[0] https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
I'd say there are two main differences:
1) Unlike flutter_gpu, Thermion isn't tied to Impeller. For example, last I checked, Impeller won't be supported on web, so you probably won't be building "native Flutter 3D apps" on web any time soon either (except for embedded webview, which is very limited). Likewise, Thermion doesn't require Flutter and can be used anywhere you can get a hardware accelerated surface, window or render target. That opens up a lot of opportunities if you're just interested in writing a 3D app in Dart, with no need for UI (or at least, with no need for Flutter's UI).
2) Filament is a mature PBR engine (and from the outside at least, it certainly seems to have more resources allocated to it than flutter_gpu). I wouldn't expect Impeller 3D to have feature parity for a long long time, if at all. Things like the Filament material system (shader language & compilation pipeline), driver support, etc are very comprehensive. One example - a webgpu backend for Filament is planned, which I suspect will arrive long before Impeller on webgpu.
[0] https://github.com/gskinnerTeam/flutter-wonderous-app
Doing that on Windows is more difficult (as there’s no D3D backend for Filament), so it’s actually an HWND that sits behind the Flutter app. On web, it’s similar (HTML5 canvas), but this can actually be imported into the Flutter app as a widget, I haven’t wired that up yet (there are performance implications on certain browsers too).
Note that size comparison is not completely fair as even with Impeller, Skia (as HarfBuzz is embedded into it) is still used for text layout and shaping.
> Updating the web engine to interface directly with Impeller is a non-goal at this time. It is a significant undertaking (compared to a flag to swap dispatchers that already exists) and also bypasses display list optimizations.
> For this added implementation complexity, Web support has not been a priority at this time for the small team working on Impeller.
> We are aware that these priorities might change in the future. There have been sanity checks to ensure that the Impeller API can be ported to WASM and also that Impeller shaders can be compiled to WGSL for eventual WebGPU support.
https://github.com/flutter/engine/blob/main/impeller/docs/fa...
I believe (?) the intention is also to publish Impeller as a standalone rendering engine (i.e. independent of Flutter). Will be interesting to see if there's a use case there too.