| ... | ... | @@ -2,170 +2,6 @@ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## SolidWorks
|
|
|
|
|
|
|
|
* hiérarchie d'assemblage (assembly, sub-assembly) et de pièces (parts)
|
|
|
|
* notion d'axe: un axe peut être défini pour un Gonio (a priori il manque de l'information pour définir en théorie le chemin de course)
|
|
|
|
* notion de configuration :utilisée typiquement pour 3 positions: median, min, max
|
|
|
|
* notion de contrainte : un assemblage de pieces est defini par les pieces + un ensemble de contraintes qui decrivent l'agencement des pieces les unes par rapport aux autres
|
|
|
|
|
|
|
|
Q: peut-on retrouver le chemin de course en fonction de min, max, axe?
|
|
|
|
Q: est-il facile de charger toutes les données d'un modèle SolidWorks?
|
|
|
|
liens:
|
|
|
|
http://www.cadcam-e.com/development-tools/Open-data-exchange-sdk.aspx
|
|
|
|
http://stackoverflow.com/questions/1024323/starting-point-for-learning-cad-cae-file-formats
|
|
|
|
|
|
|
|
Trouver la solution la plus appropriée (simple) pour récupérer _toutes_ les infos
|
|
|
|
|
|
|
|
## Notes sur les axes
|
|
|
|
|
|
|
|
* codeur calibré par constructeur
|
|
|
|
* a priori, median = valeur 0 du codeur
|
|
|
|
* codeur donne un angle
|
|
|
|
* coefficient de "transfert" (donné par service mécanique) + unité => angle ou mouvement réel
|
|
|
|
|
|
|
|
2 types d'axe: rotation, translation.
|
|
|
|
La translation est simple : sur un segment de droite.
|
|
|
|
La position en unité est calculée dans Nomad.
|
|
|
|
|
|
|
|
RQ: il manque une distance pour un axe rotation: ex: Gonio. Caractéristique de l'axe SolidWorks?
|
|
|
|
Les butées mécaniques: ne doivent jamais être atteintes sauf dans le cas boucle ouverte pour déterminer le 0.
|
|
|
|
Le service mécanique les déterminent.
|
|
|
|
Nomad a les butées min et max qui sont à l'intérieur des butées mécaniques (il faudrait idéalement la position précise des butées Nomad, au moins un point).
|
|
|
|
|
|
|
|
Mais il manque de l'information sur certains assemblages: les axes ne sont pas toujours renseignés. On peut le rajouter par la suite.
|
|
|
|
Un instrument est un assemblage d'assemblage (avec références).
|
|
|
|
|
|
|
|
Actuellement, 3 types de modélisation d'instruments:
|
|
|
|
- ExtremeD, Thalès entièrement modélisés
|
|
|
|
- D10+ : nouveautés modélisées, le reste en scan 3D
|
|
|
|
- D20 : pas de plan d'ensemble
|
|
|
|
|
|
|
|
On pourra à la fois tester les modèles SolidWorks ainsi que le scan 3D.
|
|
|
|
|
|
|
|
## Chargement des mesh à partir de Solidworks
|
|
|
|
|
|
|
|
### Méthodes
|
|
|
|
|
|
|
|
* plug-in Simscape Multibody Link
|
|
|
|
* export de la hiérarchie, des contraintes, des géométries
|
|
|
|
* configurations : on doit faire un export par configuration, puis une analyse des différences...
|
|
|
|
* bibliothèque d'import : ODX
|
|
|
|
* à tester
|
|
|
|
* plug-in Simlab Collada Exporter
|
|
|
|
* Graphe de scène uniquement, perte des contraintes
|
|
|
|
* Blender crash quand on importe un des fichiers fournis par ce plugin
|
|
|
|
* coder notre propre plug-in SOLIDWORKS ?
|
|
|
|
|
|
|
|
### Nettoyage du modèle
|
|
|
|
|
|
|
|
* réorienter les faces
|
|
|
|
* orientation, translation initiale
|
|
|
|
* simplification des mesh
|
|
|
|
On peut appliquer le calcul d'une enveloppe convexe (outil ou à la main).
|
|
|
|
Gilles est intéressé.
|
|
|
|
Tester outil payant? voir ce qui se passe avec les vis, etc.
|
|
|
|
https://www.reddit.com/r/gamedev/comments/1xqr8o/3d_model_simplification_need_help_finding_a_tool/
|
|
|
|
Définir une library soi-même? un outil qui définit une enveloppe (tester différentes formes d'enveloppes).
|
|
|
|
On peut tenir compte de la forme "industrielle", pas de surface "libre" mais des parallélépipèdes, cercles, etc.
|
|
|
|
Faire une première passe automatisée? puis des choix à faire à la main?
|
|
|
|
Il y a plusieurs stratégies à essayer (approche générique avec outil existant, approche à la main soi-même).
|
|
|
|
Idée: générer une texture comme version simplifiée (ex: les vis deviennent un élément de texture).
|
|
|
|
|
|
|
|
#### Blender
|
|
|
|
|
|
|
|
On peut utiliser Blender, au moins dans un premier temps, pour faire un script chargeant les géométries qui les nettoie et les ré-exporte.
|
|
|
|
|
|
|
|
Ligne de commande pour exécuter un script python avec blender : `blender --background --python script.py`
|
|
|
|
|
|
|
|
*Note :* penser à terminer le script par `exit()` pour pouvoir automatiser
|
|
|
|
|
|
|
|
### Edition
|
|
|
|
|
|
|
|
* faire le lien entre les axes de Nomad et ceux du modèle (calculés ou ajoutés manuellement)
|
|
|
|
* proposer des liens probables : en fonction des différences/similarités
|
|
|
|
* à faire tester : besoin de feedback utilisateur
|
|
|
|
|
|
|
|
## Rendu 3D
|
|
|
|
|
|
|
|
* Le plus joli, réaliste ou alors utile (couleurs?)
|
|
|
|
* Multi-résolution?
|
|
|
|
* JavaFX est la solution la plus portable
|
|
|
|
|
|
|
|
Le but étant d'avoir un projet "scalable" tel qu'on puisse l'utiliser avec rendu fluide sur une tablette ainsi qu'un PC.
|
|
|
|
Q: JavaFX 3D? y'a-t'il des libs/moteurs 3D?
|
|
|
|
|
|
|
|
Idée: mouvement théorique à confronter avec réalité (calibrage en réel à faire?)
|
|
|
|
|
|
|
|
## Etapes
|
|
|
|
|
|
|
|
1. Modèle SolidWorks
|
|
|
|
2. Modèle chargeable
|
|
|
|
conversion des pièces, assemblages, axes
|
|
|
|
(solutions: export (quel type?), import (C++ si il faut), conversion
|
|
|
|
3. Simplification de la géométrie
|
|
|
|
(stratégies)
|
|
|
|
4. Edition du modèle
|
|
|
|
ajout d'information
|
|
|
|
(au moins identification des axes du modèle 3D avec axes Nomad)
|
|
|
|
visualisation, sélection 3D
|
|
|
|
application desktop
|
|
|
|
application android
|
|
|
|
5. Intégration avec Nomad
|
|
|
|
liaison dynamique, visu dynamique
|
|
|
|
6. Détection de collisions
|
|
|
|
par la visu
|
|
|
|
par calculs
|
|
|
|
|
|
|
|
On peut faire plusieurs étapes simplifiées d'un coup afin d'avoir une vue d'ensemble: commencer par une table rotation.
|
|
|
|
|
|
|
|
## Technologies
|
|
|
|
|
|
|
|
JavaFX: utilisable sur tablette:
|
|
|
|
Gluon
|
|
|
|
http://www.meetup.com/svjugfx/events/221806020/
|
|
|
|
http://nighthacking.com/javafx-on-mobile-by-johan-vos/
|
|
|
|
http://www.slideshare.net/steveonjava/javafx-on-mobile-by-johan-vos
|
|
|
|
|
|
|
|
A voir si rendu en C++ le plus optimal
|
|
|
|
http://gigavoxels.imag.fr
|
|
|
|
http://evasion.imag.fr/~Fabrice.Neyret/demos/#webGL
|
|
|
|
https://www.inria.fr/centre/grenoble/actualites/une-promenade-virtuelle-dans-notre-galaxie
|
|
|
|
|
|
|
|
### Moteurs envisageables
|
|
|
|
|
|
|
|
* JOGL
|
|
|
|
* ? compatibilité android
|
|
|
|
* ? qualité du rendu
|
|
|
|
* ? capacités
|
|
|
|
* ? perfs
|
|
|
|
* JavaFX
|
|
|
|
* + compatibilité
|
|
|
|
* - qualité du rendu
|
|
|
|
* - capacités
|
|
|
|
* ? perfs
|
|
|
|
* WebGL :
|
|
|
|
* ? compatibilité android : version suffisante, intégration dans une appli ?
|
|
|
|
* + qualité de rendu
|
|
|
|
* + liberté
|
|
|
|
* + capacités
|
|
|
|
* ? performances lors d'une intégration Java
|
|
|
|
* moteurs : Three.js, Babylon.js, PlayCanvas (compatibilité WebGL 2 en cours de développement)
|
|
|
|
* OpenGL ES
|
|
|
|
* + compatibilité
|
|
|
|
* + qualité de rendu (dépend du moteur ?)
|
|
|
|
* + liberté
|
|
|
|
* ? capacités : moteurs existants ? à creuser
|
|
|
|
* [rajawali engine](https://github.com/Rajawali/Rajawali)
|
|
|
|
* [libgdx](https://libgdx.badlogicgames.com/)
|
|
|
|
* [bonzai engine](http://bonzaiengine.com/index.php)
|
|
|
|
* [jPCT API](http://www.jpct.net/index.php) ([Exemple](https://play.google.com/store/apps/details?id=com.kisionlab.tapleavesfree))
|
|
|
|
* OpenGL
|
|
|
|
* - compatibilité
|
|
|
|
* + perfs
|
|
|
|
* + qualité et liberté
|
|
|
|
|
|
|
|
### Collisions
|
|
|
|
|
|
|
|
* [Physisjs](https://github.com/chandlerprall/Physijs) : plugin three.js pour la simulation physique (seule la partie détection de collisions nous intéresse a priori ?)
|
|
|
|
## Notes
|
|
|
|
|
|
|
|
See the [notes](notes) |
