Journal Blender - explication du DNA

Posté par  .
Étiquettes :
6
2
déc.
2008
Un petit journal rapide, sans prétention.

Je suis un peu le developpement de Blender, notamment la très attendu 2.50 et outre que ce petit programme m'impressionne déjà du haut de ces 15Mo, je suis toujours enchanté de voir ce genre de pratiques astucieuses expliquées.

En gros, ça présente l'évolution de la façon dont Blender structure ses données:
http://www.blendernation.com/2008/12/01/blender-dna-rna-and-(...)

Je n'ai pas une très grande expérience dans le developpement d'application, ça peut donc paraître trivial pour certains, toujours est-il que je trouve la chose géniale.

  • # Protocol Buffers

    Posté par  . Évalué à 5.

    Comme dit dans l'article, Blender utilise une méthode de sérialisation binaire proche de Protocol Buffers de Google :
    https://linuxfr.org//~Snarky/26911.html

    Par contre, Blender a implémenté ce mécanisme bien avant que Google publie son protocole. Ca n'a rien d'extraordinaire mais c'est tout de même très astucieux et bien pratique.

  • # ce n'est pas le DNA

    Posté par  . Évalué à 0.

    mais LES DNA, seuls les Alsaciens comprendront.

  • # Elle est où l'explication ??

    Posté par  . Évalué à 3.

    j'ai suivi ton lien et je n'ai pas trouvé d'explication sur le fonctionnement de leur format et comment ils assurent la compatibilité.
    J'ai un problème de navigateur ou de cerveau (sûrement les deux...) ? Parce que ça m'intéresse vraiment et j'aimerai savoir comment ils font ça.

    • [^] # Re: Elle est où l'explication ??

      Posté par  . Évalué à 1.

      page généraliste sur l'archi de blender
      http://www.blender.org/development/architecture/

      http://wiki.blender.org/index.php/BlenderDev/Blender2.5/
      http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Data(...)

    • [^] # Re: Elle est où l'explication ??

      Posté par  . Évalué à 2.

      pour un resumé qui donne une idée vraiment rapide :) :

      dna c'est l'equvalent de ADN en francais, oui oui le truc biologique

      http://en.wikipedia.org/wiki/DNA
      http://fr.wikipedia.org/wiki/Acide_d%C3%A9soxyribonucl%C3%A9(...)

      le plus gros avantage c'est apparement que le format de fichier DNA permet de lire meme les sauvegardes des version 1.0 de blender

      me demande pas pourquoi, je ne sais pas. mais ce ne serais pas mieux pour open office ce genre de truc ?

      • [^] # Re: Elle est où l'explication ??

        Posté par  . Évalué à 1.

        OpenOffice 3.0 (format OpenDocument 1.1 si je ne me trompe pas) ouvre les fichier de OpenOffice 2.0 (qui sauvait en OpenDocument 1.0).

        Donc, ça fonctionne.

      • [^] # Re: Elle est où l'explication ??

        Posté par  . Évalué à 3.

        Alors personnellement je n'y connais rien en formats de données ni les pro et cons dans leur utilisation dans de tels programmes.

        Mais pour OpenOffice, je crois que c'est mort, parce que si on change le format de données maintenant, d'une part ça ne va pas enthousiasmer tous ceux qui ont trimé pour la normalisation ISO, ceux qui ont implémenté ou commencé à implémenter le support d'ODF dans leurs suites, et enfin je vois mal en quoi changer radicalement la manière de stocker les données va faciliter la rétrocompatibilité...

        Je crois que pour Blender, l'avantage, c'est que c'est comme ça depuis le début (ou presque), non?

      • [^] # Tentative d'explication

        Posté par  (site web personnel) . Évalué à 3.

        D'après ce que j'ai compris leur sDNA (pour struct DNA) permet de représenter un objet de façon arborescente (jusque le identique à XML) et de le stocker dans un format binaire.

        Typiquement toutes les données sont typées et enregistrées suivant un format binaire connu et non-changé (pour google : [http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)]). On stocke alors une représentation des données à la version N (le modèle en UML ou la struct en C) ainsi que les données elle-mêmes.

        A la lecture on connaît la représentation des données à la version actuelle M et on sait que l'encodage n'a pas changé. Toutes les données sauvegardé sont chargés dans la représentation des données M suivant l'algorithme suivant :
        - si l'élément existe dans N et dans M alors on le charge directement
        - si l'élément existe dans N mais pas dans M on l'ignore
        - si l'élément existe dans M mais pas dans N on le fixe à une valeur par défaut.

        En appliquant ces règles on conserve une portabilité binaire entre les versions si les représentations de données ne changent pas trop.

        Concernant les différences avec XML on peut considérer ceci :
        - Un codage binaire est beaucoup beaucoup beaucoup plus performant que du XML
        - Un codage binaire est illisible pour un humain
        - En XML on peut réaliser des règles de transformations XML -> XML donc la portabilité entre versions est toujours assurée à partir de ses règles

        Sur ce bonne lecture :)

        • [^] # Re: Tentative d'explication

          Posté par  (site web personnel) . Évalué à 2.

          (La suite)

          Pros sDNA (ou Protocol Buffer) :
          - Les performances sont excellentes (pas d'analyse de texte lourde)
          - Représentation et données stocké dans un même fichier (facilite le suivi de versions)

          Cons sDNA :
          - ne permet pas d'interchanger des données entre programmes écrit dans différents langages (ProtocolBuffer de google génère les structures de données dans chaque langage à partir d'une description)
          - ne fournit pas de facilitées pour valider et transformer les données

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.