SVGMORPHING
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
-
17 mai 2008 à 15:23
opossum_farceur Messages postés 147 Date d'inscription lundi 16 août 2004 Statut Membre Dernière intervention 14 novembre 2009 - 31 janv. 2011 à 15:18
opossum_farceur Messages postés 147 Date d'inscription lundi 16 août 2004 Statut Membre Dernière intervention 14 novembre 2009 - 31 janv. 2011 à 15:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/46682-svgmorphing
https://codes-sources.commentcamarche.net/source/46682-svgmorphing
31 janv. 2011 à 15:18
Un commentaire?! Ah, quel plaisir!
>>Firefox 4 implémentera les animations et IE(v9) va se plier >>à cette norme comme tous les autres navigateurs...
Il serait temps! Avec la vogue actuelle des applications géographiques en ligne, MS a dû finir par se rendre compte qu'il perdait des parts du gâteau...
Par ailleurs, je viens de lire :
"Du côté de l'Acid Test 3, Internet Explorer 9 n'atteint pas encore les 100 %, mais grimpe tout de même à 93 % lorsqu'Internet Explorer 8 obtenait un score ridicule de 20 %."
ce qui devrait se traduire par moins de prises de têtes pour les développeurs Web, dommage cependant que IE9 ne soit pas compatible avec WinXP.
Une petite question comme çà : "SVGMorphing" fonctionne-t-il sous IE9?
31 janv. 2011 à 10:47
Firefox 4 implémentera les animations et IE(v9) va se plier à cette norme comme tous les autres navigateurs...
Sinon félicitation pour ce script!
5 sept. 2008 à 19:25
5 sept. 2008 à 05:29
5 sept. 2008 à 00:44
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++
4 sept. 2008 à 18:47
4 sept. 2008 à 18:38
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++
3 sept. 2008 à 01:18
Je suis tombé sur ton script un peu par hasard, je developpe pas mal d'interface en svg dans le cadre professionnel ...en raison de ça je dois coder pour ie ( oui je sais c'est dramatique mais faire passer ses client sur un autre navigateur l'est aussi ^^ )
C'est un choix technologique que j'ai fait il y 3 et demi , me refusant au flash , pour le moment j'ai pas à me plaindre. Je suis content de voir que je suis loin d'être le seul fou à travailler avec ça. J'espère vraiment que le svg fera parti des standards d'ici quelques années.
En tout cas joli petite applie démonstrative.
2 juin 2008 à 19:24
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!
++
1 juin 2008 à 21:45
http://prototype-graphic.xilinus.com
Sinon bien sympa ta source ! bye
27 mai 2008 à 01:38
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.
26 mai 2008 à 22:20
Ok j'ai pas trop regarder tes sources ... j'ai juste fais mumuse pour réfléchir à comment je coderais ca
> bravo pour la gestion des parties cachées
La l'algo est tout simple : Je calcule le centre de chaque face, je tri les faces par ordre decroissant de profondeur et je les affiche. Cet algo ne marche pas toujours. Donc en fait y'a pas vraiment d'algo, ca demande trop de ressource de faire un vrai truc. C'est du javascript je rappelle.
> dommage cependant que l'on soit obligé d'écrire "Math."
Je sais bien mais ce n'etait pas du tout le but de la source de faire du parsing.
Cependant j'ai prevu de le rajouter dans la prochaine version avec l'optimisation.
"et non pas par "y=f(x,z)"" Sur ma TI il me semblait que c'etait y = f(x,z)
De toute facon x largeur de l'écran et Z la profondeur
Et puis ça dépend du repère, si c'est un repère main gauche ou main droite
Bref c'est juste des choix perso !
> ca serait bien de pouvoir contrôler la "caméra" (sa distance et sa hauteur par rapport à la scène).
Ma version de dev peut faire plus de chose, mais le blabla en dessous du graphique n'est pas complet.
Essaye les touches '+' et '-' ainsi que PageUp et PageDown ;)
26 mai 2008 à 19:30
"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).
26 mai 2008 à 01:44
Résultat : c'est lent pour dessiner des surfaces.
http://public.ahmygoddess.info/~mickael/Tools/3D/graph.htm
Sous Firefox c'est relativement rapide (Dans l'absolue ça bouffe beaucoup trop de ressource quand même !)
Sous IE j'utilise un fichier JS qui simule le canevas et qui n'est PAS de moi...
donc c'est SUPER lent (attendre un peu avant de voir quelque chose apparaitre sur la page)
Donc dans l'ensemble à part pour utiliser à des fins personnel ou pour son boulot en interne (pourquoi pas ...) ça sert pas à grand chose. Pas de plugins requis par contre c'est appréciable.
Les sources sont en cours d'optimisation (calculs de matrice etc ...)
Quand le cœur m'en dira je les finirai !
26 mai 2008 à 00:23
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!
24 mai 2008 à 19:36
24 mai 2008 à 19:27
"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?
24 mai 2008 à 02:45
avec des canevas, il parait que tu peux faire un truc qui marche sous MSIE
bon, sinon, j'aime beaucoup ton code, j'ai ete assez impressione par ta demo, meme si j'ai pas regarde l'algo (il est tard...)
bref, la ou tu aurais pu faire plus generique : sur tes formats de fichiers, tu aurais pu faire une interface et des drivers.
19 mai 2008 à 20:32
"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 "
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 ), 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++
19 mai 2008 à 18:13
Quand au code, il me semble fort tourné vers cette seule utilité, donc si tu dois refaire du SVG, tu peux tout recommencer la fois prochaine...
une petite amélioration, je pense(de logique):
if ($content= ==false) throw new Exception(' '.__FUNCTION__.'() : erreur lecture "'.$file.'" ');
=>
if ($content===false) throw new Exception(''.__METHOD__.'() : erreur de lecture du fichier "'.$file.'"');
__METHOD__ plutôt que __FUNCTION__, vu qu'on est dans une classe ;)
Quand au choix des animations, c'est bien dommage que ff ne gère pas , et le JavaScript n'est pas vraiment une solution "propre" (ce n'est plus vraiment du xml).
En conclusion, je pense que c'est un ptit truc sympa, qui montre un peu ce qu'est le SVG, mais à un niveau basique(juste des lignes...) Allez je te met 8/10 :)
Et ça me donne envie de poster ma classe SVG tient....
18 mai 2008 à 17:11
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++
17 mai 2008 à 20:55
Merci pour la note et le premier commentaire!
"Je pense que c'est un format d'avenir"
Cà fait 8 ans déjà que c'est un format d'avenir, de plus MicroSoft renacle à l'intégrer dans son IE, c'est prévu pour la version 9.0, d'ici là, les poules auront des dents (et les dents des caries). Pourtant, sur le papier, SVG ne comporte que des avantages, mais peut-être ne passent-ils qu'au deuxième plan, derrière les intérêts économiques?
"même si je ne suis pas d'accord avec tous tes choix"
Mes choix souvent sont dictés par de impératifs de performance qui sont la plupart du temps difficiles à concilier avec la poo telle que tu la conçois. Par exemple, je me suis rendu compte il y a peu que préciser le type d'un objet quand tu le passes en paramètre à une fonction était gros consommateur de ressources, ce qui tout compte fait est peut-être assez logique, vu qu'à l'origine php n'est pas typé.
Mais bon, je suis là pour apprendre, et s'il y a des choses qui te chiffonnent, te retiens pas!
a++
17 mai 2008 à 15:23
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.