PROJET D’ENTREPRISE
Rapid Render : configurateur de produit 3D en temps réel
configurateur 3D hybride avec Unity + V-Ray ; Pipeline d’actifs glTF/Draco et optimisations des performances WebGL.
IMPACT D’INGÉNIERIE
Périmètre et résultats mesurables
- approche de rendu
- Hybride temps réel/hors ligne
- ligne d'actif
- glTF + Drago
- surface de livraison
- Configurateur WebGL
Il a équilibré la vitesse et la qualité de sortie photoréaliste dans le même flux de produits.
Pipeline de données optimisé qui apporte des données de produits 3D à l'expérience Web.
Pour une découverte de produits en temps réel dans le navigateur.
Résumé rapide
- Rôle : Développeur de logiciels (moteur 3D principal, pipeline d'actifs, intégration du SDK V-Ray)
- Durée : février 2021 – janvier 2022
- Plateforme : Unity WebGL + Bureau
- Technologies de base : Unity 2020 LTS, URP, C#, Python, SDK V-Ray, glTF, Draco
- Types de sortie : aperçu WebGL en temps réel, rendu hors ligne 1080p, exportation de scène JSON
- Preuve vérifiée : Open-source : DracoPy Pull Request #17. Performances : charge WebGL <3 sec / 60 FPS - test : [device_class], [navigateur], [scene : tri_count=[tri_count], texture_count=[texture_count], avg_asset_mb=[avg_asset_mb]]. Rendu hors ligne : V-Ray 1080p ~ 15 min - paramètres : [samples], [denoise], [machine/spec], [render_farm?]
Moteur de configuration et de rendu 3D RapidRender
J'ai développé le moteur 3D principal de RapidRender au sein de Sugar Technology. En combinant les capacités de rendu en temps réel d'Unity avec l'approche de traçage de rayons de qualité production de V-Ray, j'ai établi une structure hybride qui produit à la fois une conception interactive et des résultats finaux de haute qualité sur la même plateforme.
Problèmes et contraintes
- Objectif d'ouvrir des scènes lourdes en WebGL avec un temps de chargement faible.
- La nécessité de normaliser les formats d'actifs 3D hétérogènes en une seule norme.
- Attendez-vous à une cohérence visuelle entre l'aperçu en temps réel et la sortie photoréaliste hors ligne.
- Coûts de mise en file d'attente des tâches de rendu et de retard du pipeline hors ligne.
- Diversité navigateur/GPU et contraintes de performances.
Résumé de la solution
J'ai conçu un pipeline hybride : production de scènes temps réel Unity + rendu hors ligne V-Ray. La scène Unity a été importée dans le SDK V-Ray avec Python via le format intermédiaire JSON ; La cohérence de la qualité a été obtenue tout en maintenant les performances Web avec le pipeline d'actifs glTF/Draco.
Présentation de l'architecture
- Scène Unity -> Interopérabilité JSON -> Python -> SDK V-Ray -> Sortie de rendu 1080p.
- Runtime WebGL : build Unity + streaming d'actifs asynchrone + intégration du panneau de contrôle.
- Garder le schéma de scène rétrocompatible avec la sérialisation et la gestion de versions JSON.
Pipeline d'actifs (glTF/glb + Draco)
- Différents formats fabricants normalisés en glTF/glb ; Le déballage UV, la cuisson des textures et l’injection de métadonnées sont automatisés.
- La cohérence des données a été assurée grâce à la validation et aux ensembles de règles basés sur Pygltflib.
- Chargement asynchrone et streaming progressif implémentés avec UnityGLTF.
- Taille de livraison WebGL optimisée avec compression Draco.
Performances et optimisation
- Les effets de matière, de verre et de contour ont été produits avec Shader Graph et des shaders HLSL personnalisés.
- Le batching d'appels de tirage, l'instanciation GPU, l'atlas de textures et les stratégies LOD ont été implémentés.
- Le réglage itératif des performances a été effectué avec Unity Profiler + Frame Debugger.
Pipeline V-Ray (tâches de rendu)
- Scène Unity exportée au format JSON ; Porté sur le SDK V-Ray avec Python.
- La cohérence de la sortie hors ligne a été obtenue en préservant le mappage caméra/lumière/matériau.
- L'équilibre qualité/temps a été établi avec un échantillonnage et un débruitage adaptatifs.
- Les travaux de rendu ont été mis en file d'attente et gérés avec des scripts d'automatisation.
Contribution Open Source (preuves vérifiées)
J'ai préparé le PR #17, qui ajoute des coordonnées de texture et un support normal à DracoPy ; La contribution a été acceptée dans la communauté open source et fusionnée dans la branche principale.
Effet/Résultats
- Temps de chargement de la scène WebGL - <3 sec - contexte : [device_class], [browser], [scene : tri_count=[tri_count], texture_count=[texture_count], avg_asset_mb=[avg_asset_mb]], mesure : [profiling_tool].
- Fluidité temps réel - 60 FPS - contexte : [device_class], [resolution], [scene : tri_count=[tri_count]], mesure : [profiler].- Temps de rendu hors ligne - 1080p ~ 15 min - paramètres : [samples], [denoise], [machine/spec], [render_farm ?].
- Effet de compression Draco - (une métrique peut être ajoutée : taux de réduction de la taille des paquets) - métrique : [build_size_report].
- Erreurs de validation des actifs - (des métriques peuvent être ajoutées) - mesure : journaux de validation du pipeline.
Tech Stack (Catégories)
- Moteur : Unity 2020 LTS, URP, Shader Graph
- Langues : C#, Python 3.8, Cython
- Rendu : V-Ray 5, SDK V-Ray, HDRI, IES
- Formats : glTF 2.0, glb, Draco, Assimp
- Web : WebGL, WebAssembly, gzip/Brotli, CDN
- Données/Interopérabilité : JSON, Newtonsoft.Json
- Outils : Visual Studio, PyCharm, Unity Editor, Git
##FAQ
Pourquoi l'approche hybride Unity + V-Ray ?
Pour répondre au besoin d’interaction en temps réel et de sortie photoréaliste hors ligne sur la même plateforme.
Pourquoi glTF/glb a-t-il été choisi ?
Parce qu'il offre une compatibilité Web, une large prise en charge d'outils et une standardisation stable.
Pourquoi Drago est-il critique ?
Pour réduire le temps de chargement et la taille des paquets dans WebGL.
Comment les 60 FPS ont-ils été maintenus dans WebGL ?
Avec traitement par lots, instanciation, LOD, optimisation des shaders et réglage basé sur le profileur.
Comment l'orchestration des tâches de la ferme de rendu a-t-elle été gérée ?
Les flux de priorisation/nouvelle tentative ont été établis avec des scripts Python et une approche de file d'attente de tâches.
Comment le versioning et la migration ont-ils été gérés ?
Avec gestion des versions de schéma JSON et scripts de migration automatique.
Comment la qualité du pipeline d'actifs est-elle assurée ?
Avec les validations Pygltflib et les règles de métadonnées.
Projets connexes
- Kayra Export : marché et plateforme de commerce électronique
- ABC Logistics : plateforme de suivi SIG en temps réel- Dunelm : expérience AR « View-in-Room » prise en charge par LiDAR
Mentions légales du projet
- Entreprise : Technologie du sucre
- Position : Développeur de logiciels
- Secteur : Technologies de l'architecture et du design d'intérieur
- Plateforme : Unity WebGL et bureau
- Technologies de base : Unity 3D, C#, Python, V-Ray
- Formats 3D : glTF/glb, compression Draco
- Open-Source : Prise en charge des coordonnées et des normales de texture DracoPy (PR #17)
- Durée : février 2021 – janvier 2022
- Emplacement : Istanbul, Turquie
- Contribution GitHub : DracoPy Pull Request #17