A ce sujet une lecture instructive! http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
(concerne autant la modélisation géographique que le rendu final en SVG après projection). On trouve tout un tas de techniques explosées sur la façon d'accélerer le rendu vectoriel des lignes et polygones. En gros aujourd'hui on ne trace plus les lignes avec les vieux algorithmes de Bresenham simples (on ne veut plus des effets de crénelage) mais on remplit des surfaces polygonales, en convertissant tout trait en polygone à remplir. Les algos d erendus actuels sont pris en charge par le matériel de toute carte graphique actuelle et sont une extension de Bresenham où on ne calcule plus seulement les positions mais aussi les de façon incrémentale la couverture de chaque pixel, d'après la géométrie du polygone (deux traits de réference et non plus un seul). Seuls les rendus logiciels utilisent encore le superéchantillonnage simple (de type FSAA 2x2, qui peut utiliser le Bresenham simple à un trait, mais ça coûte cher en mémoire sans donner un résultat formidable visuellement). Tous les moteurs SVG savent utiliser le rendu matériel. Le 7 juin 2013 18:26, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Ah oui ? Comment crois-tu qu'on trace des traits épais ? Ou même n'importe > quel trait d'ailleurs. > > Le logiciel calcule des "buffers" puis les remplit. Même si cela ne se > fait pas dans la requête SQL (qui elle calcule des buffers en taille > géolocalisée et non dans la taille du rendu final ; la différence c'est le > système de coordonnées : le SQL travaille dans le système géographique, > alors que le rendu des lignes travaille dans le système après projection). > > C'est nécessaire de faire comme ça pour obtenir des tracés lissés (cela > nécessite de calculuer non pas des positions de pixel mais des taux de > couverture des pixels carrés par la surface limitée par le buffer interne ; > d'nacienne méthodes utilisait un rendu suréchantillonné mais c'était trop > coûteux en mémoire, pas assez précis pour avoir plus de 4 niveaux de > transparence pour l'anticrénelage, et c'est plus efficace ce calculer des > taux de couverture pour en déduire un niveau de transparence à appliquer > pour le rendu de la couleur effective des pixels qui dès lors peut avoir un > lissage bien meilleur jusqu'à 256 niveaux ; visuellement le rendu est bien > meilleur sans nécessiter aucun suréchantillonnage, et en calculant > directement chaque pixel une seule fois). > > > > Le 7 juin 2013 18:15, Christian Quest <cqu...@openstreetmap.fr> a écrit : > > Le 7 juin 2013 17:06, Philippe Verdy <verd...@wanadoo.fr> a écrit : >> > Une texture pour le trait ? Les textures n'ont pas d'orientation, ou >> plutôt >> > cette orientation est figée. >> >> C'est comme ça que sont tracés les falaises. >> >> Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer >> >> > Tracer deux ou trois traits semi-transparents superposés de taille >> > croissante vers l'intérieur du polygone demande deux ou trois calculs de >> > buffers mais ça se fait déjà pour tracer les routes (même si elles ne >> sont >> > pas semi-transparentes, la couleur n'a pas d'influence sur les >> performances >> > ou la complexité du calcul. >> >> Et bien non... les routes ne sont pas tracées comme ça. >> On a un premier trait épais, puis un second un peu plus fin... et >> magie... ça fait une fine bordure. >> >> > Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour >> > l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?) >> > >> >> Les calculs de buffers sont long. J'en utilise un pour décaler les >> noms sur les limites administratives, et c'est pas neutre du tout. >> >> -- >> Christian Quest - OpenStreetMap France >> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
