3D + 2D : test d’un moteur graphique WASM cross-platform
(news.ycombinator.com)- Chez Adobe, les problèmes de portage cross-platform rencontrés en transposant de grosses applications comme Photoshop et Acrobat vers plusieurs environnements ont été le point de départ du développement de Renderlet
- Renderlet vise à devenir un framework graphique WASM pouvant être exécuté et embarqué partout, en combinant facilité de développement d’applications et exploitation bas niveau du GPU
- Le runtime public Wander fournit une API 3D bas niveau au-dessus du GPU, et une expérimentation y a été réalisée en y raccordant le moteur de rendu vectoriel 2D open source de Rive
- Le projet est actuellement juste avant l’alpha ouverte et prévoit un Show HN ou un Launch HN une fois le compilateur et l’intégration aux plateformes prêts
- Comme Unity a simplifié le développement cross-platform pour les jeux, Renderlet se concentre sur la simplification de l’exécution d’applications visuelles variées sur de multiples environnements
Le problème de portabilité que Renderlet cherche à résoudre
- Chez Adobe, faire fonctionner de grandes applications comme Photoshop et Acrobat sur desktop, web, mobile et cloud représentait un défi majeur
- Les versions web de Lightroom et Photoshop ont suivi un long parcours passant par JavaScript, Google PNaCl, asm.js et WebAssembly
- Il a fallu repenser l’architecture GPU selon l’appareil cible, ainsi que prévoir des builds mono-thread et une recomposition de l’interface basée sur les Web Components
- Les builds web fonctionnent bien aujourd’hui, mais ce résultat a nécessité 10 ans de travail
- La pile graphique reste un goulot d’étranglement de portabilité, et WebAssembly a été choisi comme base capable d’être exécutée et embarquée partout tout en offrant les performances nécessaires aux graphismes temps réel
- Renderlet met l’accent sur une architecture de modules graphiques autonomes pouvant être reliés entre eux, afin de s’exécuter sur n’importe quel environnement et dans n’importe quelle application
- Le développeur a rejoint YC en tant que fondateur solo et développe Renderlet depuis ces 6 derniers mois
Expérimentation d’intégration du moteur de rendu Rive
- Après que Rive a publié son moteur vectoriel 2D en open source, une expérimentation a été menée pour voir si le Rive Renderer pouvait fonctionner sur le backend GPU de Renderlet
- Le Rive Renderer est composé d’une API 2D haut niveau comparable à SVG
- Wander est la partie runtime open source de Renderlet et fournit une API 3D bas niveau au-dessus du GPU
- Le résultat a montré qu’il était possible d’exécuter la bibliothèque Rive Renderer sur le backend GPU de Renderlet, ce qui permet aussi d’utiliser un backend vectoriel 2D dans des applications 3D
- Un exemple de fonctionnement est visible dans cette vidéo Vimeo
- Les détails techniques sont résumés dans Using renderlet with rive-renderer
- Le code de Wander, le Wasm Renderer runtime, est disponible dans renderlet/wander
1 commentaires
Avis Hacker News
Il vaudrait mieux sauter l’étape PAL et passer directement à SetupRuntime. Les développeurs non spécialisés en graphisme ne connaissent pas bien ce genre de détails, et il n’est pas souhaitable d’ajouter une étape supplémentaire inutile à l’API. PAL n’est utilisé nulle part ailleurs, donc il vaudrait mieux utiliser WebGPU. (
IPaldevrait être un membre deIRuntimeet est prêt à être supprimé dans le contexte WebGPU).IPaldansIRuntimeet suppression prévue.Ce projet pourrait devenir une superbe boîte à widgets pour créer des interfaces graphiques multiplateformes, ainsi qu’un canevas remarquable pour des modèles d’interaction. Le backend C/C++ et la cible WASM permettent de construire une FFI dans pratiquement n’importe quel langage.
Je me demande quels sont les plans pour la prise en charge du texte et des polices. Certains moteurs graphiques ne gèrent pas le texte de toutes les façons souhaitées. Question sur la possibilité de charger des fichiers OTF ou WOFF2 et d’afficher des chaînes arbitraires.
Grand intérêt pour ce projet. Il y a quelques questions sur le runtime, la boucle d’événements, la FFI et la propriété des pointeurs de fenêtre. Intérêt aussi pour les plugins audio et les VST, avec certaines contraintes sur la boucle d’événements et la gestion des fenêtres. JUCE est la solution de facto, mais c’est ancien et peu pratique.
Ce projet est vraiment formidable, c’est exactement ce dont je rêve depuis plusieurs années. WASM a un énorme potentiel comme unité portable pour les calculs graphiques, audio et multimédia.
Je travaille actuellement à faire fonctionner WASM dans Godot Engine. Je me demande comment vous avez surmonté les problèmes d’accessibilité des SharedArrayBuffer dans Safari ainsi que les problèmes d’accès aux réseaux publicitaires, qui sont importants pour les jeux en ligne. Il est aussi souligné qu’il y a un problème entre les builds mono-thread et les builds normaux.
Ravi de voir davantage de projets dans le domaine de la 3D graphique/WASM. Question sur d’éventuels conseils pour entrer chez YC. Travail en cours depuis des années sur le portage d’Unreal Engine 5 vers WebGPU et WebAssembly. Il existe un moteur de rendu multithread et un système de streaming d’assets, de sorte que les utilisateurs n’ont pas besoin de télécharger tout le jeu ou toute l’application à l’avance. Il n’est pas non plus nécessaire de charger toute l’application en mémoire d’un seul coup. Une plateforme d’hébergement complète et un backend ont également été construits pour permettre aux développeurs de déployer leurs projets en ligne.
La présentation à wasm I/O était impressionnante, et je suis heureux de voir que ce travail attire l’attention.
Question sur la lecture d’un article de Ian Hickson, développeur principal de Flutter. Il y explique le concept d’un framework d’interface utilisateur totalement multiplateforme à l’aide de WASM, ce qui correspond au concept utilisé par Flutter.
Recommandation appuyée de
manifoldcomme noyau CAD pouvant être intégré à l’application.manifoldpour une intégration dans l’application.