Oui, en fait cette démo n'est qu'un support pour valider la bon fonctionnement 
de la génération des tuiles 3D au format X3D.

Côté navigation, ça ne vaut rien, je suis d'accord, c'est pas la peine de 
s'attarder dessus en l'état. En fait, j'utilise des contrôles définis par 
défaut dans la spec  X3D et l'implementation js x3dom. Donc oui, ça ne donne 
pas un navigateur potable. Tout reste à faire...

Ça intéresserait quelqu'un de bosser avec moi sur une solution de navigation 
avec x3dom, three.js ou babylon.js ?

Clément.


Le 14 janvier 2016 23:45:21 UTC+01:00, Philippe Verdy <verd...@wanadoo.fr> a 
écrit :
>Apparemment le clic gauche ne fait pas le drag, mais change
>l'orientation
>de la caméra pour viser un même point fixe à la surface de laterre
>initialement centré en LAT0/LON0 autour d'une sphère de rayon fixe
>(indépendant du zoom). c'est le clic droit qui fait le drag du point
>fixe,
>mais de façon très étrange (la direction n'est pas celle de la vue mais
>relative à l'angle du vrai nord qui n'est pas en haut de la carte une
>fois
>qu'on a changé l'orientation de la caméra. Le zoom est avec la molette
>ou
>CTRL+clic gauche.
>Il y a un autre pan avec CTRL+clic droit mais il est beaucoup trop
>rapide
>en vue rapprochée (il semble que la distance de déplacement la souris
>est
>proportionnelle avec l'angle de déplacement sur la carte mais ce taux
>est
>malheureusement pas dépendant du niveau de zoom).
>
>Ca demande pour être plus intuitif de ne pas controler la vue en
>fonction
>des longitudes/latitudes cartographiques mais en fonction des
>coordonnées
>de la projection (donc effectuer les projections inverses pour ajuster
>les
>paramètres de projection/zoom/orientation.
>
>Intuitivement au lieu de controler un nioveau de zoom, iol faudrait
>controler la hauteur de la caméra par rapport au point central de la
>vue au
>sol, au centre de l'écran.
>
>Il y a du travail à faire sur les formules mathématiques des
>projections et
>projections inverses nécessaires, et aussi pour déterminer quels
>niveaux de
>zoom sont les plus adaptés pour afficher (selon la distance réelle des
>objets vus à leur échelle) le niveau de zoom à demander pour les tuiles
>des
>TMS utilisés (je ne vois d'ailleurs que des tuiles bitmap, y-a-t-il un
>niveau où apparaissent des données vectorielles?).
>
>Pour l'instant ça ne marche pas du tout. Tout cela est donc très
>difficile
>à utiliser: les formules utilisées ne sont pas bonnes du tout. C'est
>quasiment impossible de naviguer : la souris devrait contrôler un
>déplacement relatif au niveau de zoom sur la carte représentée, et dans
>le
>même angle que cette vue (au moins l'angle calculé sur le point central
>de
>la vue et non un point hors de la vue).
>
>
>Le 14 janvier 2016 à 20:57, Frédéric Rodrigo <fred.rodr...@gmail.com> a
>écrit :
>
>> Petit retour rapide. J'ai juste testé la démo.
>> Je trouve la navigation à la sourie complètement contre intuitive.
>> click gauche devrait faire du drag, le zoom molette est à l'inverse
>de ce
>> qu'il se fait habituellement.
>> bref pour la première démo je ne suis pas arrivé a visualiser quelque
>> chose en navigant.
>>
>>
>>
>> Le 14/01/2016 12:32, Clement IGONET a écrit :
>>
>>> Bonjour tout le monde,
>>>
>>>     Je travaille depuis plus d'un an sur un projet de génération de
>>> tuiles 3D à partir des données d'OSM. Le projet se concentre surtout
>>> sur la modélisation de bâtiments.
>>>
>>>     Le projet était en C++, mais j'ai tout refait en NodeJS pour
>>> beaucoup plus de souplesse en dev (adoption, facilités du langage
>avec
>>> modèle de données JSON, concision du code, évolutions, maintenance,
>>> etc...).
>>>
>>>     Actuellement, les tuiles 3D générées peuvent être au formats
>suivants:
>>> - GeoJSON
>>> - X3D (JSON)
>>> - X3D (XML)
>>>     Et à venir:
>>> - JSON pour la lib three.js
>>> - JSON pour la lib js babylon.js
>>>
>>>     J'ai une quantité assez importante de projet à développer autour
>de
>>> ça:
>>> - viewer 3D web avec globe terrestre (x3dom, three.js, babylon.js)
>>> - vue cubemap/skybox pour la navigation là où les camionettes google
>>> ne vont pas (intérieur de bâtiment, chemins en montagne, etc...)
>>> - gestion d'évènemetns temps réel dans les bâtiments (surveillance
>>> ascenseurs, clims, incendie, intrusions, etc...)
>>>
>>>     Le projet a vocation à être libre (le moins de contraintes
>>> d'exploitation possibles).
>>>
>>>     Certains d'entre vous serez-t-il intéressé par rejoindre le
>projet?
>>>
>>>     Tout type de participation serait bievenu (demandes de
>>> fonctionnalités, communications, développement, intégration, tests,
>>> etc...).
>>>
>>>     Présentaiton du projet:
>>> http://wiki.openstreetmap.org/wiki/Open_Earth_View
>>>     Projet nodejs: https://www.npmjs.com/package/osm2x3d
>>>     Projet entier:
>>> https://git.framasoft.org/pizaninja/OpenEarthView/tree/master/
>>>     Démos:
>>>     - http://www.openearthview.net/ (hébergement OVH payé par
>framasoft)
>>>     - http://www.openearthview.net/demo/cubemap_forest/forest.html
>>> (attention, 10 MO à télécharger dans la scène)
>>>
>>> Clément Igonet.
>>>
>>> _______________________________________________
>>> dev-fr mailing list
>>> dev-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev-fr
>>>
>>
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dev-fr mailing list
>dev-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev-fr

clem...@igonet.fr
_______________________________________________
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Répondre à