distribution de n-points sur une sphère
dans les moteurs 3D, un truc nul c’est de pas avoir de geoshpere.
à gauche la sphère classsique, à droite la géosphère:
c’est composé uniquement de triangles réguliers et les triangles c’est bien.
or dans flash en 3d (je sais pas trop en fait mais je crois qu’) on a seulement des sphères toutes connes et c’est nul.
on peut créer une sphère à partir d’un nombre de segments en hauteur et d’un nombre de ‘tranches’.
Mais souvent au boulot la question c’est de pouvoir disposer X points en sphère pour pouvoir y accrocher ce qu’on veut (des images en général).
hier matin au petit déjeuner je suis tombé là dessus: nodename
où le gars fait précisément le truc en question.
et hier matin en arrivant au boulot, mon DA adoré et mon CP préféré me sont tombés dessus paniqués en me demandant si je connaissais quelqu’un qui saurait faire une sphère en 3D… >_>… à moi …
j’ai appelé le canard parce qu’il touche son slip en 3D mais comme il était pas dispo je leur dis: j’ai vu un truc ce matin qui devrait faire la blague, mais vu que le gars ne file pas les sources, va falloir porter l’algo depuis le C++. j’essaie ça cet après midi et si c’est concluant je me tape le boulot.
ce qui fut dit fut fait et en fin de journée j’arborais fièrement mon portage (oui j’ai aucun mérite, je sais).
la technique est basée sur un système de spring qui repousse et attire chaque vertex les un vers les autres. c’est une histoire de normalisation des distances. on s’en fout mais ça marche.
et hop ! la démo qui troue le slip (hum):
la source:
le zip de cette démo de ouf
du coup le zip contient une version simplifiée et super pas commentée de mon incroyable moteur de particules 3D ( tu risques d’être déçu(e)).
bon y a pas grand chose à dire, les liens fournis par nodename en disent suffisamment long. si j’ai modifié l’algo pour qu’on lui passe la liste de vertex et un seuil max de récursions. il retourne la liste de vertex ordonnés. gentiment.
plus il y a de récursions, plus c’est long mais plus le résultat est nice. sur la démo il y en a 10 à chaque ajout de point. c’est un bon compromis perf/rendu
un autre truc, l’algo réduit les distances de chaque vertex à une fraction de 1 donc après avoir appliqué le calcul, il faut resizer les vertices. rien de bien méchants mais c’est à noter.
j’espère que ça te servira.
bisou
Ça pète Nico! Ton code semble propre et optimisé. Puis j’ai cliqué 160 fois pour avoir 160 vertices, la machine a labouré un peu dans son coin un petit moment mais c’est nickel au final ! Vraiment bravo !
Ca cartonne!!!
Je sais pas pourquoi, mais mon petit doigts me dit que je vais pas tarder à m’en servir.
merci
pffff ! c’est énorme !
c’est "OMGdesque"
Hey tu t’es inspiré de Roxik on dirait !
Aec les clips préfloutés et les coordonnées forcées en integer. D’ailleurs ça donne un très mauvais rendu à basse vitesse, on voit clairement les clips sauter d’un pixel à l’autre. Même si j’imagine qu’on gagne clairement en performance vu qu’il n’y a pas d’interpolation à faire. Je me demande si ça vaut pas le coup d’activer ça à haute vitesse (là où le besoin de fluidité est important), et de réactiver les décimaux lorsque le mouvement de la sphère est plus lent (la baisse de fps se sent moins vu que les déplacements sont subtils).
salut tim,
avec ou sans décimaux, le rendu se fait sur un bitmapData donc, sauf à faire un antialias, on aura des sauts de pixels. le problème ne se pose pas quand on fait des rendus vecto vu qu’un trait vectoriel peut passer au milieu d’un pixel.
Le gain de vitesse est appréciable qu’on soit sur des tempi rapides ou lents ; si une anim broute, elle broutera qu’elle aille vite ou lentement je pense que lke rendu sera encore pire sur un tempo lent
Thanks pour les détails.
Concernant la fluidité, je réitère : A haute vitesse, un fort taux de FPS est nécessaire pour bien représenter le mouvement. En revanche, pour un bitmap qui ne va se déplacer que de 15 pixels en une seconde, pas besoin d’avoir 60 FPS, puisque la même image sera recalculée plusieurs fois.
C’est d’ailleurs pour cette raison que les "hardcore gamers" baissent les détails graphiques dans les jeux basés sur les réflexes, comme Unreal ou Quake, alors que pour les jeux solo, beaucoup plus lents, jouer à 25/30 fps suffit amplement.
En tout cas, j’arpente ton blog depuis un moment, je flash énormément mais n’ayant qu’un profil de graphiste, je ne fais quasiment pas d’expérimental comme toi. Je me cantonne à des tests d’interface 3D, d’interactions à la souris, d’effets graphiques, bref, tout ce qui est "user oriented". Et ton blog est une sacrée mine d’or en terme de recherche, surtout que tu donnes les sources, donc je tenais à te remercier.
rho c’est super D:
Je pourrai faire des jolis ballons avec: blog.gludion.com/2008/08/…
nickel l’insecte !
je viens de l’adapter pour paper, ca marche d’enfer. Merci à toi.
merci et je suis bien content que ça serve ^^
cool! Very nice!
Excellent de chez excellent !
Et c’est pareil pour le blog.
Il porte bien son nom.
Good Work !