Version imprimable
Avec le recul, j'aurais du automatiser la création du fichier sqlite d'exemple, au cas où il n'est pas présent... Je retiens le use case pour la prochaine fois!Citation:
Envoyé par Amnell
Sachant qu'elle est attendue, je vais donc la produire rapidement... et la soigner! Merci pour ton intérêt!Citation:
Envoyé par Amnell
Un exemple de rendu (un seul élément, sans couleurs) que j'obtenais avec mon module 3D (non intégré dans le projet soumis).
La prochaine capture sera celle du rendu dans DrCute, dès qu'elle sera dispo...
Question subsidiaire: Est-ce que quelqu'un peut m'expliquer comment intégrer dans son post une image que l'on a jointe en fichier attaché, sur ce forum? Je n'ai jamais trouvé cette option...
Edit: Résolu! Merci pour le tuyau, Amnell!
http://www.developpez.net/forums/att...ndu-bones.png/
Pour ma part, j'ouvre l'image dans un nouvel onglet, je récupère l'URL que je mets dans les balises IMG.Citation:
Envoyé par 0x4e84
Même sans couleur, c'est déjà pas mal du tout. Niveau performances, tu arrives à ne pas trop consommer ?Citation:
Un exemple de rendu (un seul élément, sans couleurs) que j'obtenais avec mon module 3D (non intégré dans le projet soumis).
Merci pour le tuyau!!Citation:
Envoyé par Amnell
Merci.Citation:
Même sans couleur, c'est déjà pas mal du tout.
Oui, sans souci. Je dirai même que je ne vois aucun impact sur la charge CPU, même quand je manipule la scène très rapidement dans l'espace. C'est parfaitement fluide.Citation:
Niveau performances, tu arrives à ne pas trop consommer ?
Ce qui me prend du temps, par contre, c'est le chargement initial du fichier .trian... Je pense qu'il y a largement de quoi optimiser à ce niveau-là, ce que je n'ai pas encore fait.
Au niveau du chargement des fichiers, la plus grosse optimisation à faire à mon avis est de les ré-enregistrer en binaire... cela réduira très fortement la taille des données.
Surtout s'il faut envoyer les données sur le réseaux, il ne vaut mieux pas envoyer le fichier brut en texte...
Bonne idée, je vais essayer...Citation:
Envoyé par gbdivers
Non, pas dans mon cas, vu que j'ai décidé d'effectuer le rendu du côté serveur, et d'envoyer l'image au client. Il y a du pour et du contre, et le lagging du serveur risque d'être critique au point de vue de la fluidité, mais je vais tenter le coup quand-même...Citation:
Surtout s'il faut envoyer les données sur le réseaux, il ne vaut mieux pas envoyer le fichier brut en texte...
Merci pour les conseils! :ccool:
Si tu veux vraiment t'amuser avec les optimisations de la 3d...
Une solution encore "plus mieux" (je pense) est de :
- côté serveur :
* générer une version "low polygon" des objets
* générer une (ou des) texture(s) contenant les détails "high poly" (normal mapping, displacement mapping, etc.)
* envoyer la texture et les "low poly" au client
* partitioner les triangles "hight poly", par exemple avec un octree bounding volume
- côté client :
* afficher les objets 3d en "low poly"
* si on fait un zoom, demander les "hight poly" uniquement pour les bounding volumes correspondant
Bon amusement ;)
C'était l'intérêt de ma question en fait : lorsque je m'étais penché sur la question au début du défi, je me suis heurté au fait que le chargement des .trian prend un temps considérable chez moi à cause de l'ouverture, du parsing et de l'insertion dans les listes.Citation:
Envoyé par 0x4e84
Nous nous heurtons effectivement au même problème alors.Citation:
Envoyé par Amnell
Je vais mesurer le temps d'exécution et tenter d'optimiser le parsing. Je te tiens au courant si j'obtiens des résultats concluants.
Euh, quel genre de temps considérable ?Citation:
Envoyé par Amnell
Moi, l'ouverture de tout les fichier .trian, c'était de l'ordre de 8 secondes ...
Ouverture et parsing compris, pour le plus gros des .trian, j'arrivais à plus ou moins ce temps lors de mes tests.Citation:
Envoyé par LittleWhite
Un point qui m'a intrigué d'ailleurs, sur les 3 projets je crois : personne n'a implémenté de stratégies pour compenser les problèmes de temps de chargement et de transfert de données j'ai l'impression :
- préchargement des données
- conversion des données en formats plus performant (low polygon ou low resolution)
- mise en cache
- prévisualisation
Par exemple, j'aurais aimé voir des listes avec prévisualisation des images plutôt que des listes en texte (ce qui nécessitait que le serveur créé des preview des images)
Idem, j'aurais aimé avoir une prévisualisation en plein écran des images lourde à charger (plutôt que d'avoir l'application bloquée le temps que la totalité de l'image se charge).
Du coup, j'aurais aimé garder la main quand une image se charge, par exemple pour annuler et revenir au menu ou pour faire un zoom sans attendre.
bref, plein de chose à faire
Citation:
Envoyé par LittleWhite
8OCitation:
Envoyé par Amnell
Je viens de faire le test pour le chargement + parsing de la plus grosse structure (bone.trian), chargé depuis un disque USB externe pas spécialement véloce, et je suis à 850-900 ms...
Bon, ok, je suis sur ma config du boulot, sous Win64, avec dual-Xeon (=8 coeurs, mais je n'ai pas géré le multi-threading, donc cela ne change rien) 2.4GHz... Mais tout de même, 8 secondes, cela me paraît long... Je vais essayer ce soir depuis mon Dual-Core...
Edit: même temps observés en chargeant depuis le SSD, pas de différence notable...
Ouep, c'était bien le problème d'avoir intégré le réseau dans le défi.Citation:
Envoyé par gbdivers
Je connais ces problèmes, et j'en étais assez conscient. Problème, comment faire des tests ?
Deuxièmement, notre équipe ... partait du principe => Hopital du futur, connexion de Méga ouf ... :(
Quels tests en particulier ?Citation:
Je connais ces problèmes, et j'en étais assez conscient. Problème, comment faire des tests ?
Pour tester la latence : ajouter d'un timer dans le serveur pour envoyer les données :)
... et données méga ouf. Le problème reste le mêmeCitation:
Deuxièmement, notre équipe ... partait du principe => Hopital du futur, connexion de Méga ouf ...
Hum, le timer, ouep, sinon, je "connais" des outils qui provoque des lags sur les paquets.Citation:
Envoyé par gbdivers
Ouep, je sais ... mais bon, j'ai un binome qui n'étais pas de cette avis :aie:Citation:
... et données méga ouf. Le problème reste le même
8 s me parait long aussi. Perso, j'ai 1,6 s (avec calcul de la bounding box et la création des buffers)
EDIT: et 135 ms pour le chargement des données binaires (avec recalcule des normales)
Voici quelques notes de review du code