Reprise du message précédent :
ouais, j'ai vu le code des triangles en googlant, mais je suis pas convaincu qu'une polyline de 1834573 points (ce qu'on voit sur mon exemple) se triangule rapidement en Javascript. (et du coup j'ai un peu la flemme d'y re-passer une deuxième nuit).

je regarde le truc de nvidia, comment est-ce que je peux influencer la taille du rectangle qu'il va rasteriser ?
J'ai pas de geometry shader, et si je déplace le vertex, le vertex sera déplacé pour le segment entrant et le segment sortant.

Arf ok en effet.
Alors tu peux regarder les Accumulation buffers (glAccum()), l'idée serait d'accumuler plusieurs rendus mais en changeant très légèrement à chaque fois ta projection avec ce genre de code :

Mais pareil, faut que tu aies le droit aux accumulations buffers

edit : regarde https://www.sgi.com/products/softwa [...] /accumaa.c

C'est déprécié depuis OpenGL 3, et même pas dispo dans OpenGL ES. Faut utiliser render-to-texture et jouer avec les blendmodes.

si tu veux de brownie points, je l'ai mise sur SO http://stackoverflow.com/questions [...] n-three-js

 
Ça reviendra au même, mais c'est plus chiant à mettre en place du coup Des fois c'est bien pratique de piocher dans les vieilleries deprecated d'opengl (bon visiblement en opengl ES c'est mort)

en fait la réponse peut être assez simple (encore que j'ai googlé toute la nuit), parce que je capte pas grand'chose à openGL. J'ai écrit mon premier shader dans la nuit, (et il est parti à la poubelle vers 5h ce matin )

http://quartermaester.info/

C'est pour de l'OpenGL ES mais j'ai trouvé ce site bien foutu, ils expliquent bien les shaders notamment:
http://www.learnopengles.com/andro [...] g-started/

Sinon pour ton "problème" de ligne aliasée, t'auras pas beaucoup mieux. On voit qu'il y a déjà de l'AA (de merde) d'appliqué. Lignes fines + fort contraste, ça va forcément aliaser à un moment donné ! Ca me choque pas plus que ça.

Essaye d'agrandir l'épaisseur des lignes tout de même (glLineWidth)

là elles sont à 1.5
 
à 3 ça donne ça :

plus la largeur est grande et plus la connection entre les segments est moche.

Ha ouais le rendu est vraiment dégueu ... Le bord des lettres est du coup plutot propre par contre.

'tain avec moi y'a toujours un drame, simplement prendre une polyligne issue simulation la foutre dans une vue 3D, ça marche pas.
 
Je sais pas comment je fais mais y'a rien qui marche bien, toujours un problème, un détail, un accident.

J'ai essayé d'avoir le même style de rendu sur Inkscape pour voir comment il s'en sort, et ça me semble pas forcément beaucoup mieux que ce que tu as:

Je me prendrais pas trop la tête sur ce point perso A moins de zoomer ou d'avoir un écran "retina" pour avoir plus de pixels pour séparer les lignes ça sera jamais top

En haut c'est la vue 3D et en bas c'est la vue SVG
(les 2 ont des lignes à 1.5px)

En effet la précision du rendu est clairement pas la même mais je sais pas si tu peux y faire grand chose ... Comme dit plus haut ça dépend surtout de l'implémentation niveau CG !

Au SIGGRAPH 2012 Nvidia avait présenté une extension pour tracer des paths SVG en OpenGL
    https://developer.nvidia.com/sites/ [...] _annex.pdf
 
Ça parle très rapidement d'antialiasing dans le pdf

http://www.arcsynthesis.org/gltut/  celui-ci est très bien  

Je me demande si je vais pas faire passer les points dans une matrice et tout foutre en SVG, même la 3D. mais ça veut dire qu'il faut que j'aille comprendre ce qu'est un quarternion ça veut dire 3 semaines de googling.
 
ou alors je fous une vue3D avec son contrôle de souris, tout ça, sauf que je la laisse vide avec une vue SVG en-dessous. Je pique la matrice de la caméra en temps réel, et je la copie à la racine du SVG. Si c'est une caméra orthographique, c'est compatible (la 4ème rangée de la matrice sera à 0), par contre en perspective il faut descendre dans l'arène de la géométrie projective, c'est 3 semaines de google aussi.
 
gérer la technologie et la déficience mentale en même temps c'est chaud

en fait y'a un renderer SVG dans les exemples.

 
Les quaternions si tu as déjà l'habitude des matrices c'est trivial (et sinon, ce n'est pas plus dur à comprendre que l'algèbre des matrices)
 
 
Quand tu es dans le plan 2d, et que tu veux faire des rotations en 2d, tu as différents outils, par exemple :

• les matrices de rotations 2x2
• ou tu peux utiliser des nombres complexes (si tu te souviens de tes cours de maths en terminal, un nombre complexe s'écrit z = x + iy)

Au final être dans l'ensemble des complexes (C) avec des "x + iy", ou être dans le plan 2d (RxR) avec des couples de réels { x, y } c'est kif-kif (on dit qu'il y a isomorphisme de groupe, ça fait savant)
 
Quand tu es en 3d, et que tu veux faire des rotations en 3d, c'est similaire. Tu as :

• les matrices de rotations 3x3 ou 4x4 (au choix)
• ou les quaternions : q = w + ix + jy + kz

Et c'est kif-kif
 
Il s'avère que

• c'est facile d'écrire le quaternion correspondant à "la rotation d'angle a autour du vecteur u"
• c'est facile d'enchaîner les rotations en multipliant les quaternions entre eux (il y a 2-3 règles simples de calcul, comme pour multiplier 2 complexes)
• c'est facile de transformer un quaternion (genre le résultat de la multiplication dont on vient de parler) en matrice 3x3 ou 4x4, si on veut réinjecter ça dans opengl ou dans n'importe quel brol de calcul matriciel
• si on veut décomposer une grande rotation en plein de petites rotations (pour une animation ou autre) c'est direct il suffit de diviser.

Au final multiplier 2 quaternions ça fait moins de calcul (stabilité numérique), et ça permet facilement de composer les rotations comme on veut.  
En pseudo code, si t'as un axe et un angle, le quaternion c'est :

 
Après il te faut une méthode genre Multiply(quaternion q1, quaternion q2) qui est pas bien dure, et une méthode QuaternionToMatrix44(quaternion q) qui est pas bien dure non plus
 
(point bonus : ya les octonions aussi, avec 8 composantes au lieu de 4, mais pour le coup pour la géométrie en 3d ça sert à rien, la géométrie en 3d ça marche mieux avec 4 composantes)
 
La liste des façons de représenter les rotations en 3d :  
    https://en.wikipedia.org/wiki/Rotat [...] dimensions
On note :  

 
Le code trivial : http://glprogramming.com/codedump/ [...] rnion.html

merci. Je vais regarder ça si j'y suis obligé.
 
En tout cas the projecteur de three.js il a pas aimé les 1,8M de vertices.

Si t'as des questions sur la projection perspective on en parlera aussi t'inquiète

Orange Logic, vous connaissez comme boite ?
http://www.orangelogic.com/

j'ai viré des points inutiles, je descent dans les 50 000 et c'est vachement moins moche.
http://nraynaud.github.io/webgcode/ (bouton "Load a bigger sample" )
 
(et ça affiche au fur et à mesure maintenant)

Ce que je veux dire par le manager "paye" :
- soit les équipes marchent en client / fournisseur, et de fait c'est le manager de l'équipe projet ou maintenance qui "paye" le dev, parce que les jours hommes de dev seront refacturés a son département
- soit on parle du manager qui gère l'équipe de dev, et sa capacité est une forme de budget : si ton équipe peut produire 100 j.h par mois, ben si tu en consacres 20 a un refactoring, il t'en reste plus que 80 pour faire ce que ton équipe doit produire, et en tant que responsable c'est ton job de t'assurer que tu as assez de capacité a dispo, et en ce sens t'as un droit de regard sur ce qui impacte cette capacité.

Pour ce qui est de challenger le coût du refactoring lui même, c'est une connerie à mon sens : je ne challenge jamais les chiffrages en eux même, mais par contre je les considère comme un engagement de la part des devis : a eux de documenter leurs hypothèses et prendre un peu de gras.

Pour ce qui est du dev qui peut pas parler, je dis bullshit : je demande pas au gars de faire un speech au CIO ou a des grosses huiles du business, mais si il peut pas expliquer l'opportunité d'un refactoring à un manager IT, c'était peut être pas une bonne idée de l'embaucher

Et pour répondre au point de flo, je dirais qu'il est des refactorings comme des projets en général : le business case est pas toujours monétaire, mais ça empêche pas qu'il peut exister. Pour la sécu, le business case c'est souvent que ça rapporte rien, mais ça t'enlève ou te réduit un risque qui lui peut valoir des millions (eg : refactorer une zone fragile de l'App pour éviter de semer tes numéros de CB dans la nature)

nan mais laisse tomber, Flo il revient de Devoxx, il croit que les développeurs ont le pouvoir, tout ça

nan.
il pense qu'opposer des dev (barbu, irresponsables, incapable de comprendre les enjeux stratégiques) aux managers ( inutiles, ne regardent le monde que par leur fichier excel de budget) est une bétise : les deux sont incapables d'avoir une vision globale de l'ensemble des problématiques. Et des deux côté on trouve des incompétents persuadé de savoir et de  faire mieux que les précédents ou mieux que ses partenaires. Ceux ci sont carrément dangereux

Je milite pour que le dev et le manager soit à égalité, avec des périmètres de responsabilités différents, mais aussi important l'un que l'autre : avoir un produit qui marche <-> avoir un produit qui permet de faire tourner la boite.

ouais, enfin Clooneycafé, c'est pas comme si tu misais la boite sur un changement de framework JS.

Ha ben tant que tu peux simplifier ta géométrie go for it  

 
Certes. Après, si t'as un produit qui marche, et que t'as pas d'évol à faire, t'as pas besoin de refactorer, non?
 
 
L'important en matière de dette technique, à mon sens, c'est (dans l'ordre)
 
1 : l'identifier,
2 : ne pas construire dessus
3 : la résorber.
 
Et la priorité des refactos devrait tenir compte de cet ordre : un machin pourri mais qui marche, qui est testé et éprouvé, si t'as pas de temps à perdre et qu'on te demande pas de le faire évoluer au delà du pouillème, tu le refactores pas.

bah y'a une limite parce que si le mec zomme sur un arc de cercle ça serait bien que ça soit rond, sinon il a plus confiance dans ce qu'il voit.
 
(j'ai pas encore fait de LOD pour cette partie)

Si ça peut te rassurer j'ai l'impression que c'est quasi toujours le cas en informatique...

Je pense qu'on ne vit pas dans le même monde niveau application.
 
La plupart des boîtes n'ont pas de batteries de tests automatisés. N'ont pas non plus d'équipe QA pour faire des tests : ce sont les devs qui se tapent les tests manuellement.
Parce que pour faire des tests fonctionnels, il faudrait des vraies specs et des règles documentées. Et ça, c'est trop de boulot pour les managers de ces boîtes.
Une grosse partie des devs est faite par des JD qui n'aiment pas coder en fait, leur seul but est de passer le plus vite possible CdP.
Des DBA pour gérer les bases de données proprement ? Je n'ai vu ça qu'une fois. La plupart du temps ce sont des gars qui ont lu un tutorial SQL qui se chargent des schémas et du choix de bdd.
 
Avoir comme seul problème "on ne peut pas passer sur la dernière stack à la mode sur HN", ça ferait plaisir.

Tout le reste est vrai mais ça c'est faux, de nos jours ils subissent du SQL à l'école comme vous avez tous subi du OCamL à la fac, puis ils se ruent sur MongoDB une fois en entreprise. SQL, c'est le cobol du 21ème siècle pour eux.

 
Je crois qu'on a bien résumé le métier là

 
Le gros problème c'est la définition de "qui marche".
En général une appli avec une dette technique importante, tu ne peux même pas garantir qu'elle marche parce que t'es incapable de la tester correctement.
On en vient à une définition de "qui marche" qui se résume à : "le nombre de tickets clients ouverts n'augmente pas exponentiellement".
 
Cette mentalité de winners nous permet d'avoir aujourd'hui d'avoir donné naissance à des leaders du march... wait, no.
 

hého, perso quand j'ai eu le contrôle, j'ai toujours eu très peu de bugs ouvert (6 quand j'ai quitté Besac et une poignée quand j'ai quité Montpel), et j'ai jamais poussé aucun produit au succès

'tain la vache, je commence à comprendre pourquoi y'a des gens qui adorent dessiner des pixels en openGL plutôt que d'insérer des entités dans le DOM en SVG. c'est vers les quelques centaines de milliers qu'on sent la différence

http://nraynaud.github.io/webgcode/  
\o/ 220 000 lignes de code en 40s sans trop bloquer le thread graphique (bigger sample)

http://binaire.blog.lemonde.fr/201 [...] -au-lycee/ discuss

 
Euh, le mec qui code peut au moins tester ce qu'il fait pour le suivant (ou le lui même de dans 2 mois)...