Fonction du bouton

[SebCanet]

Export en DAE : avez-vous trouvé la documentation ?

[zeptoline]

Dans la documentation de Sweet-home, j'ai trouvé la classe HomePane, qui exporte en OBJ la fenêtre 3D. Dans cette même classe est défini un objet OBJExporter qui est utilisé pour faire cet export.

Je pense qu'il serait possible de réutiliser cet objet, qui prend déjà toutes les fournitures de l'objet Home et qui les sauvegarde dans un fichier. Du coup, il faudrait comprendre un peu mieux le format DAE et tenter d'écrire sous ce format les fournitures, dans une classe DAEExporter, du coup.

Un problème serait d'essayer d’accéder à l'objet HomePane depuis un plugin, mais ça devrait être possible avec un peu plus de temps

[SebCanet]

Je viens de me plonger dans le code, et effectivement je pense que c'est la mailleure piste. Déjà on peut compiler un fork avec cette fonction remplaçant l'export OBJ par le DAE.

[zeptoline]

Bon, après avoir bien analysé le code, j'ai compris à peu près le mécanisme pour l'export en OBJ. Le code récupère des nœuds de l'objet 3D, et utilise la fonction d’écriture en récursion pour avoir tous les enfants de ce nœud, jusqu'à avoir l'objet complet.

J'aurais juste une question à ce niveau, est-ce que vous auriez une idée plus complète de ce qu'est un nœud ? Je comprends à peu près le principe, mais je n'ai pas trouvé de documentation dessus.

Sinon, pour récupérer ces nœuds, c'est bon. Il faudra juste continuer à essayer de comprendre le .dae et tenter des exportation depuis SH3D (Matthieu se charge de comprendre, et ensuite on le codera).

Maintenant, pour tester, on a essayé une nouvelle fois de convertir (en utilisant un convertisseur en ligne) le .obj en .dae, et le seul problème que nous rencontrons, c'est au niveau des murs, qui s'affichent bizarrement (ce qu'on savait déjà). Mis-à-part ça, les autres meubles sont à peu près bien rendu, il manque juste les textures, mais c'est dû à la conversion faites en ligne (on aura pas ce problème une fois qu'on fera la conversion depuis SH3D).

Du coup, j'ai eu comme idée que, dans la sélection des objets à exporter, on récupère les murs et on prends leurs attributs (leurs hauteurs et leurs longueurs, et à voir pour leurs profondeurs, dans un second temps peut-être), puis de recréer un nouvel objet, plus simple, qui ne sera qu'une face affichable dans SketchUp. Ça pourrait permettre d'éviter les erreurs d'affichage qu'on a vu, ce qui serait la solution à notre problème.

Je tenterais de faire ça dans les prochains jours, et je mettrais le résultat sur Github

[SebCanet]

Pour moi un noeud est l'intersection de lignes. Pour les conversions avez vous testé ce logiciel : http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=20481519 ?

Pour l'idée de "tricher" avec l'export c'est une très bonne idée si cela permet un gain non négligeable d' amélioration dans le rendu.

Pour la documentation, avez vous regardé ça : http://www.sweethome3d.com/fr/creerMeubleSweetHome3D.pdf http://download.java.net/media/java3d/javadoc/1.5.1/com/sun/j3d/loaders/objectfile/ObjectFile.html

[zeptoline]

La solution que j'ai évoqué a été testé, et les résultats sont plutôt prometteurs.

Voici le code, plutôt simple au final, pour empêcher les murs d'avoir des problèmes sur Sketchup. Il s'avère que les murs ont des getters et setters, dont un setter pour l’épaisseur :

if(item instanceof Wall)
            ((Wall)item).setThickness(0.1f);

Bon, c'est plutôt minimaliste, mais ça marche. Matthieu est en train d'en faire des screenshots pour pouvoir le montrer.

Du coup, il faudrait pouvoir exporter le résultat directement en dae, depuis Sweet home. L'export depuis le site web est plutôt pénible (jusque là, nous avons utilisé http://www.greentoken.de/onlineconv/ comme convertisseur). Matthieu continue de s'en charger.

Du coup, je vais continuer de regarder les différents problèmes que l'export peux faire, ce n'est pas impossible qu'il y en ai d'autre.

[LordInateur]

Ci-dessous une image du resultat. A droite le fichier généré sans modification, et à gauche la version corrigée. PS : le fichier source n'est pas exactement le même pour les deux images

[LordInateur]

[zeptoline]

J'ai fini d’implémenter l'exportation dans le plugin même. J'ai mis à jour le github avec les dernières sources, et j'ai ajouté une release du dernier jar.

L'export se fait en obj, et l'import sur Sketch-up se fait avec le plugin FluidImporter, qui permet de garder les textures, alors que les importer en dae ne les garde pas (on pourra toujours continuer les recherches sur le dae).

Je ferme donc cette issue, si on a d'autre questions, nous irons dans l'issue sur le décryptage de dae.

[SebCanet]

Du coup quelle est la plus value par rapport à la fonction déjà existante ? Et FluidImporter est payant au delà de 15 jours.

[zeptoline]

J'ai repris les méthodes d'export déjà existantes, mais en appliquant les changements que nous avions effectués, comme ça il ne faut que mettre le plugin plutôt que de devoir recompilé le code source.

Nous avons aussi utilisés MeshLab pour convertir en DAE et observer le résultat obtenu, mais ce qui est bizarre c'est que MeshLab montre le .DAE avec des textures, mais lors de l'import sur SketchUp, les textures disparaissent. En imprtant le .obj avec FluidImporter, cependant, les textures sont conservés et visible sur Sketchup (Matthieu avait pris des captures d'écran, je lui demanderai de les postés dès demain). Mais cette perte de texture est un autre problème que nous essayeront de corriger.

Du coup, ce n'est pas encore parfait, mais on a déjà une base qui semble marcher pour le moment avec le plugin (jusqu'à la fin de la version gratuite de FluidImporter, en tout cas..) sur laquelle on pourra se baser pour la suite.