lundi 05 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de NickNolte :

Journal : Blender - explication du DNA

Posté par NickNolte () le 02 décembre 2008
6
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.

> Lire le journal (10 commentaires, moyenne: 2,1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Protocol Buffers

Posté par Frédéric COIFFIER () le 02/12/2008 à 17:30. (lien). É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 libre Cuauhtémoc (page perso, ) le 02/12/2008 à 18:26. (lien). Évalué à 0.

mais LES DNA, seuls les Alsaciens comprendront.

--
http://www.ssii-lejeu.com/?idp=20111
SSII , le jeu

  • [^]Re: ce n'est pas le DNA

    Posté par libre Cuauhtémoc (page perso, ) le 02/12/2008 à 18:40. (lien). Évalué à 1.

    Pour les moinsseurs, lorsqu'on va en Alsace, on parle des "Dernières Nouvelles d'Alsace", abrégés en DNA.
    voir :
    http://www.dna.fr

    --
    http://www.ssii-lejeu.com/?idp=20111
    SSII , le jeu

Elle est où l'explication ??

Posté par moi1392 () le 02/12/2008 à 18:34. (lien). É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 dark_star () le 02/12/2008 à 22:32. (lien). É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 Frédéric COIFFIER () le 02/12/2008 à 23:21. (lien). É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 Matthieu Lagouge (Jabber id, page perso, ) le 03/12/2008 à 02:15. (lien). É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 Clément David (Jabber id, page perso, ) le 03/12/2008 à 08:23. (lien). É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 :)

      --
      C# (sans runtime) + GObject = Vala

      • [^]Re: Tentative d'explication

        Posté par Clément David (Jabber id, page perso, ) le 03/12/2008 à 10:51. (lien). É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

        --
        C# (sans runtime) + GObject = Vala

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0813s (dont 0.0098 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !