Bonjour à tous,
Je me remet doucement à pd-extended, et lorgne en ce moment autour de text2d (text3d faisant planter pd sous Ubunu 14.04 32bit). J'aimerais afficher un text2d avec un color en dessous, afin de détacher le texte du reste de l'image. Une sorte de mask.
Sauf que j'aimerais que le [color] corresponde en dimension à mon [text2d], quoi q'il arrive. Et j'avoue ne pas y arriver...
j'ai essayé pix_info, mais celui ci semble extraire les données exif d'une image plutot que analyser une image en direct...
Avez vous des pistes de reflexion ?
Merci (et bonne vacances pour ceux qui y sont)
Hors ligne
salut,
pour ma part je n'ai pas compris exactement ce que tu voulais faire niveau rendu.
tu veux faire du blend? de couleur ou de texture?
Tu aurais un exemple?
concernant ftgl, ça pourrait être une bonne chose en effet d'implémenter tout ça...
Jamais essayé de compiler en stand alone le text3d...
Nicolas, moi ça m'interesse de voir tes modifs!
Hors ligne
Bonjour,
Nicolas Lhommet a écrit:
Tu ne nous dit pas ce que tu as essayé, au juste, mais bon
et
nononononono a écrit:
pour ma part je n'ai pas compris exactement ce que tu voulais faire niveau rendu.
J'ai essayé ce que j'ai décris dans mon 1er message, mais ce n'est pas très explicite effectivement. J'ai donc essayé avec un [gemhead 50]-[color]-[alpha]-[cube] et un [gemhead 51]- [text2d]... Cela place dans le rendu le texte au dessus d'un carré de couleur un peu transparent...
Nicolas Lhommet a écrit:
Tepaze a écrit:
...(text3d faisant planter pd sous Ubunu 14.04 32bit)...
Ah bon ?? Par acquis de conscience, j'ai vérifié vite fait sur une version Live d'Ubuntu 14.04 32bit, et [text3d] (celui de Pd-extended 0.43.4) marche sans problème (enfin "chez moi, sur ma machine", je précise...).
Arrggghhh!!! Oui, bien évidement, je précise que c'est sur ma machine que cela ne fonctionne pas, et pas d'une façon générale.
nononononono a écrit:
tu veux faire du blend? de couleur ou de texture?
J'avoue une méconnaissance des termes relatifs (je crois) à la 3d. Ainsi, le blend, je ne sais pas le définir... Bon à te lire j'imagine que c'est le remplissage d'une surface par soit une couleur soit par une texture. A priori, pour le moment remplir avec de la couleur me suffirait.
NicolasLhommet a écrit:
Mais rien ne t'empêche de t'y pencher si tu es motivé[...], et si tu veux vraiment expérimenter cette possibilité, je pourrais déjà t'indiquer les petites modifs (triviales) que j'ai effectuées.
Oui je suis interessé, même si j'ai l'impression que c'est assez pointu. Avoir une approche de ce type m'interesse, limite plus par curiosité et afin d'aborder une nouvelle approche que pour aller jusqu'a la réalisation de l'objectif. Mais je n'ai pas beaucoup de temps à y consacrer actuellement. Cela changera dans les mois qui viennent si tout ce passe bien.
NicolasLhommet a écrit:
Sinon, sans intervention sur le code source, j'ai bien une idée... dans l'ambiance "ré-implémentons un (protocole) standard dans un patch Pd, pour le fun", mon dada habituel , je le ferai peut-être à l'occasion.
Que c'est mystérieux cette dernière phrase !!!
Sinon, j'ai trouvé une semi solution, je passe mon texte par [moocow/any2bytes]-[list length] et cela me donne le nombre de lettre + 2... Il ne reste plus qu'a connaitre la taille des fonts pour faire un cadre approximatif... Mais le problème n'est pas réellement résolu avec cette solution.
Dernière modification par Tepaze (2015-08-11 09:57:11)
Hors ligne
Nicolas Lhommet a écrit:
[...]recalculer les dimensions sans aide de Gem, juste à partir de la chaîne de caractères, de la taille choisie et des (nombreux) paramètres liés à la police de caractères utilisée. Du coup, c'est quand même un poil plus compliqué que ça .
Oui Mais c'est déjà plus à ma porté actuellement :-)
Pour autant je ne desespère pas de tenter la recompilation de GEM à l'occasion... Dans quelques temps quoi
Bon, je vais essayer avec ma solution pour le moment, en attendant d'avoir le temps de chercher une solution plus juste.
Merci à tous
Hors ligne
citation :
Sérieusement ?? Ça prend 15 minutes !!! Malheureusement, la plupart des gens préfèrent se contenter d'un "c'est trop compliqué pour moi"...
LOL
Pour ma part, quand la solution à l'un de mes problèmes nécessite que je doive passer par une recompilation de GEM, c'est généralement le signal que je suis en train de vouloir planter un clou avec un tourne-vis...
À ce moment là...
Soit j'essaye de trouver une vis... (utilisation d'une typo monospace + calcul)
Soit j'essaye de trouver un marteau... (processing + textWidth() )
Mais, c'est une démarche tout à fait personnelle...
Bon courage...
Hors ligne
citation :
Enfin il me semble que le but d'un forum de discussion, c'est d'en discuter,
Tout à fait...
C'est ce que je fais, je crois, en exposant ma "démarche tout à fait personnelle"...
Mais je peux aussi te laisser discuter tout seul, si tu veux...
citation :
si on veut un cadre sans aucune marge autour du texte, même en se limitant à une police à "chasse fixe" (....), tous les caractères ont des largeurs et des hauteurs différentes.
Ma foi, oui...
Mais je n'ai pas l'impression que Tepaze ne veuille absolument aucune marge...
Il souhaite afficher de la couleur "afin de détacher le texte du reste de l'image"...
Une police à chasse fixe lui offre + ou - cette possibilité...
Par ailleurs, non le code n'est pas sale...
Mais, je ne pense pas non plus qu'il y ai quelque chose de honteux à ne pas vouloir compiler un fork de GEM dès que l'occasion se présente...
Surtout que Tepaze a été assez clair sur la question...
Ça l'intéresse, mais pas pour le moment...
Aux plaisirs de lire ton petit tuto...
Hors ligne
citation :
sans prendre en compte les échanges précédents, dans lesquels on a justement pas privilégié une solution à une autre, mais plutôt pesé leurs avantages respectifs
C'est amusant, quand j'ai lu le fil, j'ai eu l'impression que tu semblais ne pas prendre en compte les réponses de Tepaze qui privilégiait sa solution à la tienne en pesant leurs avantages respectifs...
Entendons-nous bien...
Les réponses que tu apportes sont précises et détaillées, bref, elles sont précieuses.
Si elles ne servent pas à Tepaze, aucun doute qu'elles serviront à quelqu'un d'autre.
Comme tous tes autres posts d'ailleurs...
Ce qui ne change rien au fait que, personnellement, je ne recompile pas GEM, même si c'est simple, même si c'est rapide...
Rien à voir avec "c'est trop compliqué pour moi..."
L'idée pour moi est d'obtenir une solution la plus "universelle" comme tu dis...
Qui pourra être utilisée par n'importe qui sans avoir à compiler quoi que ce soit...
Par ailleurs, je ne dis pas que c'est LA solution, je dis que c'est MA solution...
Excuse-moi de vouloir donner mon point de vue sur un forum d'échange...
citation :
j'ai fait preuve d'une consternation un peu excessive smile je veux bien le reconnaître
C'est déjà bien d'en être conscient...
Hors ligne
Nicolas Lhommet a écrit:
Tepaze a écrit:
Pour autant je ne desespère pas de tenter la recompilation de GEM à l'occasion... Dans quelques temps quoi :cool
Sérieusement ?? Ça prend 15 minutes !!! Malheureusement, la plupart des gens préfèrent se contenter d'un "c'est trop compliqué pour moi"... en même temps ça fait bien les affaires des pseudo-spécialistes, qui peuvent continuer à se la "péter"
Bon, je posterai un petit tuto, histoire que tu n'aies aucunes excuses
Ok, avec plaisir.
J'ai déjà compilé des trucs, genre ffmpeg en static avec une pelletée de module, et effectivement ça c'est bien passé, et cela m'a été utile, mais je ne sais pas pourquoi, il y a un coté rebutant. Je crois que c'est le coté "Je reviens pas en arrière avec un ctl-z".
J'ai encore un problème avec Linux, je ne pige pas comment fonctionne, dans les faits, l'installation et surtout la désinstallation de programme. Ok je compile, mais une fois que cela est fait, comment je l'enlève par exemple. C'est pour cela que compiler un truc static, pas de soucis, mais sinon, j'ai des réticences (enfin pas sur ma machine de test qui subit les pire outrages )
Si l'un de vous à d'ailleurs une bonne lecture à me proposer à ce sujet (ou une explication claire) je suis preneur.
Olivier a écrit:
Pour ma part, quand la solution à l'un de mes problèmes nécessite que je doive passer par une recompilation de GEM, c'est généralement le signal que je suis en train de vouloir planter un clou avec un tourne-vis...
C'est effectivement un indicateur, mais pas necessairement un feu rouge. Je dois recompiler v4l2loopback pour avoir plus de 8 boucles disponible par exemple. Par contre tu mets en lumière mon manque de connaissance en la matière. Je n'ai jamais pratiqué processing, alors que cela me parait tout à fait intéressant. Je vais devoir m'y mettre. Mais juste au passage, processing peut interagir avec PureData (directement j'entends, ou faut il passer par v4l2loopback ?)
NicolasLhommet a écrit:
ma démarche consistait à surtout à l'encourager, même maladroitement.
Je l'ai d'ailleurs bien pris comme cela, et je ne pense pas que Olivier ai chercher à remettre en cause ta proposition NicolasLhommet, mais de rappeler, comme tu l'as fais toi aussi dans ton 1er message, que le contournement d'un problème est aussi une solution valable.
D'autant que je bosse pas mal sous une machine Linux, mais le boulot fini (presque) toujours sur un Mac actuellement. Les personnes qui exploitent les logiciels ont déjà du mal avec les programmes tout fait, alors la console, ce truc tout noir avec aucun dessin...
Et donc, l'approximation d'un calcul avec une font spécifique me permet de réalisé ce dont j'ai actuellement besoin, et je ne manquerais pas à l'occasion de recompiler GEM afin de ne pas en avoir peur
Hors ligne
citation :
Mais juste au passage, processing peut interagir avec PureData (directement j'entends, ou faut il passer par v4l2loopback ?)
Quand j'ai évoqué Processing, je parlais en fait de laisser carrément de côté GEM, voire Puredata...
Sinon, oui il est possible de faire communiquer Puredata avec Processing en utilisant de l'OSC par exemple...
Concernant la vidéo, pour l'instant, je ne sais que récupérer le flux de GEM pour l'afficher dans Processing, en passant, effectivement, par v4l2loopback + [pix_record]...
Par contre, je ne sais pas le faire dans l'autre sens...
Sinon, c'est amusant que tu parles de la compilation de v4l2loopback pour avoir plus de 8 buffers parce qu'on a été confronté au pb récemment et, en dépit de la simplicité de l'opération (make + flag) c'est mon collègue Benj qui s'y ai collé...
Bonne continuation...
Hors ligne