Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
et toutes ces démos webgl qui rament à 3 fps pour m'afficher de la 3d d'il y'a 10 ans, c'est quoi, c'est de l'algo O(N3) ?Envoyé par super_navide
ou c'est juste du travail de porc bien bâclé parce qu'on va pas claquer des budgets pour ubsifot dans un logiciel gratuit ?
je vous laisse chercher quelle est la bonne explication
moi je la sais
je vous donne un indice, c'est celle qui vous fout les jetons et que vous ne voulez pas entendre
@super_navide:
J'ai l'impression que ta vision des performances du JavaScript est un peu biaisé par le fait que ce soit le langage que tu utilise quotidiennement (et que tu apprécies manifestement). Niveau performance brut JavaScript aura du mal à se mettre au niveau de C/C++ sur les points suivants :
-Performances purs : Le C++ est compilé il est donc forcément meilleur niveau perfs. La phase d'interprétation au runtime du JavaScript est remplacé par la compilation (en amont) en C++ .
-Déterminisme : Le C++ n'étant pas garbage collecté et ayant très peu d' "overhead" il est beaucoup plus constant en temps d’exécution que le JavaScript. Pour les applis temps réels (souple ou dur) c'est très important.
-Multi-threading : Sans les Workers apparu récemment le JavaScript n'était pas multi-threadé. Et je ne sais pas à quel point c'est possible de multi-threadé du code aujourd'hui.
Après il faut relativiser, pour ce qu'on lui demande aujourd'hui, il est suffisament performant. Mais, je vois mal de grosses applis 3D temps réel (rendu 3D, physiques, audio 3D, IA, etc...) être réalisés qu'en JavaScript, du moins pour les prochaines années et ceci pour deux raisons :
1-Les performances pour les application exigeantes.
2-Le nombre de frameworks/librairies qui doit être assez limités dans ce domaine par rapport au C/C++.
super_navide raisonne surtout à un tel degré d'abstraction qu'il ne voit pas que les problèmes sont situés à l'opposé de là où il regarde c'est à dire au bas-niveau... les principaux défauts du html5 c'est que la sortie vidéo est bâclée, la sortie audio également, et niveau webgl la reconnaissance des gpu est encore dix fois plus bâclée que tout le reste, c'est des problèmes sous le capot dùs à un utilisation tellement minimaliste torchée en speed de dx/gl que les chipset gpu/audio sont totalement largués et là on est absolument pas dans des problèmes de maths mais dans des problèmes des team mozilla/ms/google qui n'ont pas les délais-budgets suffisants pour se taper toute la doc des librairies hardware, ça n'a strictement rien à voir avec ses histoires d'algorithme de recherche et de tri de fiches de paye
Cette application est fluide même sur ma nexus 7
http://carvisualizer.plus360degrees.com/classics/
à peu près 15 fps chez moi
même en comparant à C# (natif apps et .net) javascript se fait laminer, cela dit en WEB ( techno vitale actuellement) on à pas trop le choix...
Personnellement j'ai fais du WEBGL pour un entrepôt 3D , ça marche bien mais il faut pas donner cette techno à un programmeur qui n'est pas habituée à la 3D, la 3D est un monde à part et les raisonnements d'application métier ne s'y appliquent pas totalement, il faut éviter d'utiliser le CPU et faire en sorte que le maximum passent pas le GPU. Ces notions de parallélisme massif sont dures à appréhender même par un bon dev.
pour moi une bonne techno doit être performante tout en permettant la collaboration entre les designer et développeur et services ( xaml /.net est pas mal à ce niveaux) cela dit quand je travail sur la 3d médical ou les décodeur vidéo, C++ voir (c et asm) s'imposent encore, et on arrive sur des projets avec un effet tunnel assez important(on ne peut pas toujours utiliser direct Show /Media foundation/VLC pour des questions de latence et correction d'image).
javascript est ptêt bien le langage le plus lent du monde, c'est connu, faut éviter de faire n'importe quoi avec
webgl est justement plutôt bien fichu pour que tu n'aies pas à te soucier des problèmes de synchronisation entre les cartes (c'est au moins le minimum qu'on est sensé en attendre), il gère toute l'allocation vram tout seul (d'ailleurs ça m'énerve car je comprends rien à ce qui se passe là dessous, apparemment par exemple il ne fait aucune distinction entre buffer statique et dynamique, ni de distinction entre stream et reallocation, et je trouve pas ça propre du tout car du coup je vois pas comment optimiser quelque chose là dedans)
ce qu'l faut connaître surtout c'est les règles d'optimisation, pas de model high-poly, limitation des drawcall, adapter la résolution aux performances des browsers
voilà le genre de démos qui chez moi sont fluides sur chrome uniquement (sur ff et ie c'est la cata, et sur mobile ça doit etre bien pourri aussi...):
http://threejs.org/examples/#webgl_geometry_minecraft
http://threejs.org/examples/#webgl_g...y_minecraft_ao
http://threejs.org/examples/#webgl_geometry_hierarchy2
http://threejs.org/examples/#webgl_geometry_shapes
http://threejs.org/examples/#webgl_i...ing_pointcloud
http://threejs.org/examples/#webgl_i...e_voxelpainter
http://threejs.org/examples/#webgl_lights_hemisphere
http://threejs.org/examples/#webgl_lights_pointlights
http://threejs.org/examples/#webgl_l...llada_keyframe
http://threejs.org/examples/#webgl_l...llada_skinning
http://threejs.org/examples/#webgl_loader_json_blender
http://threejs.org/examples/#webgl_l...n_objconverter
http://threejs.org/examples/#webgl_shader
avec de la 3d simple on s'en sort quoi.
pour du web j'estime que c'est amplement suffisant. ça fait des jolis bidules pour décorer les sites et on recherche pas à faire grand chose de plus vu qu'à vrai dire on a pas trop le temps. quand t'as deux semaines pour peinturlurer un template wordpress, la bande effect html5 c'est en option si il te reste du temps, sinon on vit bien sans
et ceux qui sont pas contents parce qu'ils veulent imiter leur ps4, il va falloir se faire une raison, s'il y'a pas de place pour vous chez ubisoft c'est qu'il y'a pas de place
[edit]je n'aurais pas du disgresser sur les jeux vidéo, c'est presque du hors sujet dans un topic sur webgl
je préfèrerais revenir à un sujet qui fâche: la gestion de la ram soi-disant "automatisée" et qui en fait vous gaspille un max de Mo, et le garbage collector qui apparemment ne se réveille que quand on ferme la fenêtre navigateur
j'aimerais bien comprendre comment ça tourne là dessous sinon je prends le risque de faire n'importe quoi avec des leaks de partout...
Je ne développe pas en JS mais je ne pense pas que son GC déroge à la règle ; généralement le GC et le JIT alloue un beau paquet de mémoire au lancement de l’appli (pour pouvoir compiler le code à l’exécution). Au-delà de ça il faut savoir que lorsque le GC va passer faire le ménage, la VM ne va pas nécessairement rendre toute la mémoire libérée au système (c’est une opération coûteuse et pas forcément nécessaire... et puis tant que le système n’a pas de besoin présent, c’est de la mémoire toute chaude qu’on n’aura pas à aller réclamer). Bref, suivant la VM utilisée tu peux évidemment te retrouver avec des politiques de gestion de mémoires plus ou moins différentes.
Autre détail, si ton code managé fait appel à du code natif (c’est certainement le cas avec WebGL), la mémoire utilisée par ce denier ne sera pas non plus rendu au système ; l’épinglage des objets empêchera le GC de déplacer le bloc de mémoire alloué.
autrement dit débrouille toi pour faire ton propre système d'alloc avec du recyclage de buffers de 20 000 faces
programmer avec webgl le bonheur à l'état pur
bon histoire de pas faire en permanence mon gros méchant qui dit du mal de tout,
deux trucs que j'apprécie dans webgl:
- le langage javascript est ultra-fastoche, j'ai l'impression de revenir au qbasic, c'est reposant et productif...
- ça reste suffisemment bas-niveau pour qu'il y'ait un côté do-it-yourself plus créatif que d'utiliser un moteur genre unity
voilà ça fait au moins deux bons points
j'en vois pas d'autres pour l'instant...
T'es un mec dangereux toi oO
Ton pc a 6 ans d'âge Jean Kevin
Je teste aussi webgl sur d'autres machines récentes et ben... c'est encore pire lent sur les pc portables.
De toutes façons le javascript si c'était rapide ça se saurait. J'ai bossé dans le web, c'est de notoriété publique que c'est un langage très lent (en moyenne 20 fois plus lent que le c++) donc il faut l'utiliser de façon minimaliste.
Faire des jeux vidéos avec ça c'est casse-gueule, c'est trop lent pour gérer de la physique, de la haute résolution, du culling par face, des bones, des shader nextgen.... il vaut mieux se contenter de faire de la ptite appli ornementale genre bande effect menu 3d etc.
Afficher une application 3D dans un browser, il y a des tonnes d'applications. Dans ma société on en a besoin constamment, nous travaillons pour des promoteurs immobiliers , on leur proposer donc une modélisation 3D des bâtiments qui est présenté sur une application mobile et sur le web. Le programme immobilier est donc présenté en multi canal et est un formidable outil d'aide à la vente.
Lorsque que sur un site web One Page tu a toutes les plaquettes, les rendus 3D d'un bâtiment et que tu peux en plus naviguer dans le bâtiment et autour du batiment dans une vue web GL en 3D temps réel , ca me parait évident que c'est une grosse plus value.
Pourquoi perdrais t'on en performance et en ergonomie ? les browsers évoluent tous les jours avec leur spécifications, leurs performances. Pourquoi seulement limiter les navigateurs aux liens hypertextes et à la 2D ?
C'est un bon exemple d'utilisation du webgl.
Quand à la question des performances c'est les développeurs qui en sont responsables, il faut déterrer les vieilles techniques d'optimisation et être copain avec le taskmgr.
Revenir à de la 3d simple je vais pas m'en plaindre, ça fait moins de boulot...
Ben arrête d'essayer de faire tourner des démos sur ta calculatrice Texas Instruments...
ma machine fait tourner impeccablement les jeux genre doom3 et je n'ai pas besoin de plus pour faire de l'internet, et quand on verra le même genre de rendu dans webgl les poules auront des ratiches. dual core 2*3giga et carte pixel shader 3, fait tourner sans problème des dizaines de milliers de poly dans le frustum avec shaders parallax bump shadow physx etc... mais pas avec webgl
mettez un peu les mains dans l'opengl c++ vous allez voir la différence de perfs avec webgl
mais c'est sûr que si tu prends pas la peine de comparer tu peux pas savoir
Le navigateur de demain c'est l'OS d'aujourd'hui, WebGL n'est pas une mauvaise idée en soit mais n'est pas à utiliser à toutes les sauces, au niveau performance il sera toujours mieux de créer une applis PC directement mais si ce n'est pas le but premier on pourra se contenter de WebGL.
Je l'imagine bien être utilisé pour de la 3D Pro vu que le monde Pro veut avoir accès à des sites Web plutôt que des applis pour éviter tout ce qui est problème de déploiement et de MAJ et ça peut être très intéressant pour le travail collaboratif étant donné qu'on est sur le Web rien nous empêchera de travailler à plusieurs sur un même model par exemple, le seul problème se situera peut être du côté des performances.
Il y aussi les applis destiné au grand public comme les logiciels de cartographie, de météo, de simple éditeur de photo ...
Pour les petits jeux tel qu'Angry birds (qui existe déjà sur chrome) et cie, qui était fait en flash hier pour certain, seront fait en WebGL demain, ces jeux sont souvent assez simpliste niveau graphique et possibilité, donc WebGL peut très bien s'y prêter.
Il y a juste les jeux AAA (GTA, COD ...) pour lesquels c'est pas forcément une bonne idée, la demande en performance est énorme et la complexité du moteur graphique, physique et de l'IA est tel que retranscrire ça en WebGL demande un travail monstre et le jeu n'en vaudra surement pas la chandelle surtout si le joueur aura un jeu moins beau sur son navigateur, il préféra surement la version classique qui sera un cran au-dessus niveau graphique.
Chez moi chrome ne rend pas le webgl en émulé mais bien en hardware.
Et quand tu vois qu'il lui faut pomper tout un coeur 3ghz pour afficher trois polygones avec une résolution pourrie, alors que quand je fais la même chose avec directx ça consomme 0% du cpu en high-res, là tu captes que chez les fabricants de navigateurs, faire du boulot propre c'est le cadet de leurs soucis. Tant qu'il y'a pas de concurrent sérieux pour les tarter ils ont aucune raison de se fouler.
Pour l'instant ils sont contents ils ont usé de jeux de pression éhontés qui ont fait crever les plugins qui rendaient la 3d dix fois mieux (on va pas s'en plaindre, avoir un standard c'est ça de gagné), mais quand on est fortiche en marketing malhonnête on est rarement doué pour produire la qualité, et si demain une boîte fait un browser propre ça va moins faire les marioles chez googlecrosoftzilla.
Et puis chez google c'est pas vos copains, leur nouvelle idée c'est de tenter de faire dégager le javascript d'internet en essayant d'imposer un nouveau standard exotique...
Faut faire avec.
Quand on aura un browser qui sait faire tourner la carte vidéo sans gaspiller tout le process avec du travail de porc codé à la truelle par des charlatans qui s'intéressent pas à ce qu'ils font avec une ostentation éhontée, on pourra parler d'avenir dans les browsers, mais pour l'instant on en est très loin.
Pour des raisons évidentes de sécurité, vaut mieux pas.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager