g=plane(Z,origin).colored("Grey")boardThickness=.02drawer=Cube(.4,.4,.1).colored("Brown")# We define two points which are the opposite corners of the cube toCutfirstPoint=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)
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.
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.
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.
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
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.
Il y a eu beaucoup d'abus sur les livres électroniques. Beaucoup de >candidats
ont demandé et obtenu un ISBN afin de pouvoir prendre leurs documents >pour les
oraux de l'agrégation. Dans ces conditions les règles ont été modifiées:
Cette remarque est finalement assez cocasse. Quelqu'un qui fait un travail personnel toute l'année ne peut pas emmener ses notes persos. Mais en revanche, si on se contente de "pomper" dans les livres vendus, c'est légitime.
Bien sur, on me répondra a juste titre que si on n'a pas suffisamment bossé le bouquin, on n'en tirera pas grand chose. N'empeche que la logique est difficilement comprehensible…
Ce que je ne comprends pas, c'est comment on interprete les calculs pour dimensionner. Par exemple, je sais calculer les moments de force a la main, je peux les mettre dans un logiciel. Et le logiciel peut me donner une deformation. Cette deformation sera plus grande si les tubes sont de plus petit diametre ou si j'ai mal triangule'. Mais dans tous les cas, je ne sais pas ou est la bonne limite. Le logiciel peut me donner 8, 15 ou 30 pour trois montages differents. Mais il ne me dit pas s'il vaut mieux prendre 8, 15, ou 30. En general, le plus lourd sera aussi le plus rigide. Autrement dit, je peux faire des calculs, mais je ne sais pas interpreter les calculs.
Quelle precision peut on esperer ? Quel avantage par rapport a regarder la valeur tabulee dans un bouquin pour un materiau donné, est ce plus precis ? Bref, quand est-ce que je peux esperer que ca m'est utile ?
Je ne comprends en fait pas bien. Si c'est un objet complexe non homogene, le module de Young n'a pas trop de sens. Et si c'est un objet de construction simple, comme une plaque de metal ou un morceau de bois, je vais probablement trouver dans la litterature une valeur assez precise debruitee de toutes les erreurs de mesures.
Je ne connaissais pas. Merci pour les liens. Il y avraiment des idees similaires entrre pycao et cadquery: le code doit etre le plus pres possible du langage parlé, chainage des operations, plugins, travail en coordonnees proportionnelles, documentation …
A premiere vue, il y a une difference neanmoins, c'est que la construction est pensée dynamique dans cadquery, avec la notion de "Working point", qui bouge au gré des constructions. Cette notion n'existe pas dans Pycao. Dans Pycao, pour decrire des coordonnees relatives, on utilise le formalisme des vecteurs (pycao fait la difference entre points et vecteurs) sans notion dynamique. Les objets sont pensés de facon statique, mais on fournit des outils pour ensuite pouvoir les placer facilement les uns par rapport aux autres( fonctions screw_on et against notamment).
Ca me fait penser a un tableur contre une base de donnees. C'est plus rapide avec un tableur pour un petit projet, mais c'est difficile a maintenir au dela d'une certaine taille avec l'insertion de colonnes qui rend le code fragile au dela d'une certaine taille. Ca me semble un peu pareil ici. Les workings points, ca va aller vite pour des petits dessins, mais ca peut etre compliqué a gerer quand on insere du code au milieu d'un gros bloc.
En tout cas, ca a l'air bien pensé et ca me donne envie d'aller voir si il y a des idees interessantes qui pourraient etre utiles dans Pycao.
Tu dis avoir calcule' le dimensionnement. Tu peux dire quelques mots la dessus ? A priori on peut toujours faire plus ou moins rigide. Comment tu mets des limites ? Quels types de calcul tu fais ?
Je regarde tes photos, et je trouve que la triangulation est assez bonne. Bizarre que ca ait casse'. Sans doute a cause des conditions de soudage comme tu le dis.
Tu dis que c'etait galere le guidage sous le siege. Pourquoi ?
Les avantages d'open-scad:
- fichiers d'export
- un visualiseur 3D digne de ce nom
Les avantages de Pycao: un langage de haut niveau avec plein de paradigmes permettant un code compact ( box, genealogie enre les objets, systemes de mesure en coordonnees proportionnelles ou absolues, langage de la geometrie affine pour des notations compactes, primitive d'interpolations pour les courbes, squelettes, classes pour construire des librairiees facilement…).
Mon experience avec les langages de bas niveau, c'est qu'il faut au moins milles lignes de code pour decrire un velo comme celui que je donne en exemple, avec plein de calcul intermediaires pour ajuster les decalages. Ca donne un code tres difficile a maintenir. Et quand on change un parametre, par exemple, si on ecartes les roues, il faut relire le code et reajuster tous les calculs. Rien que le bonhomme tout seul sans le velo me semble un boulot colossal sans un minimum de primitives de haut niveau.
Face a ces difficultés, j'ai commencé a écrire de plus en plus de macros pour pouvoir changer a la volee tous les parametres de construction. On peut voir pycao comme un ajout d'une couche de macros assez epaisse aux elements de langage commun a plus ou moins tous les langages de cao.
Pour la modelisation, je n'ai pas trop avancé la dessus. J'ai juste regardé s'il y avait des softs interessants. Il y a mbDyn qui a l'air vraiment bien. Difficile a utiliser si on ne connait pas un peu de physique. Mais vraiment tres simple et minimaliste en mode commande, avec des modeles assez elaborés cependant. Un genre de shell pour l'analyse mecanique. Donc a priori, c'est faisable de faire un module d'interfacage.
Yes, l'axe de direction avant est a la base de la roue avant. Et il y a un autre axe de direction pour la roue arriere.
A l'avant, ce n'est pas un garde boue, mais un tube metal autour de la roue. Il faudra des gardes boues, mais pour l'instant le modele ne decrit que la partie mecanique a souder. Il reste a mettre tous les peripheriques ( freins, vitesses, garde-boue …) En revanche, la geometrie ne devrait pas trop changer. Elle est plus ou moins definitive ( pour ce proto la, il y aura sans doute d'autres protos si ca ne donne pas satisfaction).
Ah super ton projet. Bravo pour l'inventivité. C'est vrai qu'il y a pas mal de choses a experimenter encore.
Oui tu as bien vu, il y a une direction arriere. En fait, c'est un double direction avant arriere, Y'avait un proto qui existait et qui, comme le tien, a cassé rapidement. J'essaie maintenant de faire un truc un peu plus pro, qui corrige les defauts precedents. Une tite video qui montre que c'est bien conduisible et stable : https://www.youtube.com/watch?v=kP08CeD9aV8 Sentiment de glisse assez incroyable.
L'idee, c'etait de partir des velos ayant le meileur rendement actuellement ( velo a traction directe, dont le python) et d'essayer d'ameliorer encore un peu (maniabilité, stabilité, rendement).
Pour des conseils de construction pour ton futur cadre ;-), tu peux venir discuter sur http://veloartisanal.fr
D'apres mes quelques essais sur le sujet, la reproduction de qualite', c'est surtout la banque de sons. Donc realiste et leger, ca me parait difficile. Une bonne banque de sons, c'est lourd !
Pour etre concret, au piano il y a pianoteq qui fait de la synthese sans banque de sons. C'est leger (pas libre) et pas mal d'utilisateurs sont contents. Mais si on compare a une vraie banque de sons (qu'on peut en outre trouver en libre ), la banque de sons reelle est (a mon oreille) tres nettement meilleure que la synthese.
Il faut aussi s'entendre sur le mot lourd. Les banques de sons sont lourdes en memoire ( jusqu'a plusieurs giga pour les plus grosses) mais legeres pour le processeur. LinuxSampler est un synthetiseur excellent qui tourne sur des machines peu puissantes.
Enfin, il faut faire attention au marketing. Les meilleures installations logicielles avec un tres bon casque ne sont pas vraiment "realistes". Ca ressemble a ce qu'on entend quand on ecoute un cd sur du matos hifi haut de gamme. C'est bien, mais ca reste un enregistrement different du son initial.
[^] # Re: le code correspondant aux images
Posté par lelama . En réponse au journal Pycao version 0.9. Évalué à 1.
Arghh, je voulais editer pour ajouter un bonjour car je trouvais mon message un peu sec. Pas trouvé le bouton d'édition. Pas grave. Bonjour donc ;)
[^] # Re: le code correspondant aux images
Posté par lelama . En réponse au journal Pycao version 0.9. É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
qui fait ca:
[^] # Re: lien avec les autres projets
Posté par lelama . En réponse au journal Pycao version 0.9. É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.
[^] # Re: Povray bouge encore ?
Posté par lelama . En réponse au journal Pycao version 0.9. É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: lien avec les autres projets
Posté par lelama . En réponse au journal Pycao version 0.9. É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: Povray bouge encore ?
Posté par lelama . En réponse au journal Pycao version 0.9. É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:
[^] # Re: lien avec les autres projets
Posté par lelama . En réponse au journal Pycao version 0.9. É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: bravo
Posté par lelama . En réponse à la dépêche Le Frido, un livre de mathématique libre pour l’agrégation. Évalué à 6.
Cette remarque est finalement assez cocasse. Quelqu'un qui fait un travail personnel toute l'année ne peut pas emmener ses notes persos. Mais en revanche, si on se contente de "pomper" dans les livres vendus, c'est légitime.
Bien sur, on me répondra a juste titre que si on n'a pas suffisamment bossé le bouquin, on n'en tirera pas grand chose. N'empeche que la logique est difficilement comprehensible…
[^] # Re: Sai daigueulasse
Posté par lelama . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 3.
Cha va pas toi, Dijon ch'est plein sud !
# .rst
Posté par lelama . En réponse au journal Cupa : une page web éditable, simplement. Évalué à -1.
Avanages/inconvenients par rapports a rst ??
Cf https://fr.wikipedia.org/wiki/ReStructuredText
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Merci Denis pour tes reponses.
[^] # Re: Precision, toussa...
Posté par lelama . En réponse au journal Un peu de méca : mesurer un module de Young avec son smartphone. Évalué à 1. Dernière modification le 21 septembre 2016 à 18:09.
Ok, merci pour la reponse. Je comprends mieux.
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Ce que je ne comprends pas, c'est comment on interprete les calculs pour dimensionner. Par exemple, je sais calculer les moments de force a la main, je peux les mettre dans un logiciel. Et le logiciel peut me donner une deformation. Cette deformation sera plus grande si les tubes sont de plus petit diametre ou si j'ai mal triangule'. Mais dans tous les cas, je ne sais pas ou est la bonne limite. Le logiciel peut me donner 8, 15 ou 30 pour trois montages differents. Mais il ne me dit pas s'il vaut mieux prendre 8, 15, ou 30. En general, le plus lourd sera aussi le plus rigide. Autrement dit, je peux faire des calculs, mais je ne sais pas interpreter les calculs.
# Precision, toussa...
Posté par lelama . En réponse au journal Un peu de méca : mesurer un module de Young avec son smartphone. Évalué à 7.
Quelle precision peut on esperer ? Quel avantage par rapport a regarder la valeur tabulee dans un bouquin pour un materiau donné, est ce plus precis ? Bref, quand est-ce que je peux esperer que ca m'est utile ?
Je ne comprends en fait pas bien. Si c'est un objet complexe non homogene, le module de Young n'a pas trop de sens. Et si c'est un objet de construction simple, comme une plaque de metal ou un morceau de bois, je vais probablement trouver dans la litterature une valeur assez precise debruitee de toutes les erreurs de mesures.
Par exemple, toi, tu comptes l'utiliser comment ?
[^] # Re: En python aussi
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Je ne connaissais pas. Merci pour les liens. Il y avraiment des idees similaires entrre pycao et cadquery: le code doit etre le plus pres possible du langage parlé, chainage des operations, plugins, travail en coordonnees proportionnelles, documentation …
A premiere vue, il y a une difference neanmoins, c'est que la construction est pensée dynamique dans cadquery, avec la notion de "Working point", qui bouge au gré des constructions. Cette notion n'existe pas dans Pycao. Dans Pycao, pour decrire des coordonnees relatives, on utilise le formalisme des vecteurs (pycao fait la difference entre points et vecteurs) sans notion dynamique. Les objets sont pensés de facon statique, mais on fournit des outils pour ensuite pouvoir les placer facilement les uns par rapport aux autres( fonctions screw_on et against notamment).
Ca me fait penser a un tableur contre une base de donnees. C'est plus rapide avec un tableur pour un petit projet, mais c'est difficile a maintenir au dela d'une certaine taille avec l'insertion de colonnes qui rend le code fragile au dela d'une certaine taille. Ca me semble un peu pareil ici. Les workings points, ca va aller vite pour des petits dessins, mais ca peut etre compliqué a gerer quand on insere du code au milieu d'un gros bloc.
En tout cas, ca a l'air bien pensé et ca me donne envie d'aller voir si il y a des idees interessantes qui pourraient etre utiles dans Pycao.
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 1.
Tu dis avoir calcule' le dimensionnement. Tu peux dire quelques mots la dessus ? A priori on peut toujours faire plus ou moins rigide. Comment tu mets des limites ? Quels types de calcul tu fais ?
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 1.
Je regarde tes photos, et je trouve que la triangulation est assez bonne. Bizarre que ca ait casse'. Sans doute a cause des conditions de soudage comme tu le dis.
Tu dis que c'etait galere le guidage sous le siege. Pourquoi ?
[^] # Re: comparaisons
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Tu as raison. C'est juste que je ne connais pas suffisamment ces outils pour me permettre de les commenter.
[^] # Re: OpenSCAD
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 3. Dernière modification le 20 septembre 2016 à 20:34.
Pour etre un peu plus concret, voila la code complet pour decrire la personne sur le velo. C'est un squelette dont on bouge les articulations.
[^] # Re: OpenSCAD
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 4.
Les avantages d'open-scad:
- fichiers d'export
- un visualiseur 3D digne de ce nom
Les avantages de Pycao: un langage de haut niveau avec plein de paradigmes permettant un code compact ( box, genealogie enre les objets, systemes de mesure en coordonnees proportionnelles ou absolues, langage de la geometrie affine pour des notations compactes, primitive d'interpolations pour les courbes, squelettes, classes pour construire des librairiees facilement…).
Mon experience avec les langages de bas niveau, c'est qu'il faut au moins milles lignes de code pour decrire un velo comme celui que je donne en exemple, avec plein de calcul intermediaires pour ajuster les decalages. Ca donne un code tres difficile a maintenir. Et quand on change un parametre, par exemple, si on ecartes les roues, il faut relire le code et reajuster tous les calculs. Rien que le bonhomme tout seul sans le velo me semble un boulot colossal sans un minimum de primitives de haut niveau.
Face a ces difficultés, j'ai commencé a écrire de plus en plus de macros pour pouvoir changer a la volee tous les parametres de construction. On peut voir pycao comme un ajout d'une couche de macros assez epaisse aux elements de langage commun a plus ou moins tous les langages de cao.
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 1.
Pour la modelisation, je n'ai pas trop avancé la dessus. J'ai juste regardé s'il y avait des softs interessants. Il y a mbDyn qui a l'air vraiment bien. Difficile a utiliser si on ne connait pas un peu de physique. Mais vraiment tres simple et minimaliste en mode commande, avec des modeles assez elaborés cependant. Un genre de shell pour l'analyse mecanique. Donc a priori, c'est faisable de faire un module d'interfacage.
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Yes, l'axe de direction avant est a la base de la roue avant. Et il y a un autre axe de direction pour la roue arriere.
A l'avant, ce n'est pas un garde boue, mais un tube metal autour de la roue. Il faudra des gardes boues, mais pour l'instant le modele ne decrit que la partie mecanique a souder. Il reste a mettre tous les peripheriques ( freins, vitesses, garde-boue …) En revanche, la geometrie ne devrait pas trop changer. Elle est plus ou moins definitive ( pour ce proto la, il y aura sans doute d'autres protos si ca ne donne pas satisfaction).
[^] # Re: Un vélo python ?
Posté par lelama . En réponse au journal Pycao: modeleur 3D en python. Évalué à 2.
Ah super ton projet. Bravo pour l'inventivité. C'est vrai qu'il y a pas mal de choses a experimenter encore.
Oui tu as bien vu, il y a une direction arriere. En fait, c'est un double direction avant arriere, Y'avait un proto qui existait et qui, comme le tien, a cassé rapidement. J'essaie maintenant de faire un truc un peu plus pro, qui corrige les defauts precedents. Une tite video qui montre que c'est bien conduisible et stable : https://www.youtube.com/watch?v=kP08CeD9aV8 Sentiment de glisse assez incroyable.
L'idee, c'etait de partir des velos ayant le meileur rendement actuellement ( velo a traction directe, dont le python) et d'essayer d'ameliorer encore un peu (maniabilité, stabilité, rendement).
Pour des conseils de construction pour ton futur cadre ;-), tu peux venir discuter sur http://veloartisanal.fr
[^] # Re: Qualité=banque de sons
Posté par lelama . En réponse au journal [BOOKMARK] FluidLite, un synthétiseur logiciel SoundFont open source. Évalué à 4.
Pour le piano, tu as ca qui est bon.
http://freepats.zenvoid.org/Piano/
En revanche, le format sfz est utilisable seulement par linux sampler. Une version de linux sampler compilee se trouve sur kxstudio.
# Qualité=banque de sons
Posté par lelama . En réponse au journal [BOOKMARK] FluidLite, un synthétiseur logiciel SoundFont open source. Évalué à 3.
D'apres mes quelques essais sur le sujet, la reproduction de qualite', c'est surtout la banque de sons. Donc realiste et leger, ca me parait difficile. Une bonne banque de sons, c'est lourd !
Pour etre concret, au piano il y a pianoteq qui fait de la synthese sans banque de sons. C'est leger (pas libre) et pas mal d'utilisateurs sont contents. Mais si on compare a une vraie banque de sons (qu'on peut en outre trouver en libre ), la banque de sons reelle est (a mon oreille) tres nettement meilleure que la synthese.
Il faut aussi s'entendre sur le mot lourd. Les banques de sons sont lourdes en memoire ( jusqu'a plusieurs giga pour les plus grosses) mais legeres pour le processeur. LinuxSampler est un synthetiseur excellent qui tourne sur des machines peu puissantes.
Enfin, il faut faire attention au marketing. Les meilleures installations logicielles avec un tres bon casque ne sont pas vraiment "realistes". Ca ressemble a ce qu'on entend quand on ecoute un cd sur du matos hifi haut de gamme. C'est bien, mais ca reste un enregistrement different du son initial.