ABot-Earth 0.5 est le premier modèle de ville native 3D au monde lancé par Alibaba AutoNavi. Saisissez une seule image satellite ou une description textuelle, générez une scène urbaine 3D de haute précision au niveau du kilomètre en 10 minutes sur un GPU grand public, produisez un format 3DGS modifiable et importez-le directement dans Unity/UnrealEngine. Couvrant plus de 190 pays et régions.

ABot-Terre 0.5

Paramètres et statistiques de base d'ABot-Earth 0.5

ABot-Earth 0.5 est un modèle terrestre génératif natif 3DGS lancé par AMap CV Lab, une filiale d'Alibaba AutoNavi. Il est officiellement positionné comme « Modèle de Terre 3D Génératif ». Il ne s'agit pas d'un logiciel de modélisation 3D traditionnel, mais d'un modèle de monde urbain 3D avec une IA générative comme noyau - saisissez une seule image satellite ou une description textuelle, générez une scène urbaine 3D de haute précision au niveau d'un kilomètre sur un GPU grand public en 10 minutes et produisez directement le format 3D Gaussian Splatting (3DGS) modifiable.

Projets	Informations publiques
Positionnement officiel	Modèle de Terre 3D génératif (modèle de Terre 3D génératif)
Architecture de base	Framework de génération 3DGS natif + paradigme de génération de compression
Mode de saisie	Image satellite unique/description textuelle
Vitesse de génération	~10 min/km2 (GPU grand public, tel que RTX 3090/4090)
Débit au niveau de la production	Tuile unique (~ 2,56 km²) en 25 minutes environ (GPU A100) ; Un cluster de 1 000 cartes complète la zone bâtie mondiale en 10 jours
Couverture	Plus de 300 villes, plus de 190 pays et régions
Format de sortie	Splatting gaussien 3D natif (3DGS), prend en charge les niveaux LOD
Compatible moteur	Unity, Unreal Engine, prend en charge la norme OGC 3D Tiles
Taille des données	~3,2 billions de primitives gaussiennes (zone bâtie mondiale)
Licence open source	Dépôt public GitHub (amap-cvlab/ABot-Earth-0.5), comprenant des rapports techniques
Taille de la communauté	GitHub 184 étoiles, 11 forks, 2 observateurs (à partir de 2026-07)
Dernière version	v0.5 (~2026-06)
Rapport technique	arXiv 2606.09967 + rapport technique GitHub.pdf
Développeur	Laboratoire de CV AMap, Alibaba AutoNavi

Brève revue en une phrase : ABot-Earth n'est pas un autre logiciel de modélisation 3D, mais transforme la Terre en une « toile 3D générable » - la modélisation d'une ville au niveau kilométrique qui prenait auparavant des mois et qu'une équipe de professionnels pouvait réaliser peut désormais être complétée avec une image satellite + une carte graphique grand public + 10 minutes.

Détermination du type : le type principal est [Grand modèle de base/Infrastructure API] - il s'agit d'un modèle de génération de ville 3D de bout en bout, et le livrable principal est une scène 3DGS générative. Dans le même temps, il est fourni aux utilisateurs finaux sous la forme d'une [application de productivité/côté métier] via Web Studio (ABot-Earth Studio). L’analyse approfondie suivante couvre ce double type.

Utilisateurs et reconnaissance du marché d'ABot-Earth 0.5

ABot-Earth 0.5 sera rendu public vers juin 2026 et est développé par Alibaba Amap AMap CV Lab. Sa reconnaissance sur le marché peut être évaluée à trois niveaux : l'impact académique, l'attention de l'industrie et la vérification de la communauté.

Impact académique : le rapport technique est accessible au public sur arXiv (2606.09967) et inclus dans Hugging Face Papers. Le document propose un cadre de génération 3DGS natif, qui dépasse considérablement la référence optimale précédente (69,5 d'EarthCrafter) avec un indice FID de 16,1, et le KID passe de 0,061 à 0,006. Il s’agit de la première méthode générative permettant d’atteindre ce niveau de performance sur des données réelles de reconstruction 3DGS.

Attention de l'industrie : En tant que produit de pointe d'AutoNavi dans le domaine 3D, ABot-Earth est naturellement soutenu par les données cartographiques mondiales d'AutoNavi et les ressources d'infrastructure d'Alibaba. La phase de tests internes a ouvert les applications aux studios de jeux et aux équipes de jumeaux numériques. Sa vidéo de démonstration YouTube fournit une démonstration complète des effets générés.

Vérification de la communauté Open Source : le référentiel GitHub fournit un rapport technique complet (tech-report.pdf) et l'accord open source est public. Bien que 184 stars and 11 forks ne soit pas un projet open source à grande échelle, en tant que version d'un laboratoire de recherche d'entreprise, il se concentre sur la divulgation technologique plutôt que sur la co-construction communautaire. Les deux contributeurs (qianmingduowan, frankjiang) sont tous deux membres principaux d'AMap CV Lab.

Unicité du positionnement sur le marché : contrairement à la reconstruction photogrammétrique traditionnelle de Google Earth et à la génération procédurale de Marble, ABot-Earth est la première voie technique permettant de « générer du 3DGS natif de bout en bout basé sur des images satellite réelles ». Alors que la couverture 3D de Google Earth est limitée aux zones urbaines numérisées, ABot-Earth peut générer des scènes 3D directement à partir d'images satellite dans des zones sans données numérisées, comme l'Irlande rurale.

Avantages financiers d'ABot-Earth 0.5

L'avantage de coût d'ABot-Earth doit être démantelé sous deux dimensions : la substitution d'itinéraire technique et le niveau de déploiement, plutôt que de simplement comparer les prix des abonnements.

Voie technique alternative : photogrammétrie générative vs photogrammétrie traditionnelle

Dimensions comparatives	Photogrammétrie traditionnelle (méthode Google Earth)	ABot-Earth 0.5 (génératif)
Collecte de données	Photographie oblique / numérisation LiDAR, prend plusieurs mois	Image satellite unique (disponible dans le monde entier)
Coût au kilomètre carré	Des dizaines à des centaines de milliers de dollars	~1% des méthodes traditionnelles (données du rapport technique)
Cycle de traitement	Semaines ou mois	10 minutes pour générer / 25 minutes pour les tuiles de qualité production
Exigences de l'équipe	Équipe professionnelle d'arpentage et de cartographie + cluster GPU	Personne seule + GPU grand public
Cohérence de la couverture	Uniquement les zones urbaines analysées	Une couverture d'images satellite peut être générée
Editabilité de la sortie	Format fermé, exportation restreinte	3DGS natif, importable dans Unity/UE

Développeurs côté C/individuels : postulez pour utiliser Web Studio gratuitement pendant la période de test interne. Vous devez apporter votre propre GPU grand public (niveau RTX 3090/4090) pour l'inférence locale. La génération d’une seule scène ne consomme que de l’électricité et de la dépréciation du GPU, avec des coûts explicites très faibles. Les limites de l'autorisation commerciale ne sont pas divulguées dans les conditions de test internes et les droits d'utilisation commerciale des actifs générés doivent être confirmés avant utilisation.

API/Développeur : le prix de l'API autonome n'est pas divulgué pour le moment. Pendant la phase de test interne, Web Studio (abot-earth.amap.com) est utilisé comme portail de livraison, et aucun SDK ou API REST indépendant n'est fourni. Nous prévoyons de faire attention à savoir si Amap ouvrira des canaux API à l'avenir.

Enterprise/Game Studio : pour les équipes qui doivent générer des scènes par lots, le coût du déploiement du cluster GPU doit être évalué. Les rapports techniques révèlent que la génération complète de la zone bâtie mondiale (environ 800 000 km²) prend environ 10 jours sur un cluster A100 de 1 000 cartes. Le coût réel comprend la puissance de calcul du GPU, le transfert de données et le stockage. Par rapport à la modélisation externalisée traditionnelle (des milliers à des dizaines de milliers de dollars par kilomètre carré), le routage génératif peut réduire les coûts à environ 1 %.

Coûts cachés : Les coûts cachés les plus remarquables à ce stade sont la dépendance de la qualité de la production sur la résolution et la clarté des images satellite d'entrée. Le format 3DGS peut nécessiter des étapes de conversion supplémentaires lorsqu'il est intégré au pipeline du moteur de jeu traditionnel, ainsi que le SLA commercial et la stabilité du service qui n'ont pas encore été clarifiés lors de la phase de tests internes.

Principales fonctionnalités d'ABot-Earth 0.5

Les capacités d'ABot-Earth 0.5 sont conçues autour de « la génération de bout en bout depuis des images satellite jusqu'à un monde 3D interactif ». Les fonctions principales peuvent être résumées en six catégories :

• Ville 3D à génération d'image/texte unique : saisissez une seule image satellite ou une description en langage naturel pour générer automatiquement des scènes 3D de haute précision au niveau du kilomètre. Il prend en charge le départ de n'importe quelle coordonnée sur terre, couvrant divers reliefs tels que les villes, les banlieues et les terrains naturels.
• Sortie 3DGS native : sortie directe au format 3D Gaussian Splatting, préservant la géométrie, les détails de texture et les informations sémantiques. Chaque scène est composée de millions d'ellipsoïdes gaussiens 3D avec des paramètres de couleur, de transparence, de rotation et de covariance, qui expriment mieux les géométries non multiples telles que les feuilles et l'eau que les maillages traditionnels.
• Génération native multi-LOD : le modèle dispose d'une structure hiérarchique LOD intégrée pendant la phase de génération au lieu d'un sous-échantillonnage après la génération. Prend en charge une transition en douceur des vues au niveau de la planète aux détails au niveau de la rue, et permet un rendu en streaming en temps réel de milliards de primitives gaussiennes sur le moteur de rendu YunJing.
• Intégration et éditabilité du moteur : La scène 3DGS générée peut être directement importée dans les moteurs grand public tels que Unity et Unreal Engine, prenant en charge l'édition, la combinaison et la création secondaire. Rapport technique démontrant l'intégration de modèles de monuments de haute précision reconstruits par COLMAP (Tour Eiffel, Colisée, etc.) dans un flux de travail hybride contextuel génératif.
• Inférence transparente par fenêtre coulissante : adoptez une stratégie d'inférence par fenêtre coulissante pour effectuer une fusion intelligente dans la zone de transition des blocs générés adjacents afin d'éliminer les artefacts d'épissage et d'assurer la continuité visuelle des scènes à grande échelle. Un seul bloc d'inférence couvre 1,6 km × 1,6 km (entrée d'image satellite 4K) et la fenêtre coulissante interne est générée par unités de tuiles d'entraînement de 200 m × 200 m.
• Adaptation des conditions inter-domaines : grâce au mécanisme d'adaptation des conditions piloté par VLM (Visual Language Model), il gère les énormes différences de résolution, d'angle de prise de vue, de conditions atmosphériques, etc. des images satellite mondiales. La phase de formation utilise des perspectives de satellite simulées pour restituer les données, et la phase d'inférence utilise VLM pour s'adapter dynamiquement aux entrées réelles des satellites.

Point de vue d'expert : L'ingéniosité de la conception d'ABot-Earth réside dans la « génération en tant que service » plutôt que dans la « génération puis exportation ». Ses capacités natives multi-LOD signifient que les utilisateurs n'ont pas à investir davantage dans l'optimisation du rendu : une hiérarchie diffusable est disponible dès le moment de la génération, ce qui résout les problèmes de post-optimisation les plus chronophages dans la reconstruction 3D traditionnelle. De plus, l’utilisation d’images satellites comme conditions d’entrée permet l’établissement rapide de fonds de carte numériques 3D dans des zones dépourvues de capacités de levé aérien et de cartographie (pays en développement, zones reculées), ce qui constitue un angle mort structurel dans les solutions de photogrammétrie telles que Google Earth.

Evolution du modèle et de la version d'ABot-Earth 0.5

La structure des versions d'ABot-Earth est actuellement relativement concise et en est au premier stade d'itération rapide :

Version principale

• v0.1 (~2025-06) — Aperçu anticipé : aperçu ABot-Earth. Vérification des capacités de base de génération de villes 3D. Le parcours technique pour la caractérisation 3DGS + la génération de conditions d’images satellite a été établi. Il n’existe actuellement aucune version de déploiement publique indépendante.
• v0.5 (~2026-06) — Dernière version actuelle : ABot-Earth 0.5. L'avancée principale réside dans trois aspects : proposer un cadre de génération 3DGS natif (plutôt que de convertir en 3DGS après génération) ; réaliser la génération endogène de plusieurs niveaux de LOD ; et la construction d'un pipeline de production mondial pouvant couvrir plus de 190 pays et plus de 300 villes. Le rapport technique et le référentiel GitHub sont rendus publics et les tests internes de Web Studio sont lancés.

L'écart d'environ un an entre les deux versions reflète l'énorme charge de travail depuis la vérification des algorithmes jusqu'au déploiement technique : y compris des projets systématiques tels que le pipeline de reconstruction ABot-3DGS, la planification mondiale de données multi-sources et la construction du moteur de rendu au niveau du billion (EarthScape).

Jugement du rythme de version : suite au laboratoire de recherche Amap, le rythme de sortie d'ABot-Earth est similaire à des "versions majeures marquantes" plutôt qu'à des "petites étapes continues". La maturité de la v0.5 a dépassé le stade de la démonstration académique et est entrée dans la phase de production qui peut être testée en interne. La prochaine version devrait progresser dans trois directions : amélioration de la résolution de génération, génération de détails au niveau du sol (vue de la rue) et ouverture d'API commerciale. Le rapport technique mentionne clairement « du ciel au sol » comme objectif de la prochaine étape.

Avantages techniques d'ABot-Earth 0.5

Les avantages techniques d'ABot-Earth doivent être compris à partir du positionnement unique du « modèle terrestre 3D génératif », plutôt que par rapport aux modèles génératifs 3D généraux (tels que TRELLIS, Hunyuan3D). Ce qui suit analyse les quatre innovations technologiques fondamentales selon la chaîne « mécanisme → effet → scénarios applicables ».

Framework natif de génération 3DGS : éviter le détour du "d'abord grille puis formater"

Mécanisme : la plupart des modèles génératifs 3D existants sont représentés par un maillage ou un NeRF en sortie, et l'exportation vers 3DGS nécessite des étapes de conversion supplémentaires. ABot-Earth apprend directement l'espace latent du 3DGS au sein d'un paradigme de génération de compression : d'abord en compressant des scènes 3DGS réelles de niveau million en vecteurs latents compacts, puis en entraînant un modèle de diffusion dans l'espace latent pour générer de nouvelles scènes 3DGS.

Effet : La scène 3DGS générée peut être utilisée directement pour le rendu et l'édition sans conversion de format. Par rapport aux solutions basées sur le maillage, 3DGS exprime plus naturellement des géométries complexes telles que les feuilles, les surfaces d’eau et les murs-rideaux en verre, et prend naturellement en charge le rendu différentiel.

Scénarios applicables : scénarios qui nécessitent des itérations à haute fréquence (prototypage rapide du développement de jeux, construction rapide de jumeaux numériques) et équipes qui doivent s'interfacer avec les flux de travail 3DGS existants (tels que les plug-ins Unity/UE).

Plusieurs niveaux de LOD endogènes : l'efficacité du rendu ne dépend pas de la post-optimisation

Mécanisme : le décodeur produit une structure 3DGS multi-niveaux (zoom 14-19) lors de sa génération, au lieu de générer d'abord un modèle complet de haute précision, puis de sous-échantillonner. Les couches de haute précision (zoom 17-19) sont générées nativement par le modèle génératif, et les couches de faible précision (zoom 14-16) sont générées par le sous-échantillonnage statistique guidé par distance de Bhattacharyya, qui peut être exécuté en parallèle sur le processeur.

Effet : prend en charge le zoom continu depuis la vue globale à vol d'oiseau jusqu'au niveau de la rue. Le moteur de rendu YunJing planifie dynamiquement les niveaux de LOD correspondants en fonction de la fenêtre d'affichage, obtenant ainsi une fréquence d'images interactive en temps réel de milliards de primitives. Cela évite le goulot d'étranglement des « modèles de haute précision trop volumineux pour être rendus en temps réel » dans les pipelines traditionnels.

Scénarios applicables : applications nécessitant une navigation interactive de scènes 3D à grande échelle (cartes Web, centres de commande numériques de villes jumelées, planification d'itinéraires de drones).

Raisonnement transparent par fenêtre coulissante : résout le problème d'épissage de la "génération de grandes scènes"

Mécanisme : La phase d'entraînement est mesurée en tuiles de 200 m × 200 m et la phase d'inférence est mesurée en blocs de 1,6 km × 1,6 km. Dans les zones superposées des blocs générés adjacents, les artefacts de limite sont éliminés grâce à une stratégie intelligente de fusion de poids.

Effet : La zone de couverture d'un seul bloc d'inférence est 64 fois supérieure à celle de la vignette d'entraînement, ce qui réduit considérablement le nombre d'inférences requises pour la génération de scènes complètes. Et l'effet de fusion des limites atteint un niveau visuel « presque transparent » dans les évaluations subjectives (rapport technique Fig. 4).

Scénarios applicables : projets nécessitant un contexte 3D continu à grande échelle (jumeaux numériques au niveau de la ville, simulation de conduite autonome, gestion économique de l'espace aérien à basse altitude).

Adaptation des conditions inter-domaines : transformer la « qualité d'image satellite instable » en un avantage de conception

Mécanisme : Dans la phase de formation, l'image « perspective satellite simulée » est rendue à partir de la scène 3DGS comme condition ; dans la phase d'inférence, VLM est utilisé pour analyser l'angle de prise de vue, les conditions atmosphériques, la résolution et d'autres caractéristiques de l'entrée réelle du satellite, et adapter dynamiquement les paramètres générés.

Effet : Le modèle est robuste aux images satellite provenant de différentes sources et qualités. Dans les zones où Google Earth manque de données 3D (comme l'Irlande rurale), ABot-Earth peut toujours générer des scènes 3D raisonnables contenant des bâtiments, des routes et de la végétation.

Scénarios applicables : projets de couverture mondiale avec une qualité d'image satellite inégale, ou applications qui doivent établir rapidement des fonds de carte 3D pour des zones sans données d'arpentage et de cartographie.

Comparaison technique avec des produits concurrents :

Dimensions	Google Terre	Marbre (génération procédurale)	CityDreamer / Earthcrafter	ABot-Terre 0.5
Parcours technique	Photogrammétrie oblique + post-traitement manuel	Génération de règles procédurales	Génération de modèles de diffusion et reconstruction de vues 2D	Génération 3DGS native
Dépendance aux données	Nécessite une photographie oblique multi-angle	Aucune donnée réelle requise	Données de formation requises	Une seule image satellite suffit
Couverture	Seules les zones urbaines clairsemées	Illimité mais pas réel	Zone limitée	La couverture des images satellite est suffisante
Vitesse de génération	Mois à années	Instantané mais pas réel	Niveau minute (zone limitée)	~10 min/km²
Format de sortie	Format fermé	Spécifique au moteur	Vue/maillage 2D	3DGS natif
Modifiable	Limité	Paramétrique	Faible	Élevé (édition directe 3DGS)
Évaluation de la qualité visuelle	Géométrie/Textures Élevé, Esthétique Moyen	Qualité des règles visuelles	FID 69.5 (EarthCrafter)	FID 16.1

Comment utiliser ABot-Earth 0.5

ABot-Earth utilise actuellement Web Studio de tests internes comme portail de livraison principal, et le chemin d'utilisation est le suivant :

Entrée	Méthode d'accès	Convient à la foule	Conditions préalables
Web Studio (entrée principale)	abot-earth.amap.com → Postuler pour des tests internes	Tous les utilisateurs	Application de test interne réussie + navigateur de bureau (support WebGL)
Exploration du monde (scène par défaut)	abot-world.amap.com	Navigation des utilisateurs	Pas besoin de postuler, vous pouvez explorer directement la ville 3D prédéfinie
Rapport technique et code	GitHub : amap-cvlab/ABot-Earth-0.5	Chercheurs/Développeurs	Besoin de configurer vous-même le contexte d'inférence et le GPU
Inférence locale (bêta interne)	Les utilisateurs bêta internes ont le droit de redémarrer l'inférence locale	Développeurs avec GPU	GPU grand public (RTX 3090/4090) + qualifications bêta internes

Processus d'utilisation typique (Web Studio) :

1. Visitez abot-earth.amap.com et cliquez sur « Connexion pour postuler aux tests internes » pour soumettre la candidature.
2. Après avoir réussi l'examen, entrez dans Studio et sélectionnez le mode "Création instantanée".
3. Sélectionnez la méthode de saisie : téléchargez des images satellite ou saisissez une description textuelle (telle que "Générer une ville 3D de Shinjuku, Tokyo")
4. Attendez environ 10 minutes (GPU grand public) pour terminer la génération
5. Vérifiez les résultats générés dans la fenêtre d'aperçu 3D, prenant en charge la mise à l'échelle, la rotation et la traduction.
6. Téléchargez les actifs au format 3DGS générés et importez-les dans Unity, Unreal Engine ou d'autres outils prenant en charge 3DGS.

Conseil d'expert : à ce stade, il est recommandé de comprendre d'abord la qualité de la génération et le niveau de couverture via la fonction "World Exploration" (abot-world.amap.com) avant de postuler à des tests internes. Étant donné que Web Studio est basé sur WebGL, le bureau Chrome/Edge offre la meilleure expérience. La vitesse d'approbation de la qualification bêta interne et le SLA sont soumis au processus officiel en vigueur.

Prix des produits pour ABot-Earth 0.5

ABot-Earth est actuellement en phase de test interne et les informations publiques sur les prix sont limitées, mais elles peuvent être désassemblées en trois couches en fonction de la forme du produit :

• Client C/utilisateurs individuels : utilisez Web Studio pour générer des scénarios gratuitement pendant la période bêta interne. Vous devez apporter votre propre GPU grand public pour l'inférence locale (Web Studio effectue l'inférence IA pour le client dans le cloud, mais l'inférence locale nécessite votre propre carte graphique). Le quota gratuit, les temps de génération et les limites de résolution sont soumis aux conditions de la version bêta interne.
• Développeurs/Chercheurs : l'entrepôt et les rapports techniques de GitHub sont gratuits et ouverts au public, et peuvent être reproduits ou redéveloppés sur la base de rapports techniques. Les heures d’ouverture de l’API et la stratégie tarifaire n’ont pas été annoncées.
• Enterprise/Game Studio : Tarifs commerciaux à annoncer. À en juger par le rapport technique selon lequel le cluster A100 de 1 000 cartes peut terminer la génération mondiale en 10 jours, le prix de la génération par lots au niveau de l'entreprise sera basé sur la consommation d'énergie de calcul du GPU + l'autorisation d'utilisation des données. Il est actuellement recommandé de contacter l'équipe AutoNavi via le canal bêta interne pour obtenir un devis commercial.

Analyse comparative des coûts avec modélisation traditionnelle (référence de déduction, données non officielles) :

• Méthode traditionnelle : le coût d'externalisation pour un seul kilomètre carré de modélisation urbaine 3D est d'environ 5 000 à 50 000 USD, avec un temps de cycle de 2 à 8 semaines.
• Chemin génératif ABot-Earth : coût de calcul GPU (en termes de GPU cloud) ~ 50 à 200 $/km² + 10 minutes de temps de génération
• Source principale de réduction des coûts : élimination du processus d'enquête sur le terrain, de modélisation manuelle et de multiples séries de modifications, réduisant ainsi la partie main-d'œuvre du coût à presque zéro.

Scénarios d'application d'ABot-Earth 0.5

Les scénarios d'application d'ABot-Earth se concentrent sur les domaines qui « nécessitent des données spatiales urbaines 3D rapides, peu coûteuses et à grande échelle » plutôt que sur une modélisation 3D générale.

• Développement de jeux - Génération de fonds de carte du monde ouvert : utilisez des images satellite pour générer des fonds de carte de villes du monde ouvert, remplaçant ainsi la modélisation manuelle traditionnelle ou la génération procédurale. Les avantages se reflètent à deux niveaux : premièrement, la construction de la scène au niveau de la ville est réduite de « mois » à « jours » ; Deuxièmement, les résultats générés sont basés sur des données géographiques réelles, qui sont naturellement spatialement rationnelles, réduisant ainsi la charge de travail de l'équipe artistique dans la « fabrication du plan de la ville ». Points clés pour l'acceptation : si la disposition du bâtiment généré est conforme au réseau routier réel et si le style de texture correspond au style artistique du jeu.
• Intelligence incorporée/Simulation de conduite autonome : fournit un contexte d'entraînement urbain 3D de haute précision pour les véhicules aériens sans pilote (UAV) et les véhicules autonomes. Les scènes générées par ABot-Earth sont physiquement réalistes et cohérentes dans plusieurs perspectives, et peuvent remplacer de véritables données de photographie aérienne dans des simulations fermées. Le rapport technique répertorie explicitement la navigation par drone inclus comme scénario d’IA incorporé appliqué. Points clés pour l'acceptation : si la précision géométrique du rendu répond aux exigences de la migration Sim-to-Real et à la fidélité de la simulation des capteurs.
• Économie à basse altitude et gestion de l'espace aérien : une carte de base numérique en trois dimensions qui prend en charge la planification d'itinéraire des drones, la détection des conflits dans l'espace aérien et l'évaluation des points d'atterrissage d'urgence. L’économie à basse altitude nécessite une carte 3D couvrant la totalité de la ville (plutôt que quelques itinéraires seulement), et le chemin génératif d’ABot-Earth résout le problème de couverture. Points clés d'acceptation : précision de l'estimation de la hauteur du bâtiment, exhaustivité de la détection des obstacles (poteaux téléphoniques, arbres).
• Digital Twin City : construisez rapidement une base de jumelles numériques au niveau de la ville. Les méthodes traditionnelles nécessitent des mois, voire des années, de cycles de collecte de données et de modélisation, mais ABot-Earth peut réduire le temps de « première cartographie » à quelques jours. Il convient aux scénarios tels que la planification urbaine, la gestion des urgences et la surveillance environnementale qui nécessitent des mises à jour fréquentes des cartes de base 3D. Points clés d'acceptation : facilité d'intégration avec les systèmes SIG (tels que Cesium) et prévisibilité des cycles de mise à jour.
• **Production cinématographique et télévisuelle et production virtuelle

Film** : générez des scènes jumelles numériques d'arrière-plans urbains réels, en remplaçant les prises de vue en direct ou la construction purement CGI. La scène 3DGS générée peut être utilisée comme carte de base contextuelle pour la production virtuelle et prend en charge l'itinérance des caméras en temps réel. Points clés pour l'acceptation : Compatibilité du format de sortie avec le pipeline UE/Unity. Indique si la commutation LOD affecte la fréquence d'images du rendu en temps réel.

Matrice d'adaptation de scène :

Scénario	Recommandation	Indicateurs de base	Problèmes d'acceptation
Carte de base du monde ouvert du jeu	★★★★★	Vitesse de génération, échelle de scène	Rationalité de l'agencement du bâtiment, compatibilité des moteurs
Simulation intelligente incorporée	★★★★★	Précision géométrique, cohérence multi-vues	Effet de transfert Sim-vers-Réel
Gestion économique de l'espace aérien à basse altitude	★★★★☆	Couverture, précision de la hauteur du bâtiment	Complétude des obstacles, alignement du système de coordonnées
Jumeau numérique de la ville	★★★★☆	Fréquence de mise à jour, intégration avec SIG	Maîtrise de la commutation LOD, format de données
Production virtuelle de films et de télévision	★★★☆☆	Qualité visuelle, fréquence d'images en temps réel	Contrôlabilité du style artistique, flexibilité de modification

Personnes concernées pour ABot-Earth 0.5

ABot-Earth s'adresse au groupe d'utilisateurs qui ont besoin de « scènes 3D à grande échelle » plutôt que de « ressources 3D uniques », et ses limites applicables sont relativement claires.

• Game Studio (Open World Direction) : Une équipe qui doit créer rapidement une carte de base contextuelle d'une ville réelle. ABot-Earth peut remplacer le processus traditionnel de « construction manuelle en référence à des villes réelles ». Mais attention : les scènes générées sont « réalistes » plutôt que « stylisées », et les pipelines artistiques avec des styles de rendu non réalistes tels que les dessins animés et les polygones faibles nécessitent un travail de rendu supplémentaire.
• Équipe Digital Twin et SIG : une équipe qui doit créer des cartes de base numériques 3D pour les villes, les parcs et les pôles de transport. L'intérêt d'ABot-Earth réside dans la réduction du premier cycle de modélisation de « mois » à « jours », et il possède la capacité naturelle d'aligner les coordonnées géographiques. Cependant, la « précision absolue » des scènes génératives n'est pas aussi bonne que la reconstruction par balayage laser, et elle doit être mélangée et superposée avec des données BIM de haute précision.
• Ingénieur de simulation de conduite autonome : Des scènes urbaines 3D diverses et généralisables sont nécessaires pour entraîner et vérifier les algorithmes de perception. ABot-Earth peut couvrir les reliefs et les formes architecturales de différents pays et styles urbains. Cependant, la version actuelle est principalement basée sur la perspective de la photographie aérienne, et la génération de détails au niveau du sol (au niveau de la rue) est clairement le prochain objectif (Rapport technique §6). Il est actuellement plus adapté aux tâches de simulation basées sur la « planification de perspective de photographie aérienne ».
• Équipe économique des drones et des basses altitudes : Une carte tridimensionnelle couvrant l'ensemble de la ville est nécessaire pour soutenir la planification des itinéraires et la gestion de l'espace aérien. Les capacités de couverture mondiale d'ABot-Earth et sa vitesse de génération à la minute près résolvent le problème des « points morts de couverture » des solutions traditionnelles.
• Institutions de recherche et d'enseignement : Besoin de données urbaines 3D à grande échelle pour la recherche universitaire (informatique urbaine, télédétection, intelligence incorporée). Les rapports techniques et les référentiels GitHub fournissent des fondements théoriques complets et des indices de reproduction.

Dissuadé/ne s'applique pas aux personnes :

• Solo 3D Asset Creator : Pour les équipes qui n'ont pas besoin d'une scène au niveau de la ville, mais qui n'ont besoin que d'un seul bâtiment ou objet, ABot-Earth n'est pas le bon outil. De telles exigences sont plus adaptées aux modèles génératifs au niveau objet tels que TRELLIS et Hunyuan3D.
• Projets d'arpentage nécessitant une précision centimétrique : les scènes génératives d'ABot-Earth fonctionnent bien au niveau "visuellement raisonnable", mais ne peuvent pas atteindre la norme centimétrique du balayage laser ou de la reconstruction photographique oblique en termes de précision géométrique absolue. Des scénarios tels que les levés techniques et les mesures telles que construites nécessitent toujours des méthodes de mesure traditionnelles.
• Projets qui s'appuient fortement sur des styles artistiques spécifiques : Les scènes générées par ABot-Earth reflètent le "style des images satellite réelles". Si le projet nécessite un style artistique spécifique (cyberpunk, style encre, faible polygone), un traitement post-stylisation supplémentaire est requis.
• Utilisateurs individuels sans ressources GPU : bien que Web Studio puisse exécuter des inférences dans le cloud, le déploiement local et les builds par lots nécessitent toujours un GPU grand public. Sans GPU, l'expérience utilisateur est limitée.

Résumé et perspectives d'ABot-Earth 0.5

ABot-Earth 0.5 réduit le seuil technique et le coût de la modélisation urbaine en 3D de deux ordres de grandeur. Il ne s'agit pas d'un « outil de modélisation 3D plus rapide », mais il redéfinit le cheminement de « comment obtenir une ville en 3D » - de « cartographie + reconstruction » à « description + génération ». Sa différenciation fondamentale réside en trois points : la représentation 3DGS native apporte l'avantage d'un format prêt à l'emploi, la structure LOD endogène résout le problème de rendu en temps réel de scènes de plusieurs milliards et la capacité d'obtenir une couverture généralisée de toutes les coordonnées dans le monde en fonction des conditions des images satellite.

Limites et incertitudes actuelles :

• Incertitude en phase de tests internes : Web Studio est en période de tests internes. La vitesse d'approbation des applications, le quota de génération et le SLA du service sont tous basés sur le processus officiel réel. Il n’y a pas encore de conditions commerciales publiques.
• La qualité de la génération dépend de l'entrée : dans les zones avec une faible résolution d'image satellite, une couverture nuageuse et des ombres importantes, la qualité de la génération diminuera considérablement. Au cours de la phase de test interne, il est recommandé de commencer par évaluer les zones d’images satellite de haute qualité (zones urbaines centrales).
• Maturité écologique du format 3DGS : Bien que le 3DGS gagne rapidement en popularité dans la communauté académique, le support natif des moteurs de jeux grand public (Unity, UE) est encore en construction. L'importation dans des pipelines traditionnels peut nécessiter des plugins de conversion de format supplémentaires ou des bibliothèques d'exécution.
• La limite de l'autorisation commerciale n'est pas claire : les conditions des droits d'utilisation commerciale, la propriété des droits d'auteur et les règles de redistribution des actifs générés n'ont pas été divulguées lors de la phase de test interne. La portée de l'autorisation doit être confirmée via Amap avant toute utilisation commerciale.
• Les détails au niveau du sol sont temporairement manquants : La version actuelle est principalement basée sur la vue aérienne/satellite (vue aérienne oblique), et les détails au niveau du sol au niveau de la rue sont le prochain objectif clair.

Évaluation des risques d'approvisionnement/d'adoption :

• Court terme (0 à 6 mois) : il est recommandé aux studios de jeux et aux équipes de jumeaux numériques de postuler pour acquérir de l'expérience via le canal bêta interne. Concentrez-vous sur la vérification de la qualité de la génération, de la compatibilité des moteurs et de l'amélioration de l'efficacité des itérations selon vos propres scénarios commerciaux. Ne comptez pas uniquement sur les produits de votre pipeline de production qui sont encore en version bêta.
• À mi-parcours (6 à 12 mois) : faites attention à savoir si AutoNavi ouvre l'API/SDK, lance la tarification de la version entreprise et aux progrès de la prise en charge native de 3DGS dans Unity/UE. Si ABot-Earth dispose d’une voie de commercialisation claire (telle qu’une tarification basée sur la superficie générée, permettant un déploiement privatisé), elle peut être pleinement adoptée dans des projets à risque faible ou moyen.
• Long terme (12 mois+) : Grâce à des améliorations des détails au niveau du sol, une résolution plus élevée et des capacités d'édition de scène, ABot-Earth a le potentiel de devenir la « couche de base de scène 3D » standard pour les jumeaux numériques et le développement de jeux. Avant d'acheter, les entreprises doivent confirmer : la propriété intellectuelle des données générées, l'engagement de disponibilité dans le SLA commercial et l'engagement à long terme d'AutoNavi envers ce produit.

Outils associés : midjourney, stable-diffusion

Informations de version

• ABot-Terre 0.5 ：Prend en charge la génération d'images/textes uniques de villes 3D, 10 minutes d'inférence GPU grand public et la sortie au format 3DGS, couvrant plus de 190 pays. （~2026-06）
• Aperçu d'ABot-Earth ：Première version d'aperçu, vérification des capacités de base de génération de villes 3D. （~2025-06）