Quel format pour les fichiers Sweet Home 3D ?
711 views
Skip to first unread message
Emmanuel Puybaret
Sep 19, 2014, 9:33:06 AM9/19/14
to tec...@googlegroups.com
Bonjour à tous,
Je viens vous embêter aujourd'hui avec une question sur laquelle je préfère de pas me tromper car elle engage les futures évolutions de Sweet Home 3D, mon fidèle cheval de bataille comme la plupart de vous le savent. Ce logiciel qui continue d'évoluer petit à petit toujours sous licence GNU GPL va bientôt souffler la 9ème bougie de sa première ligne de code (90000 aujourd'hui, hors commentaires, localisations, documentation et autre), et son format de fichier à besoin d'évoluer. Pas forcément qu'il ne tienne plus la route, mais plus parce qu'il risque d'être difficile à supporter sur d'autres plateformes.
L'existant :
Le format actuel d'un fichier SH3D est en fait un fichier ZIP (compressé ou pas) qui contient une entrée "Home", une entrée optionnelle "ContentDigests" et un ensemble d'entrées ou de sous-dossiers numérotés à partir de 0 :
- l'entrée "Home" qui est une sérialisation Java de la grappe d'objets décrivant le logement édité par l'utilisateur
- l'entrée optionnelle "ContentDigests" qui contient les clés SHA-1 de toutes les autres entrées du fichier SH3D. Elle est utilisée pour vérifier l'intégrité du fichier SH3D et retrouver éventuellement des ressources manquantes dans les catalogues de Sweet Home 3D lui-même, quand le fichier SH3D est endommagé, suite par exemple, à des erreurs de copie sur une clé USB que l'utilisateur retire trop tôt
- les autres entrées numérotées qui contiennent tous les fichiers des modèles 3D, les images de textures et autres ressources dont les objets Java ont besoin.
Au départ, ce format a été choisi pour sa simplicité de programmation, car le listing des classes de lecture/écriture d'un logement devait apparaître dans le livre "Les cahiers du programmeur Swing" dont Sweet Home 3D était l'étude de cas. Résultat : 250 lignes de programme Java, commentaires compris, pour lire/écrire les fichiers SH3D.
Depuis cette première version, j'ai ajouté de quoi gérer des entrées numérotées dans des sous-dossiers et l'entrée "ContentDigests", le tout avec la possibilité de réparer en partie les fichiers SH3D endommagés. On arrive maintenant à 1500 lignes de programme + quelques méthodes readObject/writeObject dans les classes des objets sérialisées qu'il a fallu ajouter pour conserver la compatibilité descendante et... ascendante : même si certaines informations ne seront pas visualisées correctement, sachez qu'on peut encore ouvrir avec la première version de Sweet Home 3D un fichier réalisé avec la dernière version 4.4. Chapeau bas au concepteur de la sérialisation Java !
L'avenir :
Le format actuel fonctionne correctement mais je sens qu'il a besoin d'évoluer car l'entrée "Home" qui contient la grappe d'objets du logement enregistré est au format de sérialisation Java. Bien que ce soit un format efficace et qui résiste bien aux évolutions des classes enregistrées dans le temps, la sérialisation Java a plusieurs inconvénients :
1. C'est un format "propriétaire" (mais documenté) qui a été conçu pour fonctionner dans un programme Java ou entre JVMs, et qui n'est pas utilisé ailleurs.
2. C'est un format binaire illisible par un humain et encore moins réparable à la main.
3. Ca n'est pas un format standard dans le monde de l'immobilier et de l'ameublement.
Pour le format ZIP, présent sur tous les OS, je ne lui trouve pas d'inconvénient sauf peut-être qu'on est capable d'atteindre de meilleures compressions avec d'autre formats plus récents, mais comme c'est au prix d'un temps d'encodage qui prend plus de temps...
Comme j'envisage de porter tout ou partie de Sweet Home 3D sur d'autres plateformes où il n'y a pas Java (comme iOS), ou pas le JRE d'Oracle (comme Android), la question se pose de faire évoluer le format des fichiers SH3D ou pas. Ce serait en effet bien de pouvoir lire des fichiers créés avec la version Desktop actuelle du logiciel, puis de pouvoir éditer les mêmes fichiers sur toutes les plateformes.
J'ai donc pensé à la solution suivante :
- Développement d'un module en C ou peut-être un autre langage (Swift ?) capable de décoder les données d'un flux d'objet sérialisé avec Java, pour lire la grappe des objets édités dans un logement.
- Quitte à écrire un décodeur de flux sérialisé, j'ai pensé au départ que je pourrai aussi écrire un encodeur pour conserver le même format, mais je crains que respecter le format de sérialisation à l'écriture soit bien plus compliqué et donc trop casse gueule, d'autant plus que sur Internet je n'ai toujours pas réussi à trouver de bibliothèque capable de lire ou écrire un flux à ce format (si vous en connaissez une, je suis preneur).
Je penche donc plutôt pour l'écriture d'un module supplémentaire programmé en Java et d'autres langages, capable d'écrire et lire la grappe des objets Sweet Home 3D en XML, ce qui est bien plus portable, pas trop compliqué à programmer et pourrait respecter les autres conditions que je me suis fixé. Du jour où j'introduis cette modification, le comportement des entrées-sorties serait alors celui-ci:
* dans la version Desktop, à la sauvegarde d'un fichier SH3D, écriture systématique de la grappe d'objets Java au format sérialisé et au format XML. Le format sérialisé ne pesant pas bien lourd comparé à tout le reste d'un fichier SH3D qui contient toutes les textures et les modèles 3D, cette entrée ZIP "historique" ne sera pas bien gênante. A l'ouverture d'un fichier SH3D, Sweet Home 3D lira en priorité le flux au format XML s'il est présent, sinon il lira le flux sérialisé comme maintenant.
* sur les futures versions iOS / Android et pourquoi pas à terme sur la version Desktop, la stratégie de lecture à l'ouverture d'un fichier SH3D serait la même que pour la version Desktop, grâce au décodeur de flux sérialisé + le parser XML. Pour la sauvegarde, écriture uniquement du flux XML. Cela aura pour conséquence d'empêcher les utilisateurs d'ouvrir un tel fichier avec une ancienne version Desktop de Sweet Home 3D, mais l'essentiel reste tout de même la compatibilité descendante. Casser la compatibilité ascendante (partiellement) une fois tous les 10 ans, ça n'est pas trop demandé quand même ! ;-)
Qe pensez-vous de cette idée ?
Après se pose la question du format XML. Pour respecter le 3ème critère (ou en tout cas s'en approcher), je penche bien pour utiliser le format BIM XML ( http://bimxml.org ) en ajoutant mes propres extensions si c'est possible. Ce format est utilisé comme format d'échange dans la construction et ça devrait ainsi permettre à terme d'importer et d'exporter des fichiers de logements à ce format. Mais je crains de me perdre dans ce format, et je crois que c'est surtout l'équivalent BIM / IFC / STEP qui est utilisé (mais ce dernier format étant binaire, je préfère le mettre à l'écart).
Alors vous me conseilleriez le format BIM ou des tags XML persos ?
Finalement, avec l'arrivée petit à petit de Java sur iOS, via RoboVM et peut-être un jour un JRE Oracle avec JavaFX, je ferais peut-être mieux d'attendre et finalement ne rien changer (mais se posera alors toujours la question de résoudre les conditions 2 et 3).
Merci d'avance pour vos conseils.
A+
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Je viens vous embêter aujourd'hui avec une question sur laquelle je préfère de pas me tromper car elle engage les futures évolutions de Sweet Home 3D, mon fidèle cheval de bataille comme la plupart de vous le savent. Ce logiciel qui continue d'évoluer petit à petit toujours sous licence GNU GPL va bientôt souffler la 9ème bougie de sa première ligne de code (90000 aujourd'hui, hors commentaires, localisations, documentation et autre), et son format de fichier à besoin d'évoluer. Pas forcément qu'il ne tienne plus la route, mais plus parce qu'il risque d'être difficile à supporter sur d'autres plateformes.
L'existant :
Le format actuel d'un fichier SH3D est en fait un fichier ZIP (compressé ou pas) qui contient une entrée "Home", une entrée optionnelle "ContentDigests" et un ensemble d'entrées ou de sous-dossiers numérotés à partir de 0 :
- l'entrée "Home" qui est une sérialisation Java de la grappe d'objets décrivant le logement édité par l'utilisateur
- l'entrée optionnelle "ContentDigests" qui contient les clés SHA-1 de toutes les autres entrées du fichier SH3D. Elle est utilisée pour vérifier l'intégrité du fichier SH3D et retrouver éventuellement des ressources manquantes dans les catalogues de Sweet Home 3D lui-même, quand le fichier SH3D est endommagé, suite par exemple, à des erreurs de copie sur une clé USB que l'utilisateur retire trop tôt
- les autres entrées numérotées qui contiennent tous les fichiers des modèles 3D, les images de textures et autres ressources dont les objets Java ont besoin.
Au départ, ce format a été choisi pour sa simplicité de programmation, car le listing des classes de lecture/écriture d'un logement devait apparaître dans le livre "Les cahiers du programmeur Swing" dont Sweet Home 3D était l'étude de cas. Résultat : 250 lignes de programme Java, commentaires compris, pour lire/écrire les fichiers SH3D.
Depuis cette première version, j'ai ajouté de quoi gérer des entrées numérotées dans des sous-dossiers et l'entrée "ContentDigests", le tout avec la possibilité de réparer en partie les fichiers SH3D endommagés. On arrive maintenant à 1500 lignes de programme + quelques méthodes readObject/writeObject dans les classes des objets sérialisées qu'il a fallu ajouter pour conserver la compatibilité descendante et... ascendante : même si certaines informations ne seront pas visualisées correctement, sachez qu'on peut encore ouvrir avec la première version de Sweet Home 3D un fichier réalisé avec la dernière version 4.4. Chapeau bas au concepteur de la sérialisation Java !
L'avenir :
Le format actuel fonctionne correctement mais je sens qu'il a besoin d'évoluer car l'entrée "Home" qui contient la grappe d'objets du logement enregistré est au format de sérialisation Java. Bien que ce soit un format efficace et qui résiste bien aux évolutions des classes enregistrées dans le temps, la sérialisation Java a plusieurs inconvénients :
1. C'est un format "propriétaire" (mais documenté) qui a été conçu pour fonctionner dans un programme Java ou entre JVMs, et qui n'est pas utilisé ailleurs.
2. C'est un format binaire illisible par un humain et encore moins réparable à la main.
3. Ca n'est pas un format standard dans le monde de l'immobilier et de l'ameublement.
Pour le format ZIP, présent sur tous les OS, je ne lui trouve pas d'inconvénient sauf peut-être qu'on est capable d'atteindre de meilleures compressions avec d'autre formats plus récents, mais comme c'est au prix d'un temps d'encodage qui prend plus de temps...
Comme j'envisage de porter tout ou partie de Sweet Home 3D sur d'autres plateformes où il n'y a pas Java (comme iOS), ou pas le JRE d'Oracle (comme Android), la question se pose de faire évoluer le format des fichiers SH3D ou pas. Ce serait en effet bien de pouvoir lire des fichiers créés avec la version Desktop actuelle du logiciel, puis de pouvoir éditer les mêmes fichiers sur toutes les plateformes.
J'ai donc pensé à la solution suivante :
- Développement d'un module en C ou peut-être un autre langage (Swift ?) capable de décoder les données d'un flux d'objet sérialisé avec Java, pour lire la grappe des objets édités dans un logement.
- Quitte à écrire un décodeur de flux sérialisé, j'ai pensé au départ que je pourrai aussi écrire un encodeur pour conserver le même format, mais je crains que respecter le format de sérialisation à l'écriture soit bien plus compliqué et donc trop casse gueule, d'autant plus que sur Internet je n'ai toujours pas réussi à trouver de bibliothèque capable de lire ou écrire un flux à ce format (si vous en connaissez une, je suis preneur).
Je penche donc plutôt pour l'écriture d'un module supplémentaire programmé en Java et d'autres langages, capable d'écrire et lire la grappe des objets Sweet Home 3D en XML, ce qui est bien plus portable, pas trop compliqué à programmer et pourrait respecter les autres conditions que je me suis fixé. Du jour où j'introduis cette modification, le comportement des entrées-sorties serait alors celui-ci:
* dans la version Desktop, à la sauvegarde d'un fichier SH3D, écriture systématique de la grappe d'objets Java au format sérialisé et au format XML. Le format sérialisé ne pesant pas bien lourd comparé à tout le reste d'un fichier SH3D qui contient toutes les textures et les modèles 3D, cette entrée ZIP "historique" ne sera pas bien gênante. A l'ouverture d'un fichier SH3D, Sweet Home 3D lira en priorité le flux au format XML s'il est présent, sinon il lira le flux sérialisé comme maintenant.
* sur les futures versions iOS / Android et pourquoi pas à terme sur la version Desktop, la stratégie de lecture à l'ouverture d'un fichier SH3D serait la même que pour la version Desktop, grâce au décodeur de flux sérialisé + le parser XML. Pour la sauvegarde, écriture uniquement du flux XML. Cela aura pour conséquence d'empêcher les utilisateurs d'ouvrir un tel fichier avec une ancienne version Desktop de Sweet Home 3D, mais l'essentiel reste tout de même la compatibilité descendante. Casser la compatibilité ascendante (partiellement) une fois tous les 10 ans, ça n'est pas trop demandé quand même ! ;-)
Qe pensez-vous de cette idée ?
Après se pose la question du format XML. Pour respecter le 3ème critère (ou en tout cas s'en approcher), je penche bien pour utiliser le format BIM XML ( http://bimxml.org ) en ajoutant mes propres extensions si c'est possible. Ce format est utilisé comme format d'échange dans la construction et ça devrait ainsi permettre à terme d'importer et d'exporter des fichiers de logements à ce format. Mais je crains de me perdre dans ce format, et je crois que c'est surtout l'équivalent BIM / IFC / STEP qui est utilisé (mais ce dernier format étant binaire, je préfère le mettre à l'écart).
Alors vous me conseilleriez le format BIM ou des tags XML persos ?
Finalement, avec l'arrivée petit à petit de Java sur iOS, via RoboVM et peut-être un jour un JRE Oracle avec JavaFX, je ferais peut-être mieux d'attendre et finalement ne rien changer (mais se posera alors toujours la question de résoudre les conditions 2 et 3).
Merci d'avance pour vos conseils.
A+
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Sylvain Rey
Sep 19, 2014, 11:48:42 AM9/19/14
to tec...@googlegroups.com
Hello
Je me permets, sans répondre directement à tes questions, de faire un parallèle avec le monde des jeux videos.* des fichiers décrivant des regroupements cohérents de ressources, qu'on nommera des "scènes"
* un répertoire de ressources (Assets) qui contient des fichiers individuels qui peuvent être vraiment de tout : modèles 3d aux formats des logiciels du marché, descriptifs d'animations, textures, fichiers sons, localisation, pourquoi pas des bases de données sous des formes variées, en bref, n'importe quelle ressource. Ca peut être aussi des DLL ou, bien sûr, du code source.* là-dessus se rajouteront dynamiquement des répertoires de cache et d'output pour les binaires (formats de ressources intermédiaires, compilés à la volée) - cette partie n'est pas gérée par l'utilisateur et est clairement nécessaire pour des raisons de performance
* on repousse la problématique du packaging binaire au dernier moment
* on peut gérer de très gros projets, où un contributeur va s'occuper de certaines textures, un autre de certains modèles 3D, etc.++
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes techos.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+un...@googlegroups.com.
Pour envoyer un message à ce groupe, adressez un e-mail à tec...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/techos .
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
Dominique Jocal
Sep 19, 2014, 11:56:48 AM9/19/14
to techos
La tactique classique c'est:
- xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, pour que ca marche tout le temps, rapidement, avec un code très simple. Migrations de versions de modèles facilitées. Ya plein d'outils pour faciliter les vérifications d'attendu dans les tests auto (xmldiff) .
- fonctionnalité d'export en format du marché, uniquement. Ne serait ce que pour gérer sans contraindre le cœur les sémantiques différentes que tu decouvriras forcément dans des scénarios complexes.
D
Emmanuel Puybaret
Sep 19, 2014, 12:12:19 PM9/19/14
to tec...@googlegroups.com
Merci Sylvain pour ton retour.
C'est très intéressant car malgré les apparences, le format actuel des fichiers SH3D est conceptuellement très proche de ce que tu décris.
En effet, un fichier ZIP (le format "extérieur" des fichiers SH3D) n'est qu'une autre façon plus pratique de manipuler une arborescence (un seul fichier pour l'utilisateur), mais plus longue à écrire (il faut écrire toutes entrées du fichier ZIP à chaque sauvegarde) et moins partageable si plusieurs utilisateurs travaillent ensemble sur le même projet.
Dans ce fichier ZIP / SH3D, les fichiers des images et des modèles 3D (pourquoi pas d'autres ressources si un jour il y aura besoin) sont aussi enregistrés tels quel dans leur format d'origine (JPEG / PNG / OBJ-MTL / 3DS / DAE...).
Je ne veux justement pas toucher à cela, et voir que d'autres font (presque) pareils me rassure d'autant plus.
Ce que je veux juste changer, c'est l'équivalent de ce que tu nomes "des fichiers décrivant le projet dans son ensemble et ses settings" qui dans un fichier SH3D est le résultat d'une sérialisation Java, pas trop portable donc.
Au cas où tu aies des idées pour cette partie-là, n'hésite pas à prolonger la discussion. ;-)
A+
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
> Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
C'est très intéressant car malgré les apparences, le format actuel des fichiers SH3D est conceptuellement très proche de ce que tu décris.
En effet, un fichier ZIP (le format "extérieur" des fichiers SH3D) n'est qu'une autre façon plus pratique de manipuler une arborescence (un seul fichier pour l'utilisateur), mais plus longue à écrire (il faut écrire toutes entrées du fichier ZIP à chaque sauvegarde) et moins partageable si plusieurs utilisateurs travaillent ensemble sur le même projet.
Dans ce fichier ZIP / SH3D, les fichiers des images et des modèles 3D (pourquoi pas d'autres ressources si un jour il y aura besoin) sont aussi enregistrés tels quel dans leur format d'origine (JPEG / PNG / OBJ-MTL / 3DS / DAE...).
Je ne veux justement pas toucher à cela, et voir que d'autres font (presque) pareils me rassure d'autant plus.
Ce que je veux juste changer, c'est l'équivalent de ce que tu nomes "des fichiers décrivant le projet dans son ensemble et ses settings" qui dans un fichier SH3D est le résultat d'une sérialisation Java, pas trop portable donc.
Au cas où tu aies des idées pour cette partie-là, n'hésite pas à prolonger la discussion. ;-)
A+
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
> Visitez ce groupe à l'adresse http://groups.google.com/group/techos.
> Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Loïc Lefèvre
Sep 19, 2014, 1:18:55 PM9/19/14
to tec...@googlegroups.com
Bonjour Emmanuel,
Pour reprendre ce que disent Sylvain et Dominique, le format JSON offre une grande souplesse y compris la possibilité d'etre modifiable a la main, pour les metadata. Ensuite, les fichiers de resources que tu mentionnes peuvent continuer d'exister comme aujourd'hui. Un format «a plat» (repertoires et fichiers non zippés) pourrait aussi etre utile lors du developpement. Enfin, as-tu pensé aux formats collada et fbx tres en vogue ? voire l'utilisation de shaders ? (Ps: je connais tres peu sweet home 3d)
bon we
Loic
Laurent Caillette
Sep 19, 2014, 1:28:34 PM9/19/14
to tec...@googlegroups.com
Je rejoins Sylvain sur l'idée d'une arborescence de fichiers avec à la
racine un descripteur -- typiquement en XML -- et des sous-répertoires
avec les textures et les modèles 3D. L'avantage de cette structure
c'est qu'elle est plus facile à versionner et à synchroniser sur le
réseau (ça marche bien avec DropBox par exemple). Ce n'est pas pour
rien qu'Apple a adopté ce fonctionnement pour Pages et Keynote, deux
applications stratégique déclinées en version iOS et synchronisables
par iCloud. L'important c'est que toutes les ressources nécessaires
soient présentes. Une question en passant, qu'en est-il des polices de
caractères ?
Pour faciliter l'échange entre utilisateurs "à l'ancienne" (mail,
disquette 5¼...) le fichier unique c'est le plus simple ; de toutes
façons les solutions ne sont pas mutuellement exclusives. SH3D
pourrait publier des modèles éclatés sur un serveur (github ou quelque
chose de plus dédié ?) tandis que les utilisateurs s'enverraient des
archives compressées.
En gros, si tu ouvres une archive compressée il te la décompresse dans
un répertoire temporaire et recompresse au moment de la sauvegarde ;
s'il y a un serveur on garde le format éclaté pour une synchro plus
économe. (Je déconseille le système de fichier virtuel, pour
comprendre ce qui se passe dedans on repasse très vite à des vrais
fichiers.)
Concernant le format de compression je suggère de jeter un coup d'œil
à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur
toutes les plateformes. Que l'utilisateur non-averti ait un peu de mal
à l'ouvrir, ça limitera ses chances de faire des bêtises.
Pour la compatibilité, il suffit que les anciennes versions puissent
lire les fichiers produits par les nouvelles versions. Je conseille de
placer le numéro de version du modèle au tout début du descripteur,
comme premier attribut de l'élément racine, qu'on puisse l'extraire
avec une regex par exemple.
Concernant le XML, je saisis l'occasion d'exhumer ce billet qui
suggère des pistes pour limiter les dégâts :
https://groups.google.com/d/topic/techos/8EXgbmyASCs/discussion
En gros il s'agit d'utiliser les attributs XML autant que possible
afin d'économiser les balises fermantes. Le résultat est finalement
assez concis. Bon faut pas rêver, l'échappement, le support de la BOM,
le parsing, ça reste assez tordu.
Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis
s'il adopte un format normalisé pour le plan de la maison. Ça obligera
d'une part à faire des trucs inutiles pour le projet, et d'autre part
à se contorsionner pour faire les trucs utiles. Pour
l'intéropérabilité, la fonctionnalité d'export devrait suffire.
La lecture des anciens fichiers avec une bibliothèque en C portable,
ça me semble tout à fait pertinent. Au moins c'est portable partout et
n'importe quel langage sait causer à une bibliothèque écrite en C.
Quant à la lecture d'objets Java sérialisés, je sais que des gars
l'ont déjà fait ; en 2000 j'ai lu un article à propos d'un
microcontrôleur qui causait le RMI.
Pour le développement d'une application graphique multiplateforme iOS
+ Android + Windows + Mac + Linux, il y a un arbitrage assez sévère
entre le coût et la qualité. Tout ce que j'ai vu de sérieux c'est
Xamarin (cher, non OSS) qui compile du C# et nécessite des
développements spécifiques à chaque plateforme cible. Ce dernier point
est un gage de crédibilité, la portabilité "transparente" (disons, du
même niveau que Java/Swing) demeurant inatteignable encore un bout de
temps. J'ai pas mal d'idées là-dessus mais ça nous emmènerait assez
loin du sujet initial, le format de fichiers.
racine un descripteur -- typiquement en XML -- et des sous-répertoires
avec les textures et les modèles 3D. L'avantage de cette structure
c'est qu'elle est plus facile à versionner et à synchroniser sur le
réseau (ça marche bien avec DropBox par exemple). Ce n'est pas pour
rien qu'Apple a adopté ce fonctionnement pour Pages et Keynote, deux
applications stratégique déclinées en version iOS et synchronisables
par iCloud. L'important c'est que toutes les ressources nécessaires
soient présentes. Une question en passant, qu'en est-il des polices de
caractères ?
Pour faciliter l'échange entre utilisateurs "à l'ancienne" (mail,
disquette 5¼...) le fichier unique c'est le plus simple ; de toutes
façons les solutions ne sont pas mutuellement exclusives. SH3D
pourrait publier des modèles éclatés sur un serveur (github ou quelque
chose de plus dédié ?) tandis que les utilisateurs s'enverraient des
archives compressées.
En gros, si tu ouvres une archive compressée il te la décompresse dans
un répertoire temporaire et recompresse au moment de la sauvegarde ;
s'il y a un serveur on garde le format éclaté pour une synchro plus
économe. (Je déconseille le système de fichier virtuel, pour
comprendre ce qui se passe dedans on repasse très vite à des vrais
fichiers.)
Concernant le format de compression je suggère de jeter un coup d'œil
à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur
toutes les plateformes. Que l'utilisateur non-averti ait un peu de mal
à l'ouvrir, ça limitera ses chances de faire des bêtises.
Pour la compatibilité, il suffit que les anciennes versions puissent
lire les fichiers produits par les nouvelles versions. Je conseille de
placer le numéro de version du modèle au tout début du descripteur,
comme premier attribut de l'élément racine, qu'on puisse l'extraire
avec une regex par exemple.
Concernant le XML, je saisis l'occasion d'exhumer ce billet qui
suggère des pistes pour limiter les dégâts :
https://groups.google.com/d/topic/techos/8EXgbmyASCs/discussion
En gros il s'agit d'utiliser les attributs XML autant que possible
afin d'économiser les balises fermantes. Le résultat est finalement
assez concis. Bon faut pas rêver, l'échappement, le support de la BOM,
le parsing, ça reste assez tordu.
Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis
s'il adopte un format normalisé pour le plan de la maison. Ça obligera
d'une part à faire des trucs inutiles pour le projet, et d'autre part
à se contorsionner pour faire les trucs utiles. Pour
l'intéropérabilité, la fonctionnalité d'export devrait suffire.
La lecture des anciens fichiers avec une bibliothèque en C portable,
ça me semble tout à fait pertinent. Au moins c'est portable partout et
n'importe quel langage sait causer à une bibliothèque écrite en C.
Quant à la lecture d'objets Java sérialisés, je sais que des gars
l'ont déjà fait ; en 2000 j'ai lu un article à propos d'un
microcontrôleur qui causait le RMI.
Pour le développement d'une application graphique multiplateforme iOS
+ Android + Windows + Mac + Linux, il y a un arbitrage assez sévère
entre le coût et la qualité. Tout ce que j'ai vu de sérieux c'est
Xamarin (cher, non OSS) qui compile du C# et nécessite des
développements spécifiques à chaque plateforme cible. Ce dernier point
est un gage de crédibilité, la portabilité "transparente" (disons, du
même niveau que Java/Swing) demeurant inatteignable encore un bout de
temps. J'ai pas mal d'idées là-dessus mais ça nous emmènerait assez
loin du sujet initial, le format de fichiers.
Emmanuel Puybaret
Sep 22, 2014, 3:23:24 AM9/22/14
to tec...@googlegroups.com
Bonjour,
Merci pour toutes suggestions. C'est vraiment sympa :-)
> La tactique classique c'est:
> - xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, [...]
> - fonctionnalité d'export en format du marché, uniquement. [...]
C'est ce qui me parait le moins risqué en effet, mais ça remet encore à plus tard l'export/import au format BIM (il y a déjà un export pur 3D au format OBJ). Comme je crois que le format BIM permet des extensions, ça aurait été pas mal de basculer tout de suite sur celui-là. Mais il vaut mieux que je soie raisonnable, sinon je ne démarrerai jamais ce chantier.
> Pour reprendre ce que disent Sylvain et Dominique, le format JSON offre une grande souplesse y compris la possibilité d'etre modifiable a la main, pour les metadata.
Je préfère tout de même XML, parce que c'est plus connu, parce que je maîtrise bien le parser SAX, parce que je ne connais pas JSON et encore moins ses pièges, et finalement parce que le parser SAX est dispo dans Java 6 et pas JSON, ce qui évite d'inclure une bibliothèque supplémentaire (avec ses dépendances éventuelles).
> Ensuite, les fichiers de resources que tu mentionnes peuvent continuer d'exister comme aujourd'hui. Un format «a plat» (repertoires et fichiers non zippés) pourrait aussi etre utile lors du developpement.
Je suis d'accord qu'explorer des fichiers dans des répertoires système, c'est le plus simple, mais les explorateurs de fichiers ZIP fonctionnent maintenant de façon quasi-transparente maintenant.
> Enfin, as-tu pensé aux formats collada et fbx tres en vogue ?
Sweet Home 3D est déjà capable d'importer des fichiers Collada/DAE. Comme c'est du XML, j'ai pensé aussi créer un format dérivé du format Collada pour Sweet Home 3D, mais je n'y crois pas.
Pour le format FBX, je n'ai pas encore vu de bibliothèques sur le web avec de nombreux objets à ce format. Donc, ça va attendre, surtout qu'en plus, je viens juste de finir d'écrire un nouveau parser pour le format 3DS. ;-)
> voire l'utilisation de shaders ?
Pour améliorer l'éclairage dans la vue 3D, j'aimerais bien, mais Java 3D n'est pas trop fait pour ça. De plus, Sweet Home 3D est déjà capable de faire aussi des rendus assez réalistes en ray-tracing dans le module de création de "photo" (voir la dernière colonne de la page http://www.sweethome3d.com/gallery.jsp )
> Je rejoins Sylvain sur l'idée d'une arborescence de fichiers avec à la racine un descripteur
> [...]
Du point de vue utilisateur, c'est quand même beaucoup plus simple et moins risqué de manipuler un fichier unique plutôt qu'une arborescence, sans compter qu'avec un seul fichier ne se pose pas le problème de la gestion des droits qui pourrait révéler de mauvaises surprises avec une arborescence.
> qu'en est-il des polices de caractères ?
Il n'y a pas de possibilité de choisir une autre police et tout texte utilise la police par défaut pour l'instant.
> SH3D pourrait publier des modèles éclatés sur un serveur
Pour la version Online, c'est déjà en partie le cas : les modèles 3D et les textures disponibles sur sweethome3d.com ne sont pas incorporés dans le fichiers SH3D, mais sont téléchargés séparément via une URL externe au lieu d'une URL "jar:" interne au fichier.
> Concernant le format de compression je suggère de jeter un coup d'œil à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur toutes les plateformes
Je viens d'essayer les différences de compression sur un gros fichier SH3D de 395 Mo non compressé (un fichier de cette taille doit représenter une très petite minorité des fichiers SH3D) : il est passé à 149,9 Mo en format ZIP compressé en utilisant le menu "Enregistrer et compresser", puis avec un logiciel externe, sa taille est passée à 137,9 Mo toujours au format ZIP compressé (oui, Java n'a pas le meilleur moteur de compression ZIP), 150,3 Mo au format BZIP, 148,4 Mo en GZIP2 et 103,5 Mo en format 7Zip / LZMA.
Donc, je ferai mieux de sauter directement au format LZMA pour obtenir un vrai gain ! Mais comme dit plus haut, l'enregistrement au format compressé étant bien plus lent, les fichiers SH3D ne sont pas compressés quand on choisit le menu "Enregistrer" de Sweet Home 3D, et je ne crois pas que le format compressé soit dans les faits très utilisé. Du coup, je me demande si ça vaut vraiment la peine d'implémenter le format LZMA parce que ça va encore plus ralentir une sauvegarde compressée, et ne connaissant pas ce format, ça va me reprendre à nouveau un paquet de temps pour trouver ce qui est réparable dans un tel fichier quand il est endommagé (si c'est possible).
> Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis s'il adopte un format normalisé pour le plan de la maison.
Ok, ok, on va éviter les paris inutiles, et désolé Laurent, tu n'auras pas mon iPad Mini. ;-)
J'utiliserai donc juste un format XML perso et relirai ton billet sur l'utilisation des attributs XML pour m'aider. Ca permettra déjà à d'autres personnes d'exploiter des fichiers SH3D si besoin. Qui sait, peut-être qu'un jour une personne va écrire un programme qui sera capable d'importer un fichier SH3D, ou encore mieux, un convertisseur au format BIM ?
> La lecture des anciens fichiers avec une bibliothèque en C portable, ça me semble tout à fait pertinent.
Bon, je vais tenter cette solution et vous tiendrai au courant.
Bonne semaine à tous,
Merci pour toutes suggestions. C'est vraiment sympa :-)
> La tactique classique c'est:
> - fonctionnalité d'export en format du marché, uniquement. [...]
C'est ce qui me parait le moins risqué en effet, mais ça remet encore à plus tard l'export/import au format BIM (il y a déjà un export pur 3D au format OBJ). Comme je crois que le format BIM permet des extensions, ça aurait été pas mal de basculer tout de suite sur celui-là. Mais il vaut mieux que je soie raisonnable, sinon je ne démarrerai jamais ce chantier.
> Pour reprendre ce que disent Sylvain et Dominique, le format JSON offre une grande souplesse y compris la possibilité d'etre modifiable a la main, pour les metadata.
> Ensuite, les fichiers de resources que tu mentionnes peuvent continuer d'exister comme aujourd'hui. Un format «a plat» (repertoires et fichiers non zippés) pourrait aussi etre utile lors du developpement.
> Enfin, as-tu pensé aux formats collada et fbx tres en vogue ?
Pour le format FBX, je n'ai pas encore vu de bibliothèques sur le web avec de nombreux objets à ce format. Donc, ça va attendre, surtout qu'en plus, je viens juste de finir d'écrire un nouveau parser pour le format 3DS. ;-)
> voire l'utilisation de shaders ?
> Je rejoins Sylvain sur l'idée d'une arborescence de fichiers avec à la racine un descripteur
> Pour faciliter l'échange entre utilisateurs "à l'ancienne" (mail, disquette 5¼...) le fichier unique c'est le plus simple
A force d'avoir vu passer des fichiers ZIP à réparer, le principal avantage que je perçois à utiliser une arborescence de fichiers est qu'il y a plus de chances que les fichiers individuels d'une arborescence soient récupérables qu'un fichier ZIP. Mais le format ZIP est bien fichu quand même et j'arrive maintenant à récupérer une bonne partie du contenu valide d'un fichier ZIP endommagé, voire même tronqué. De plus, le format ZIP peut être compressé ou pas, le non compressé étant d'ailleurs celui par défaut dans Sweet Home 3D pour des raisons de performance.
Du point de vue utilisateur, c'est quand même beaucoup plus simple et moins risqué de manipuler un fichier unique plutôt qu'une arborescence, sans compter qu'avec un seul fichier ne se pose pas le problème de la gestion des droits qui pourrait révéler de mauvaises surprises avec une arborescence.
> qu'en est-il des polices de caractères ?
> SH3D pourrait publier des modèles éclatés sur un serveur
> Concernant le format de compression je suggère de jeter un coup d'œil à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur toutes les plateformes
Donc, je ferai mieux de sauter directement au format LZMA pour obtenir un vrai gain ! Mais comme dit plus haut, l'enregistrement au format compressé étant bien plus lent, les fichiers SH3D ne sont pas compressés quand on choisit le menu "Enregistrer" de Sweet Home 3D, et je ne crois pas que le format compressé soit dans les faits très utilisé. Du coup, je me demande si ça vaut vraiment la peine d'implémenter le format LZMA parce que ça va encore plus ralentir une sauvegarde compressée, et ne connaissant pas ce format, ça va me reprendre à nouveau un paquet de temps pour trouver ce qui est réparable dans un tel fichier quand il est endommagé (si c'est possible).
> Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis s'il adopte un format normalisé pour le plan de la maison.
J'utiliserai donc juste un format XML perso et relirai ton billet sur l'utilisation des attributs XML pour m'aider. Ca permettra déjà à d'autres personnes d'exploiter des fichiers SH3D si besoin. Qui sait, peut-être qu'un jour une personne va écrire un programme qui sera capable d'importer un fichier SH3D, ou encore mieux, un convertisseur au format BIM ?
> La lecture des anciens fichiers avec une bibliothèque en C portable, ça me semble tout à fait pertinent.
Bonne semaine à tous,
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Dominique Jocal
Sep 22, 2014, 3:41:08 AM9/22/14
to techos
Qui sait, peut-être qu'un jour une personne va écrire un programme qui sera capable d'importer un fichier SH3D, ou encore mieux, un convertisseur au format BIM ?
C'est l'esprit même de l'open source !
Si la foule veut un export BIM, elle participe.
A+
Si la foule veut un export BIM, elle participe.
A+
Le 22 septembre 2014 09:23, Emmanuel Puybaret <puyb...@eteks.com> a écrit :
Bonjour,
Merci pour toutes suggestions. C'est vraiment sympa :-)
> La tactique classique c'est:
> - xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, [...]
> - fonctionnalité d'export en format du marché, uniquement. [...]
C'est ce qui me parait le moins risqué en effet, mais ça remet encore à plus tard l'export/import au format BIM (il y a déjà un export pur 3D au format OBJ). Comme je crois que le format BIM permet des extensions, ça aurait été pas mal de basculer tout de suite sur celui-là. Mais il vaut mieux que je soie raisonnable, sinon je ne démarrerai jamais ce chantier.
> Pour reprendre ce que disent Sylvain et Dominique, le format JSON offre une grande souplesse y compris la possibilité d'etre modifiable a la main, pour les metadata.
Je préfère tout de même XML, parce que c'est plus connu, parce que je maîtrise bien le parser SAX, parce que je ne connais pas JSON et encore moins ses pièges, et finalement parce que le parser SAX est dispo dans Java 6 et pas JSON, ce qui évite d'inclure une bibliothèque supplémentaire (avec ses dépendances éventuelles).
> Ensuite, les fichiers de resources que tu mentionnes peuvent continuer d'exister comme aujourd'hui. Un format <<a plat>> (repertoires et fichiers non zippés) pourrait aussi etre utile lors du developpement.
Je suis d'accord qu'explorer des fichiers dans des répertoires système, c'est le plus simple, mais les explorateurs de fichiers ZIP fonctionnent maintenant de façon quasi-transparente maintenant.
> Enfin, as-tu pensé aux formats collada et fbx tres en vogue ?
Sweet Home 3D est déjà capable d'importer des fichiers Collada/DAE. Comme c'est du XML, j'ai pensé aussi créer un format dérivé du format Collada pour Sweet Home 3D, mais je n'y crois pas.
Pour le format FBX, je n'ai pas encore vu de bibliothèques sur le web avec de nombreux objets à ce format. Donc, ça va attendre, surtout qu'en plus, je viens juste de finir d'écrire un nouveau parser pour le format 3DS. ;-)
> voire l'utilisation de shaders ?
Pour améliorer l'éclairage dans la vue 3D, j'aimerais bien, mais Java 3D n'est pas trop fait pour ça. De plus, Sweet Home 3D est déjà capable de faire aussi des rendus assez réalistes en ray-tracing dans le module de création de "photo" (voir la dernière colonne de la page http://www.sweethome3d.com/gallery.jsp )
> Je rejoins Sylvain sur l'idée d'une arborescence de fichiers avec à la racine un descripteur
> [...]
> Pour faciliter l'échange entre utilisateurs "à l'ancienne" (mail, disquette 5 1/4...) le fichier unique c'est le plus simple
A force d'avoir vu passer des fichiers ZIP à réparer, le principal avantage que je perçois à utiliser une arborescence de fichiers est qu'il y a plus de chances que les fichiers individuels d'une arborescence soient récupérables qu'un fichier ZIP. Mais le format ZIP est bien fichu quand même et j'arrive maintenant à récupérer une bonne partie du contenu valide d'un fichier ZIP endommagé, voire même tronqué. De plus, le format ZIP peut être compressé ou pas, le non compressé étant d'ailleurs celui par défaut dans Sweet Home 3D pour des raisons de performance.
Du point de vue utilisateur, c'est quand même beaucoup plus simple et moins risqué de manipuler un fichier unique plutôt qu'une arborescence, sans compter qu'avec un seul fichier ne se pose pas le problème de la gestion des droits qui pourrait révéler de mauvaises surprises avec une arborescence.
> qu'en est-il des polices de caractères ?
Il n'y a pas de possibilité de choisir une autre police et tout texte utilise la police par défaut pour l'instant.
> SH3D pourrait publier des modèles éclatés sur un serveur
Pour la version Online, c'est déjà en partie le cas : les modèles 3D et les textures disponibles sur sweethome3d.com ne sont pas incorporés dans le fichiers SH3D, mais sont téléchargés séparément via une URL externe au lieu d'une URL "jar:" interne au fichier.
> Concernant le format de compression je suggère de jeter un coup d'oeil à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur toutes les plateformes
Je viens d'essayer les différences de compression sur un gros fichier SH3D de 395 Mo non compressé (un fichier de cette taille doit représenter une très petite minorité des fichiers SH3D) : il est passé à 149,9 Mo en format ZIP compressé en utilisant le menu "Enregistrer et compresser", puis avec un logiciel externe, sa taille est passée à 137,9 Mo toujours au format ZIP compressé (oui, Java n'a pas le meilleur moteur de compression ZIP), 150,3 Mo au format BZIP, 148,4 Mo en GZIP2 et 103,5 Mo en format 7Zip / LZMA.
Donc, je ferai mieux de sauter directement au format LZMA pour obtenir un vrai gain ! Mais comme dit plus haut, l'enregistrement au format compressé étant bien plus lent, les fichiers SH3D ne sont pas compressés quand on choisit le menu "Enregistrer" de Sweet Home 3D, et je ne crois pas que le format compressé soit dans les faits très utilisé. Du coup, je me demande si ça vaut vraiment la peine d'implémenter le format LZMA parce que ça va encore plus ralentir une sauvegarde compressée, et ne connaissant pas ce format, ça va me reprendre à nouveau un paquet de temps pour trouver ce qui est réparable dans un tel fichier quand il est endommagé (si c'est possible).
> Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis s'il adopte un format normalisé pour le plan de la maison.
Ok, ok, on va éviter les paris inutiles, et désolé Laurent, tu n'auras pas mon iPad Mini. ;-)
J'utiliserai donc juste un format XML perso et relirai ton billet sur l'utilisation des attributs XML pour m'aider. Ca permettra déjà à d'autres personnes d'exploiter des fichiers SH3D si besoin. Qui sait, peut-être qu'un jour une personne va écrire un programme qui sera capable d'importer un fichier SH3D, ou encore mieux, un convertisseur au format BIM ?
> La lecture des anciens fichiers avec une bibliothèque en C portable, ça me semble tout à fait pertinent.
Bon, je vais tenter cette solution et vous tiendrai au courant.
Bonne semaine à tous,
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Le 19 sept. 2014 à 17:56, Dominique Jocal a écrit :
> La tactique classique c'est:
> - xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, pour que ca marche tout le temps, rapidement, avec un code très simple. Migrations de versions de modèles facilitées. Ya plein d'outils pour faciliter les vérifications d'attendu dans les tests auto (xmldiff) .
> - fonctionnalité d'export en format du marché, uniquement. Ne serait ce que pour gérer sans contraindre le coeur les sémantiques différentes que tu decouvriras forcément dans des scénarios complexes.
--
Dominique Jocal
Henri Tremblay
Sep 22, 2014, 11:15:04 AM9/22/14
to tec...@googlegroups.com
Juste un mini commentaire :
XML est foncièrement "has been". Tout est en JSON ou yaml au niveau données. C'est beaucoup plus compact, ça se parle vite et c'est lisible. Le json est toutefois plus usité en java. Tu penses Jackson et ça va tout seul.
Le 2014-09-22 03:23, "Emmanuel Puybaret" <puyb...@eteks.com> a écrit :
Bonjour,
Merci pour toutes suggestions. C'est vraiment sympa :-)
> La tactique classique c'est:
> - xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, [...]
> - fonctionnalité d'export en format du marché, uniquement. [...]
C'est ce qui me parait le moins risqué en effet, mais ça remet encore à plus tard l'export/import au format BIM (il y a déjà un export pur 3D au format OBJ). Comme je crois que le format BIM permet des extensions, ça aurait été pas mal de basculer tout de suite sur celui-là. Mais il vaut mieux que je soie raisonnable, sinon je ne démarrerai jamais ce chantier.
> Pour reprendre ce que disent Sylvain et Dominique, le format JSON offre une grande souplesse y compris la possibilité d'etre modifiable a la main, pour les metadata.
Je préfère tout de même XML, parce que c'est plus connu, parce que je maîtrise bien le parser SAX, parce que je ne connais pas JSON et encore moins ses pièges, et finalement parce que le parser SAX est dispo dans Java 6 et pas JSON, ce qui évite d'inclure une bibliothèque supplémentaire (avec ses dépendances éventuelles).
> Ensuite, les fichiers de resources que tu mentionnes peuvent continuer d'exister comme aujourd'hui. Un format <<a plat>> (repertoires et fichiers non zippés) pourrait aussi etre utile lors du developpement.
Je suis d'accord qu'explorer des fichiers dans des répertoires système, c'est le plus simple, mais les explorateurs de fichiers ZIP fonctionnent maintenant de façon quasi-transparente maintenant.
> Enfin, as-tu pensé aux formats collada et fbx tres en vogue ?
Sweet Home 3D est déjà capable d'importer des fichiers Collada/DAE. Comme c'est du XML, j'ai pensé aussi créer un format dérivé du format Collada pour Sweet Home 3D, mais je n'y crois pas.
Pour le format FBX, je n'ai pas encore vu de bibliothèques sur le web avec de nombreux objets à ce format. Donc, ça va attendre, surtout qu'en plus, je viens juste de finir d'écrire un nouveau parser pour le format 3DS. ;-)
> voire l'utilisation de shaders ?
Pour améliorer l'éclairage dans la vue 3D, j'aimerais bien, mais Java 3D n'est pas trop fait pour ça. De plus, Sweet Home 3D est déjà capable de faire aussi des rendus assez réalistes en ray-tracing dans le module de création de "photo" (voir la dernière colonne de la page http://www.sweethome3d.com/gallery.jsp )
> Je rejoins Sylvain sur l'idée d'une arborescence de fichiers avec à la racine un descripteur
> [...]
> Pour faciliter l'échange entre utilisateurs "à l'ancienne" (mail, disquette 5 1/4...) le fichier unique c'est le plus simple
A force d'avoir vu passer des fichiers ZIP à réparer, le principal avantage que je perçois à utiliser une arborescence de fichiers est qu'il y a plus de chances que les fichiers individuels d'une arborescence soient récupérables qu'un fichier ZIP. Mais le format ZIP est bien fichu quand même et j'arrive maintenant à récupérer une bonne partie du contenu valide d'un fichier ZIP endommagé, voire même tronqué. De plus, le format ZIP peut être compressé ou pas, le non compressé étant d'ailleurs celui par défaut dans Sweet Home 3D pour des raisons de performance.
Du point de vue utilisateur, c'est quand même beaucoup plus simple et moins risqué de manipuler un fichier unique plutôt qu'une arborescence, sans compter qu'avec un seul fichier ne se pose pas le problème de la gestion des droits qui pourrait révéler de mauvaises surprises avec une arborescence.
> qu'en est-il des polices de caractères ?
Il n'y a pas de possibilité de choisir une autre police et tout texte utilise la police par défaut pour l'instant.
> SH3D pourrait publier des modèles éclatés sur un serveur
Pour la version Online, c'est déjà en partie le cas : les modèles 3D et les textures disponibles sur sweethome3d.com ne sont pas incorporés dans le fichiers SH3D, mais sont téléchargés séparément via une URL externe au lieu d'une URL "jar:" interne au fichier.
> Concernant le format de compression je suggère de jeter un coup d'oeil à bzip2 qui compresse bien mieux que ZIP, et déjà implémenté sur toutes les plateformes
Je viens d'essayer les différences de compression sur un gros fichier SH3D de 395 Mo non compressé (un fichier de cette taille doit représenter une très petite minorité des fichiers SH3D) : il est passé à 149,9 Mo en format ZIP compressé en utilisant le menu "Enregistrer et compresser", puis avec un logiciel externe, sa taille est passée à 137,9 Mo toujours au format ZIP compressé (oui, Java n'a pas le meilleur moteur de compression ZIP), 150,3 Mo au format BZIP, 148,4 Mo en GZIP2 et 103,5 Mo en format 7Zip / LZMA.
Donc, je ferai mieux de sauter directement au format LZMA pour obtenir un vrai gain ! Mais comme dit plus haut, l'enregistrement au format compressé étant bien plus lent, les fichiers SH3D ne sont pas compressés quand on choisit le menu "Enregistrer" de Sweet Home 3D, et je ne crois pas que le format compressé soit dans les faits très utilisé. Du coup, je me demande si ça vaut vraiment la peine d'implémenter le format LZMA parce que ça va encore plus ralentir une sauvegarde compressée, et ne connaissant pas ce format, ça va me reprendre à nouveau un paquet de temps pour trouver ce qui est réparable dans un tel fichier quand il est endommagé (si c'est possible).
> Je parie un iPad Mini Retina avec Emmanuel qu'il n'aura que des ennuis s'il adopte un format normalisé pour le plan de la maison.
Ok, ok, on va éviter les paris inutiles, et désolé Laurent, tu n'auras pas mon iPad Mini. ;-)
J'utiliserai donc juste un format XML perso et relirai ton billet sur l'utilisation des attributs XML pour m'aider. Ca permettra déjà à d'autres personnes d'exploiter des fichiers SH3D si besoin. Qui sait, peut-être qu'un jour une personne va écrire un programme qui sera capable d'importer un fichier SH3D, ou encore mieux, un convertisseur au format BIM ?
> La lecture des anciens fichiers avec une bibliothèque en C portable, ça me semble tout à fait pertinent.
Bon, je vais tenter cette solution et vous tiendrai au courant.
Bonne semaine à tous,
--
Emmanuel PUYBARET
Email : puyb...@eteks.com
Web : http://www.eteks.com
http://www.sweethome3d.com
Le 19 sept. 2014 à 17:56, Dominique Jocal a écrit :
> La tactique classique c'est:
> - xml ou json perso pour les sauvegardes de travail et la conservation long terme, via une grammaire très proche de ton modèle interne, pour que ca marche tout le temps, rapidement, avec un code très simple. Migrations de versions de modèles facilitées. Ya plein d'outils pour faciliter les vérifications d'attendu dans les tests auto (xmldiff) .
> - fonctionnalité d'export en format du marché, uniquement. Ne serait ce que pour gérer sans contraindre le coeur les sémantiques différentes que tu decouvriras forcément dans des scénarios complexes.
Dominique Jocal
Sep 22, 2014, 2:39:01 PM9/22/14
to techos
JSON a un petit inconvénient je crois, la grammaire n'a pas prévu le commentaire. <!-- XML l'a prévu. -->
Mais on peut considérer cela comme un détail, ou prendre un parser qui supporte /** un format du genre */.
A+
Sylvain Rey
Sep 22, 2014, 3:58:36 PM9/22/14
to tec...@googlegroups.com
Alors si on commence un débat JSON vs XML (villains que nous sommes !), il va falloir inviter le troisième larron de la bande : Protobuf.
C'est du binaire mais c'est vraiment très performant (compact et surtout très rapide à sérialiser/désérialiser). Ca vaut donc le coup si tu as de très gros volumes (j'ai eu des uses case où je sérialisais plusieurs GB de données, répartis sur plusieurs, hum, millions d'objets... ça passe !).
Dans l'esprit, c'est le plus proche de ta sérialisation java, tout en ajoutant la compatibilité inter-langages.
Pas forcément très sexy quand on fait du mauvais esprit !
Dominique Jocal
Sep 22, 2014, 4:18:53 PM9/22/14
to techos
c'est vrai que les balises fermantes de xml, on a vu plus moderne, json donc.
m'enfin xml s'est plaint auprès de Dieu en personne quand ils ont sorti soap; le pauvre, il ne méritait pas cela.
Dominique Jocal
Emmanuel Puybaret
Sep 23, 2014, 3:04:16 AM9/23/14
to tec...@googlegroups.com
Vous êtes un peu bizarre les gars, vous donnez vos faveurs à une techno, pire un format de fichier (ce qui implique des choses plus pérennes encore), parce qu'elle est "plus moderne", a plus la "cote", ou n'est pas "has been" !
Quant à Protobuf, il est hors jeu, parce que je cherche un format texte pour qu'il soit bidouillable par n'importe qui. Ce sera moins rapide que du binaire, mais d'expérience, un parser SAX, ça peut tourner très vite si c'est bien programmé.
A+
Sylvain Rey
Sep 23, 2014, 3:41:22 AM9/23/14
to tec...@googlegroups.com
RôÔô, tu nous casses la baraque ! Comment va-t-on faire pour se vendre si on ne réinvente pas toutes nos technologies tous les deux ans ? :-D
http://en.wikipedia.org/wiki/OpenDocument
http://en.wikipedia.org/wiki/Office_Open_XML
Julien Kirch
Sep 23, 2014, 3:50:18 AM9/23/14
to tec...@googlegroups.com
Sinon l’alternative que j’ai déjà croisé plusieurs fois et que j’aime bien c’est zip + contenu sqlite car la persistance SQL a un certain nombres d’avantages.
Julien
Sylvain Rey
Sep 23, 2014, 6:15:52 AM9/23/14
to tec...@googlegroups.com
Henri Tremblay
Sep 23, 2014, 8:06:51 AM9/23/14
to tec...@googlegroups.com
L'idée de Julien est plutôt bonne. H2 va aussi te faire ça.
C'est pas une mode. C'est mieux. C'est comme si tu ne dis que tu veux faire de la peinture à l'huile. Ça marchait mais c'est toxique...
Personne n'utilise de parser SAX. C'est xstream, jaxb ou autre. C'est raisonnablement rapide et surtout ça plie le sujet en 10 minutes.
JSON, c'est plus compact, plus rapide à lire et supporté site toutes les plates-formes.
Yaml aussi. Par contre je n'en ai jamais parlé. Mais ça à la faveur pour des fichiers de propriétés ces jours-ci.
Emmanuel Puybaret
Sep 24, 2014, 3:53:44 AM9/24/14
to tec...@googlegroups.com
La base de données, ça a des côtés pratiques mais ça n'est sûrement pas enregistré pas dans un format textuel. De plus, ça oblige les personnes intéressées par l'exploitation de fichiers existants à passer par une API qu'ils on moins de chance de connaître. :-(
Personne n'utilise de parser SAX.
Ca m'étonnerait énormément d'être le seul, rien que parce que SAX sert probablement comme base à de nombreux autres types de parser XML! Et tant pis si ça me prend plus de 10 minutes, mais avec une organisation des données simples comme celle de Sweet Home 3D, ça ne me prendra pas non plus plusieurs jours.
C'est xstream
xstream = une bibliothèque en plus. Pas nécessaire pour si peu.
jaxb
jaxb = java 6 ou plus. Je ne me suis pas décidé à laisser tomber les utilisateurs sous Java 5 utilisant des Mac PowerPC, même s'il ne doit pas y en avoir des masses.
En plus, jaxb ça m'obligera sûrement à passer par des classes intermédiaires, rien que parce que les classes du modèle de Sweet Home 3D n'ont pas de constructeur par défaut. L'idée des JavaBeans c'était bien, mais pourquoi donc avoir laissé mourir les constructeurs !
A+
Henri Tremblay
Sep 24, 2014, 5:20:56 PM9/24/14
to tec...@googlegroups.com
Évidemment, les parsers utilisent SAX. Mais c'est les seuls :-P
JAXB, tu dois avoir un implémentation Java 5. Mais en pratique, il ne doit pas te rester beaucoup d'utilisateur de Java 5.
Tu dois pouvoir mettre un constructeur privé pour JAXB je crois.
Je ne connais pas sqlite. Par contre, H2 est bien en texte. La base de données est une liste d'insert.
Reply all
Reply to author
Forward
0 new messages