SVGMORPHING

Commentaire de malalam le 17/05/2008 15:23:37 administrateur CS

Hello,

pas de commentaire...?
Bon, Oppossum, j'aime bien ta croisade pour le svg en ce moment :-) Je pense que c'est un format d'avenir (même s'il accuse maintenant un certain âge...il n'en reste pas moins que ce n'est pas lui qui est vieux et dépassé, c'est la communauté web qui est très en retard...).
Je n'ai pas testé ton code, mais je l'ai parcouru. C'est bien codé, même si je ne suis pas d'accord avec tous tes choix. Ca reste quand même de haut niveau.
Bref, je vais noter l'idée, et le code...pas le rendu puisque je ne l'ai pas testé. Mais j'encourage ceux qui aurait besoin de se mettre au svg, ou ceux avides d'innovation, à se pencehr sérieusement sur ce code, et sur le précédent (je ne sais plus si je t'avais laissé un commentaire, mais dans le doute, celui-ci s'applique aussi, ainsi que la note). 10 pour moi.

Commentaire de opossum_farceur le 18/05/2008 17:11:57

Salut,
Mon précédent code (http://www.phpcs.com/code.aspx?ID=46344), sur lequel celui-ci repose, n'utilisait pas SVG, car il pouvait se traiter de manière plus classique avec la librairie GD de PHP, et être ainsi indépendant du navigateur. L'utilisation de SVG était cependant tout à fait envisageable (avec les restrictions "habituelles" sur IE!), et aurait pu donner un code beaucoup plus représentatif de la cohérence du système que SVGMORPHING; en effet, SVG c'est pas autre chose que du XML; le serveur envoie alors les données au client sous cette forme, le client les réceptionne avec "responseXML" et les intègre telles quelles dans son DOM : c'est d'une efficacité redoutable!
Cette technique n'est pas utilisée avec SVGMORPHING à cause de l'absence dans l'implémentation de FF de l'élément "animate" (et çà n'est pas prévu apparemment dans sa prochaine version), ce qui fait que le client est obligé de "retravailler" les données, un modeste "responseText" pour leur réception s'avérant dans ce cas-là plus adapté.

Pour les curieux de SVG, un code qui peut donner des idées :
http://www.javascriptfr.com/codes/SVG3DCAMEMBERT_46033.aspx
a++

Commentaire de opossum_farceur le 19/05/2008 20:32:07

Salut,

"Contrairement à Malalam, j'ai d'abord regardé le résultat"
Pour tout dire, j'ai trouvé l'approche de Malalam assez curieuse, un peu comme s'il mettait la charrue avant les boeufs, mais bon, j'allai pas me révolter contre son appréciation!

"Quand au code, il me semble fort tourné vers cette seule utilité"
Il n'a en effet aucune autre prétention; j'aurais bien voulu pondre un code générique, qui puisse aussi transformer un carrosse en citrouille, mais çà n'est, hélas, pas dans mes compétences!

"c'est bien dommage que ff ne gère pas <animate>"
Cet élément n'apparait pas non plus dans sa version 3.0 (sniff!), qui ne devrait plus trop tarder.

"JavaScript n'est pas vraiment une solution propre"
Absolument, d'ailleurs, pour l'avoir testé aussi avec SVGViewer (qui gère donc correctement <animate>), j'ai trouvé sa transition entre les 2 formes beaucoup plus "fluide".

"c'est un ptit truc sympa, qui montre un peu ce qu'est le SVG, mais à un niveau basique"
Je n'ai utilisé que ce qui était nécessaire. Si tu sais adapter ce script pour qu'il fonctionne avec IE, tu m'intéresses! (j'ai essayé des tas de trucs, y'a rien qui marche, en plus je viens d'apprendre que ASV n'est pas bien supporté par Vista, c'est dément...)

a++

Commentaire de opossum_farceur le 24/05/2008 19:27:41

Salut,

"faire plus generique"
Je comprends bien que certains voudraient voir s'afficher autre chose que les départements français (peut-être les départements belges, pour Eregon, ou alors des pays, voir même autre chose que des cartes?).
Un 1er problème consiste à trouver les données dans un système de coordonnées et de projection pas trop exotiques, de manière à ce que l'on puisse reconnaître facilement les formes, et si possible avec l'extension ".txt", afin de ne pas avoir à passer par des utilitaires de conversion pas forcément faciles à utiliser et à obtenir. De toute manière, même si les données se présentent sous la forme ".txt", il sera nécessaire de mettre au point un script préalable afin de les rendre réellement exploitables (suppression des îles, enclaves et autres bizarreries, faire en sorte que le tracé des formes se fasse toujours dans le même sens : horaire ou anti-horaire, etc...).
Le 2ème problème, c'est la "réduction" des formes à un certain nombre de points identique pour chaque forme, c'est là qu'intervient l'algorithme de Douglas-Peucker; pour ce faire, je n'ai pas utilisé le script que j'ai publié, mais un autre, et même plusieurs autres, plus adaptés à cette tâche. Cette transformation ne s'est pas faite sans mal, j'ai dû ruser avec certains départements qui faisaient de la résistance, et le nombre de points (66) de chaque forme ne s'est pas imposé de lui-même : c'est le nombre de points du département le plus petit en superficie (et possédant de ce fait le nombre de points le moins important) : Paris.
Enfin, si vous arrivez à franchir tous ces obstacles, l'adaptation de SVGMorphing à ces nouvelles données ne sera, par comparaison, qu'un jeu d'enfant...

"avec des canevas"
Encore un "plug-in" de derrière les fagots?

Commentaire de opossum_farceur le 26/05/2008 00:23:48

Salut,

Merci coucou747 pour l'info, je ne connaissais pas. J'ai depuis expérimenté un peu l'affaire et suis en mesure de préciser certaines choses :
- <canvas> ne requiert pas un environnement xml ou xhtml pour fonctionner : html suffit.
- <canvas> n'est pas implémenté dans MSIE, cependant, le script d'adresse :
http://excanvas.sourceforge.net/
est censé combler cette lacune.
- <canvas> n'est pas aussi puissant que SVG (dont il s'inspire visiblement) mais permet quand même tout un tas de tracés bien sympathiques.
- <canvas> est intégré dans le DOM, ce qui fait que l'on peut accéder à/modifier ses attributs avec les fonctions getAttribute/setAttribute (le gag c'est qu'il ne semble avoir que 2 attributs propres : "width" et "height")

Muni de ce petit bagage, j'ai réussi à adapter sans trop de chamboulements SVGMorphing à ce <canvas>.
Résultat des courses :
- avec FF : résultat quasiment identique à celui obtenu avec SVG
- avec MSIE + excanvas : l'image tremblote, le timer est visiblement débordé pour finalement ne jamais s'arrêter (seul moyen : fermer le navigateur); en bref : une catastrophe!

Commentaire de opossum_farceur le 26/05/2008 19:30:07

@Zeroc00l,

"Sous IE j'utilise un fichier JS qui simule le canevas"
C'est à peu de chose près, le même dont j'ai indiqué l'adresse.

A part çà, ton script est intéressant, bravo pour la gestion des parties cachées; dommage cependant que l'on soit obligé d'écrire "Math." devant chaque fonction mathématique; d'autre part, les fonctions de 2 variables s'expriment par "z=f(x,y)" et non pas par "y=f(x,z)", et puis çà serait bien de pouvoir contrôler la "caméra" (sa distance et sa hauteur par rapport à la scène).

Commentaire de opossum_farceur le 27/05/2008 01:38:07

@Zeroc00l,

Pour la gestion des parties cachées des fonctions de 2 variables il existe un algorithme rapide connu sous le nom de "méthode des lignes de crête", qui donnait déjà de très bons résultats du temps où les processeurs se trainaient encore à une fréquence de quelques dizaines de Mhz.

Commentaire de opossum_farceur le 02/06/2008 19:24:23

Salut,
J'ai été voir à l'adresse indiquée, il y a encore du pain sur la planche, pour que ce "framework" devienne vraiment utile et fonctionnel; les exemples, plutôt maigres, sont ignorés par FF, décidemment, la compatibilité avec les navigateurs semble être un problème central pour qui s'intéresse au dessin vectoriel!
++

Commentaire de opossum_farceur le 04/09/2008 18:38:25

Salut,
Il n'y a pas de honte à coder pour IE+ASV, car IE est utilisé par 75% des internautes, l'approche discutable, par contre, c'est la mienne, à savoir coder pour FF exclusivement. L'idéal évidemment c'est de pondre des applications "cross-browser", mais, pour avoir perdu pas mal de temps à mélanger allègrement html, xml, svg, javascript et php, je me suis fait à l'idée que, en dehors de cas triviaux, l'entreprise relevait de la gageure.
La bonne solution serait l'intégration de svg dans IE (certains avancent que çà pourrait se faire dans IE9); MicroSoft aurait pu le faire depuis déjà plusieurs versions de son navigateur, j'en conclus qu'il n'a pas vraiment la volonté de le faire et qu'il essaie d'imposer à la place des solutions concurrentes et propriétaires.
C'est pour çà que je doute que svg puisse faire partie un jour des standards.
a++

Commentaire de opossum_farceur le 05/09/2008 00:44:48

Salut,
Si SVG avait une position dominante dans le domaine du dessin vectoriel, oui on pourrait parler de standard, mais on est loin du compte! Le standard "de fait", çà serait plutôt FLASH.
a++