Journal Pycao version 0.9

Posté par  . Licence CC By‑SA.
Étiquettes :
15
3
juil.
2019

Bonjour à tout le monde,

Pycao est un modeleur 3D en python. C'est à dire que vous écrivez du code python dans votre éditeur favori pour décrire vos objets 3D. Il peut être utilisé à titre graphique pour de jolies images, comme logiciel de CAO pour des projets personnels nécessitant des mesures précises, ou pour des scientifiques souhaitant un outil sans IDE pour interfacer facilement des données scientifique.

Vous trouverez en suivant ce lien une présentation des choix techniques et des objectifs pour décider si Pycao peut vous être utile.

La version 0.9 est sortie. Il est en version préfinale. La version 1.0 sera essentiellement du nettoyage de code par rapport à la version 0.9.

Quelques images: Architecture Meuble

  • # lien avec les autres projets

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

    Quels sont les liens avec Openscad, Opencascade ainsi qu'avec Cadracks (down depuis quelques semaines) ? D'ailleurs je ne connais pas tellement la différence entre chacun d'eux.

    • [^] # Re: lien avec les autres projets

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

      Ca mérite une dépêche non ?

    • [^] # Re: lien avec les autres projets

      Posté par  . Évalué à 2.

      Il y a quelques comparaisons avec les logiciels existant sur la page de doc Pycao.

      Pour ce que j'en comprends.

      Opencascade est une bibliotheque bas niveau. Pycao a l'opposé se veut le plus haut niveau possible pour faciliter le travail de la personne qui fait son projet. Pycao utilise povray en bas niveau. En fait, pycao convertit les instructions de haut niveau en des instructions povray de bas niveau, et c'est povray qui gere la présentation graphique.

      La partie conversion de Pycao vers povray n'est pas tres importante ( quelques centaines de lignes de code). Donc on devrait pouvoir exporter vers opencascade au lieu de povray via pythonocc. Il faudrait adapter la partie export de pycao pour quelqu'un qui est motivé. Le gros du boulot est de comprendre openCascade : pas de tutoriel pythonocc, Ou de comprendre Pycao pour quelqu'un qui connait pythonocc.

      Openscad est destiné aux imprimantes 3d me semble-t-il. Il exporte du stl (pas pycao). Facile en prendre en main, bien pour des petits projets (ce qui est souvent le cas des projets sur imprimante 3d). Mais tres bas niveau avec plein de coordonnées, donc me semble perilleux d'aborder un truc complexe avec openscad. Pas de rendu photo-realiste dans openscad.

      • [^] # Re: lien avec les autres projets

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

        Et ça s'interface avec Freecad également ?

        • [^] # Re: lien avec les autres projets

          Posté par  . Évalué à 2.

          Pycao n'est pas suffisamment mûr pour être interfacé me semble-t-il. Si on interface avec d'autres logiciels maintenant, ca va rigidifier certaines composantes alors que certaines simplifications sont sans doute encore possibles et souhaitables.

          En gros, le but est d'aboutir a une descripion simple et lisible des scenes 3D en langage semi-naturel. L'approche est empirique. Quand il y a galère pour décrire un objet 3D ou qu'on le fait en produisant du code non lisible, quand on sent que des objets similaires se manipulent avec des syntaxes différentes difficiles a memoriser, il faut changer le code dans Pycao. La priorité est l'utilisateur final, qui doit pouvoir avoir une description simple et lisible de son objet.

          Il n' y aura probablement pas de gros changements a venir. Mais quelques changements a la marge seront sans doute souhaitables et il serait dommage de rigidifier le projet en l'état.

      • [^] # Re: lien avec les autres projets

        Posté par  . Évalué à 2.

        La partie conversion de Pycao vers povray n'est pas tres importante ( quelques centaines de lignes de code). Donc on devrait pouvoir exporter vers opencascade au lieu de povray via pythonocc. Il faudrait adapter la partie export de pycao pour quelqu'un qui est motivé. Le gros du boulot est de comprendre openCascade : pas de tutoriel pythonocc, Ou de comprendre Pycao pour quelqu'un qui connait pythonocc.

        Permets moi de douter de la facilité d'un port vers OpenCascade. Il faudrait déjà savoir de quel type de CAO on parle, Boundary representation (Brep) ou Constructive Solid Geometry (CSG).

        OpenCascade permet les deux mais la partie Brep que je connais un peu est un enfer sur terre de compléxité, si la partie CSG est aussi complexe, il est peu probable de faire un pont vers OpenCascade en une centaine de lignes. Et du coup on peut se demander pourquoi ne pas être parti de pythonocc, qui est déjà assez haut niveau.

        Il serait intéressant que l'auteur du journal détail ces choix, s'il les maîtrise.

        • [^] # Re: lien avec les autres projets

          Posté par  . Évalué à 2.

          Bonjour Freejeff. Il faut bien comprendre que Pycao traite principalement de la partie logique de la 3D, independamment de la technique utilisee pour la representation finale des objets. On peut donner une representation geometrique des objets sans (ou avec tres peu de) coordonnées comme le ferait un menuisier dans son atelier ou comme le faisaient les grecs avant l'invention des coordonnées cartesiennes. L'essentiel étant que le langage du menuisier soit suffisamment précis pour qu'il n'y ait pas d'ambiguité dans l'objet qu'il veut décrire. Si les objets sont définis sans ambiguité par le menuisier, ou par la personne qui code informatiquement, on peut alors exporter cet objet vers des supports materiels divers (mesh, representation mathematique avec des fonctions, fichier povray…).

          Si je devais donner une analogie, c'est comme pour un fichier midi quand on joue sur un clavier. Le fichier midi code de facon logique ce que tu joues, a quel moment tu appuies sur une touche et a quelle vitesse, mais ce n'est pas un fichier musical. Il faut ensuite un sampler pour traduire les informations logiques codees dans le fichier midi vers un fichier son.

          Ici, c'est pareil. Pycao traite principalement des informations logiques qui permettent de caracteriser les objets. En ordre de grandeur, l y a aujourd'hui environ 7 mille lignes de code dont seulement 300 ou 400 sont dediées a l'export vers Povray, le reste étant dédié à la manipulation logique des objets.

          Si on voulait exporter des mesh depuis pycao, il faudrait essentiellement un logiciel qui manipule des mesh et qui gere la csg nativement, avec une api python bien documentée. Je peux me tromper, mais il me semble qu'avec un tel logiciel, on pourrait remplacer le module d'export vers povray par un module d'export vers des mesh.

          Un logiciel de manipulation de mesh et la csg en python bien documenté et perenne n'est pas facile a trouver en logiciel libre. Je suis preneur de tout retour d'experience dans ce domaine. Pythonocc ne fait pas le job car la documentation est a mon gout insuffisante comparativement au niveau de complexité. Le risque est grand de s'enliser plusieurs mois dans Pythonocc avant de pouvoir avoir une vision globale.

  • # Povray bouge encore ?

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

    En lisant la doc je vois que c'est du povray derrière ! Quelle belle surprise !

    J'ai essayé de me remettre il y a quelques années dans povray, fort de mon expérience désormais acquise en POO, ou langage fonctionnel. J'ai trouvé ça d'un lourd… impossible d'accéder de faire des syntaxes telles que texture.pigment , ou object1.transformation = object2.transformation…

    Comment Pycao se positionne par rapport à povray ? Toutes les fonctions du langage sont prise en charge ? (media, photon etc) Ça a du demander un boulot de fou…

    Je vais tester, et merci pour la diffusion !

    • [^] # Re: Povray bouge encore ?

      Posté par  . Évalué à 1.

      Non, toutes les fonctionnalités de Povray ne sont pas implémentées. N'ont été conservées que celles qui sont essentielles.

      En revanche, il y a des fonctionnalités supplémentaires pour faciliter le codage. Quelques exemples non exhaustifs:

      • on peut formuler en langage semi-naturel des instructions du genre "ouvrir le tiroir jusqu'a ce que la poignee soit au niveau de cet autre objet" ou "tourner l'aiguille de l'horloge pour que la pointe de l'aiguille soit sur le 3" tandis qu'il faut indiquer les operations en coordonnees dans povray.
      • Le module courbes fait des constructions de point intermediaire en background pour passer par les points donnés avec vitesse prescrite alors qu'il faut faire les calculs a la main dans povray et recoller les bouts de courbe
      • On peut faire des collages: on colle le verre de la montre sur le cadran, le cadran sur le bracelet et quand on demande de bouger le bracelet sur la main d'un personnage, toute la montre (bracelet+cadran+verre) bouge. Dans povray, il faut bouger independamment chaque sous-objet

      • [^] # Re: Povray bouge encore ?

        Posté par  . Évalué à 2. Dernière modification le 03 juillet 2019 à 21:07.

        On peut faire des collages: on colle le verre de la montre sur le cadran, le cadran sur le bracelet et quand on demande de bouger le bracelet sur la main d'un personnage, toute la montre (bracelet+cadran+verre) bouge. Dans povray, il faut bouger independamment chaque sous-objet

        On peut aussi sur POVRay heureusement. L'animation serait juste ingérable sinon :o

        • [^] # Re: Povray bouge encore ?

          Posté par  . Évalué à 1.

          Oui, tu as raison, merci de la remarque. Je vais preciser pour que ce soit plus clair.

          Dans povray, on fait des unions, C'est a dire qu'on a un objet global. Une fois que l'union est faite, toutes les operations appliquees sur l'union s'appliquent a l'ensemble des sous parties (intersection, couleur…) et on n'a plus guere d'acces aux sous-parties sauf a changer le code en amont.

          Dans pycao, il y a une union, comme dans povray, mais on a encore acces aux sous-parties. On peut changer une union deja construite en ajoutant du code en aval. Il y a aussi un collage qui est differente de l'union et qui est une operation asymetrique du type pere fils : le deplacement du pere implique le deplacement du fils, mais pas l'inverse. Dans cette relation de collage, il ne s'agit pas d'un objet global. Cela n'agit que sur les deplacements mais les objets restent mutuellement independants pour les operations de CSG ou de texturage. Il y a donc plusieurs niveau de granularite' en fonction des besoins qu'on a.

          • [^] # Re: Povray bouge encore ?

            Posté par  . Évalué à 2.

            Via des variables tu peux quand même avoir pas mal de contrôle sur les objets individuellement a posteriori. Créer une relation de parentalité ne devrait pas être impossible (POV est turing complet après tout), on pourrait même imaginer de l'armature, de l'IK et tout le toutim, soyons fou. Mais est-ce que ça vaudrait l'effort ? Probablement pas. On préfère faire tout ça tranquillou dans le modeleur qui pilote le machin.

  • # le code correspondant aux images

    Posté par  . Évalué à 5.

    Bonjour,

    ça a l'air sympa !
    L'idéal serait d'avoir un lien vers le code correspondant aux images pour se faire une meilleure idée sur sa complexité (ou pas…) et donner encore plus envie (ou pas…).

    • [^] # Re: le code correspondant aux images

      Posté par  . Évalué à 7.

      Le code pour le petit meuble Ici

      Le code pour la piece entiere ici

      Le code pour un objet tres simple, un tiroir

          g=plane(Z,origin).colored("Grey")
    boardThickness=.02
    drawer=Cube(.4,.4,.1).colored("Brown")
    # We define two points which are the opposite corners of the cube toCut
    firstPoint=drawer.point(boardThickness,boardThickness,boardThickness,"aaa")
    secondPoint=drawer.point(boardThickness,boardThickness,1.1,"nnp")
    toCut=Cube(firstPoint,secondPoint).colored("Yellow")
    drawer.amputed_by(toCut,keepTexture=False)
    button=Sphere(drawer.point(.5,0,.5,"pap"),.01).colored("Yellow").glued_on(drawer)

      qui fait ca: Titre de l'image

Suivre le flux des commentaires

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