Voici un petit patch que j'ai fait dans le train en rentrant de l'OpenAtelier de chez Reso-nance.
Rien de bouleversant dans le résultat : une image pixelisée...
Je ne passe pas par du GLSL mais par la création, dynamiquement, de 1600 abstractions...
Et c'est fluide chez moi...
Je vous le poste, parce qu'il contient pas mal de petit truc pratique qui m'aurait bien aidé à mes débuts...
Tissage dynamique, argument $1-$2, [pix_data], [div ] / [mod ], [repeat ], send dynamique, positionnement matricielle dans GEM...
Dernière modification par Olivier (2012-05-02 14:25:16)
Hors ligne
Si je puis me permettre...
Plus simple que les sharders, le GLSL, CUDA et j'en passes... Tu faisais une couche alpha avec des petits carrés noirs et avec des filets blancs (ou l'inverse) et un [pix_resize] et le tour était joué... Solution de feignasse, mais ça fait le job tout autant avec certainement moins de ressources au passage.
Bon après dans la continuité de la question posé il y a quelques jours, ça trouve sa place et puis c'est toujours une bonne chose d'avoir des exemples de patch dynamique.
Hors ligne
Clairement, ce n'était pas le résultat que je visais... mais le moyen...
Histoire de proposer quelque chose de simple qui brasse pas mal de petits trucs...
Obtenir 1600 abstractions, ordonnées et atteignables indépendamment les unes des autres, c'est quelque choses qui m'aurait fait gagner pas mal de temps il y a quelques années... (surtout que là, on peut mettre n'importe quel primitive à la place du carré... )
Sur Marseille, je venais de croiser Ricardo Palmieri, l'organisateur de la PdConf au Brésil... qui a, on peut le dire, bien transer sa mère quand il a découvert le coup du [repeat ] avec [pix_data ]...
Donc, si ça peut faire gagner du temps à certain... zou...
Un petit patch...
Dernière modification par Olivier (2012-04-29 20:16:14)
Hors ligne
Sympa ! Ça m'intéresse. Si ça t'embête pas, j'aimerais bien l'essayer chez oim...
Hors ligne
Merci
Hors ligne
Oh My God !
hummmm... bon c'est un peu compliqué pour moi la, faut que je bosse encore sur les concepts puredata mais je le garde dans ma boite à outils
merci olivier
Hors ligne
Je suis hyper d'accord avec toi olivier : ce type de patchage offre la possibilité de travailler très précisément avec chaque itération de l'absract, et c'est pas forcément plus lourd que d'autres méthodes.
Hors ligne
Re bonjour,
Puisque c'est voué à être didactique, puis-je abuser et demander s'il serait possible de mettre plus de commentaires dans les patchs pour que quelqu'un de débutant comme moi puisse s'y retrouver et savoir quoi fait quoi ?
Je sais que c'est du boulot, mais cela pourrait être utile à d'autres, de la même manière qu'il est toujours très agréable et productif de retrouver un code source en C bien commenté.
Merci pour tout en tout cas.
Hors ligne
Tout à fait...
J'avoue que compte tenu du faible nombre de boite, je n'ai pas penser à le faire...
Mais ça mérite sûrement quelques explications...
Je vais essayer de prendre le temps de le faire...
Hors ligne
Voilà, voilà...
J'ai rajouté quelques commentaires dans l'archive...
Par contre, je n'ai pas détaillé l'extraction des x et y avec [div ] et [mod ] qui relève directement de notions mathématiques.
Je peux l'expliquer ici, au besoin, mais dans le patch ça me semblait un peu lourd.
Hors ligne
Top ! merci Olivier. C'est un poil plus clair
Bon d'accord il faut aussi que je me fasse une bonne session de découverte des objets PD, jai encore du mal à comprendre la logique. J'ai encore du mal à voir comment fonctionne la structure.
Par exemple, dans ton patch, comment fonctionne [repeat] ? Quelle est la partie "répétée" ? en langage de programmation structurée comme le C par exemple, dans une boucle "for" on a les instructions de la boucle entre {}. J'essaie de faire l'analogie avec PD mais peut-etre n'est-ce pas la même logique. je comprend que la boucle commence à [rereat] mais je ne vois pas quelle partie du patch est répétée.
Et aussi, le [s ] en fin de patch est à priori un "send" ? ( tu vois le niveau ! ) mais c'est récupéré ou ?
bon je continue mon exploration. Merci encore.
Hors ligne
Le [repeat ] répète ce qu'il reçoit autant de fois que demandé.
Ce qu'il reçoit, ici, c'est une nouvelle chaîne GEM à chaque frame...
L'algo fait en sorte que pour chaque nouvelle frame, il en parcours tous les pixels et en transmette la couleur dans les [abstr ] correspondant.
L'argument du [s ] est, pour cela, actualisé à chaque tour de compteur, donc 1600 fois par frame.
L'information relative à la couleur est récupérée dans les [abstr ] par la boite [r $1-$2] qui est initialisé au démarrage par les arguments de [abstr ].
Ne te décourage pas...
Si j'ai posté ce patch, c'est justement parce qu'il contient pal mal de choses différentes.
Quand tu l'auras compris tu auras parcouru un chemin émancipant...
Hors ligne