Discussion :

[0x4e84]

Effectivement, j'avais un fichier .sqlite automatiquement créé qui faisait exactement 0 octet, d'où la difficulté d'une réception du modèle des médecins.

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!

Dans ce cas, je ferai sans doute partie de ceux qui attendront la partie 3D, même si elle est postée hors concours.

Sachant qu'elle est attendue, je vais donc la produire rapidement... et la soigner! Merci pour ton intérêt!

[0x4e84]

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!

[Amnell]

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...

Pour ma part, j'ouvre l'image dans un nouvel onglet, je récupère l'URL que je mets dans les balises IMG.

Un exemple de rendu (un seul élément, sans couleurs) que j'obtenais avec mon module 3D (non intégré dans le projet soumis).

Même sans couleur, c'est déjà pas mal du tout. Niveau performances, tu arrives à ne pas trop consommer ?

[0x4e84]

Pour ma part, j'ouvre l'image dans un nouvel onglet, je récupère l'URL que je mets dans les balises IMG.

Merci pour le tuyau!!

Même sans couleur, c'est déjà pas mal du tout.

Merci.

Niveau performances, tu arrives à ne pas trop consommer ?

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.
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.

[gbdivers]

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...

[0x4e84]

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.

Bonne idée, je vais essayer...

Surtout s'il faut envoyer les données sur le réseaux, il ne vaut mieux pas envoyer le fichier brut en texte...

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...

Merci pour les conseils!

[gbdivers]

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

[Amnell]

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.

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.

[0x4e84]

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.

Nous nous heurtons effectivement au même problème alors.
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.

[LittleWhite]

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.

Euh, quel genre de temps considérable ?
Moi, l'ouverture de tout les fichier .trian, c'était de l'ordre de 8 secondes ...

[Amnell]

Euh, quel genre de temps considérable ?
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.

[gbdivers]

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

[0x4e84]

Euh, quel genre de temps considérable ?
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.

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...

[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

Ouep, c'était bien le problème d'avoir intégré le réseau dans le défi.
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 ...

[gbdivers]

Je connais ces problèmes, et j'en étais assez conscient. Problème, comment faire des tests ?

Quels tests en particulier ?
Pour tester la latence : ajouter d'un timer dans le serveur pour envoyer les données

Deuxièmement, notre équipe ... partait du principe => Hopital du futur, connexion de Méga ouf ...

... et données méga ouf. Le problème reste le même

[LittleWhite]

Quels tests en particulier ?
Pour tester la latence : ajouter d'un timer dans le serveur pour envoyer les données

Hum, le timer, ouep, sinon, je "connais" des outils qui provoque des lags sur les paquets.

... et données méga ouf. Le problème reste le même

Ouep, je sais ... mais bon, j'ai un binome qui n'étais pas de cette avis

[gbdivers]

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)

[gbdivers]

Voici quelques notes de review du code