test13

[abakleriche]

Il s'agit d'un test sur les objets peu résolus.

J'ai deux problèmes (avec SE-FAST)

• Le plan objet semble fantaisiste
• A très grande distance, l'objet disparaît de la scène (bien que je demande toujours la même résolution pour cet objet). De plus, il me semblait que ça marchait avec CHORALE 2017.

Ci-joint les données avec les deux fichiers log test13_player_fast.zip

[apajot]

Pour le plan objet, c'est un problème connu, il faut qu'on le fasse. Il y a le meme soucis avec le plan distance (tu as la distance à l'imposteur, pas la vraie distance). Pour la très grande distance, avant que je ne regarde plus précisément, elle est bien inférieure à la distance du plan far de clipping ?

[abakleriche]

Je regarde, dans le log que je t'ai fourni, ce n'est pas le cas, mais cela aurait dû l'être. J'ai un cafouillage à ce niveau là, je te redis dès que c'est clair. Par contre, lorsque j'exécute ce test, avec la dernière version du toolkit, j'ai une violation d'assertion dans C:/devs/DevProduitSE/dev/commun/src/xio/Element.cpp ligne 444 Expression _impl->_playCount>0 A priori ça a lieu dans le seTkSimulationStop

[abakleriche]

Je mérite le bonnet d'âne ! J'ai 3 tests à 3 distances, et ne n'avais positionné les distances de clipping que pour le premier, à la distance la plus courte (là où c'était inutile). Donc cette partie du problème est résolue. Il reste l'histoire des plans objet et distance, et la violation d'assertion

[apajot]

ouf ! les plans objet et distance c'est noté, je vais regarder le temps que ca prendrait pour le planifier ensuite. La violation d'assertion Lalaina est dessus depuis un petit moment déjà, dès que c'est corrigé je te relivre.

[apajot]

C'est corrigé.

[abakleriche]

Le plan objet est OK. Par contre, il reste des incohérences entre le plan objet et le plan distance : certains pixels sont considérés (à juste titre) comme appartenant à l'objet, mais la distance associée est celle du fond.

[apajot]

Je regarde.

[apajot]

Je n'ai pas trouvé de cause à ton problème (et je n'ai pas réussi à le reproduire), par contre j'ai fait une correction qui change la manière dont on calcule les objectId et distance sur les bords des objets, peut-être que c'était lié par un sombre moyen que je ne vois pas. Du fait des limitations d'openGL, le plan objet et le plan distance n'ont pas exactement le même comportement en rendu sous-pixellique qu'avec de l'anti-aliasing hardware. Avec de l'AA hardware, on a accès à tous les échantillons couvrant un pixel, et on fait le choix explicitement parmi eux pour garder celui d'objectId min. Avec le rendu sous-pixellique, on ne peut pas avoir accès à ca efficacement, les plans objets et distances sont donc obtenus via une texture en mode nearest (seul mode de "mélange" assurant une cohérence, moyenner des distances ou des objectIds n'ayant pas de sens aux discontinuités). Du coup, il se peut que des pixels de bord contenant manifestement une portion de l'objet sous-pixellique aient l'id et la distance de l'objet en arrière plan (avant la correction, ils avaient objectId = 0 et distance = 0). Le calcul d'intensité est donc très légèrement faux (cela dit il l'était déjà avant vu que sur le bord on ne distingue pas la contribution du fond de celle de l'objet), mais on ne peut pas faire mieux. Tu auras cette correction avec la prochaine livraison de Paul. Si nécessaire je peux t'en faire une avant.

[abakleriche]

Je viens de tester la nouvelle version. Désormais, le fonctionnement est inversé : il y a des pixels qui appartiennent à l'objet, qui ont la distance de l'objet, mais qui sont identifiés comme pixels de fond. Sur le leurre à 50 km, aucun pixel n'est identifié comme appartenant à l'objet. Le comportement précédent était un problème mineur, le nouveau est un problème majeur pour VHEDAA. Serait-il possible de revenir au comportement précédent ? (Avec mes excuses pour t'avoir fait travailler inutilement).

[apajot]

Pourrais-te me fournir des données ? ce comportement d'incohérence n'a aucun sens...(par contre pour le leurre à 50km, s'il est très sous-pixellique, oui ca arrivera. Si ca n'arrivait pas avant c'était un coup de chance, la limitation pour garder des performances convenables venant d'OpenGL.

[abakleriche]

Ci-joint les données et l'image produite. test13.zip

Tous les pixels ont un code -1, y compris ceux qui ont une distance à 50 km. Dans la version précédente, il y avait quelques pixels qui avaient un code 0 (leurre) et la distance du fond (ce qui est beaucoup moins gênant).

[apajot]

le code 0 était un hasard (valeur par défaut), ca n'était pas le leurre. Je vais regarder.

[apajot]

Bon, la seule solution robuste que l'on voit est d'assurer quasi la même précision qu'avec de l'antialiasing standard, et on ne voit qu'un seule solution technique viable pour le faire, qui reste malgré tout coûteuse en temps de calcul (il faut construire des mipmaps spécifiques à la volée, et meme en restant sur GPU ca implique des pings-pongs de données de GPU à GPU). Elle aura donc un impact sur les performances lorsque les plans objets et/ou distance seront activés (notamment incompatible avec OSTAIR). J'estime avoir besoin d'entre 2 et 3j pour le coder/debugger, et je m'y mets dès que j'ai fini ce que je fais là.

[apajot]

Je viens de déposer une mise à jour qui devrait corriger tes problèmes. Je n'ai fait que la version windows, si tu as besoin d'une version linux il n'y a qu'à demander !

[abakleriche]

Merci Anthony. Ça m'a l'air de bien marcher. La version Linux peut attendre (à moins que tu n'identifies un risque de comportement différent ?). Je ferme l'issue. Le truc qui maintenant nous bloque pour finir les tests de recette VHEDAA c'est le memory leak avec les leurres RENULIR (issue #12). Est-ce que les données fournies sont suffisantes pour que tu regardes ?

[abakleriche]

Je rouvre l'issue car on a encore un problème sous Linux. Dans certains cas, si on active la précision étendue, on a des valeurs fantaisistes pour le plan objet sur des facettes de bord de l'objet. cf. exemple joint, avec image obtenue. pb_pl_ob.zip Les valeurs semblent plus ou moins aléatoires, et le problème ne semble pas se produire sous Windows (mais on a plus de chance de le détecter sous Linux, car VHEDAA sort en erreur s'il trouve un objet inconnu).

[apajot]

Je regarde

[apajot]

Je viens de corriger un truc que j'avais remarqué hier soir, qui ressemble à ca. Je n'ai pas réussi à reproduire le cas d'erreur sous windows à partir du log, mais je t'ai uploadé la version avec la correction que j'ai faite, tu me diras si ca corrige ton problème. Si ce n'est pas le cas je me mettrai en situation de débugger sous Linux.

[abakleriche]

Mon collègue Jonathan vient d'essayer à DGA MI. Il a une erreur au link : référence non définie à un truc du genre SE_FAST_IR_V4::outputmodule::key... (Approximativement car il m'a dit ça au téléphone). Je n'ai pas d'erreur au link sous Windows.

Le 13/09/2017 à 16:14, apajot a écrit :

Je viens de corriger un truc que j'avais remarqué hier soir, qui ressemble à ca. Je n'ai pas réussi à reproduire le cas d'erreur sous windows à partir du log, mais t'ai uploadé la version avec la correction que j'ai faite, tu me diras si ca corrige ton problème. Si ce n'est pas le cas je me mettrai en situation de débugger sous Linux.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/8#issuecomment-329181312, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2mvsEac_Lstoxz90tsPjV1voadeoks5sh-NVgaJpZM4OMdr_.

[apajot]

ok, ca sent la compilation pas complètement refaite... je recompile la version linux, et j'en profiterai pour te faire passer la nouvelle version d'OSG qu'on vient de déployer ici (on a dû faire quelques modifs pour OSTAIR). Il faudra faire quelques modifs dans tes scripts d'environnement (remplacer osg_3.0-OSE1 par osg_3.0-OSE2). Vu le débit qu'on a j'espère que l'upload prendra moins de 2h...

[apajot]

Bon, on a un soucis de déploiement, je te refais une compile basée sur la version d'OSG que tu as.

[apajot]

C'est uploadé

[apajot]

J'ai uploadé la version de test.

[abakleriche]

Voici les impostors et l'image générée.

Le 14/09/2017 à 16:39, apajot a écrit :

J'ai uploadé la version de test.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/8#issuecomment-329503310, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2lCNAQuLwceyaj_HdfJoeS4lS-dQks5siTqvgaJpZM4OMdr_.

[apajot]

Je ne vois pas la pièce jointe, dois-je prendre rdv chez l'ophtalmo d'urgence ?

[apajot]

Décidément, je ne reproduis rien...Juste une question pour être sûr : tu as les mêmes fichiers de shaders sur l'install windows et l'install linux ?

[abakleriche]

Oui, j'ai bien recopié le répertoire Private. Je vais essayer de vérifier (en faisant un diff), mais ce n'est pas simple car l'install Linux est à DGA MI, et l'install Windows à ABAK (je n'ai plus de machine Windows à DGA MI sur laquelle je puisse faire tourner FAST-IT-V4), et pas de liaison internet à DGA MI ! Donc il y a des déplacements physiques. Tu as fait tourner le player sous Linux avec le fichier log qui pose problème ?

[apajot]

non j'ai repris le scénario équivalent et je l'ai fait tourner avec SE-TK-RENDER. Je vais te faire un paquet avec SE-TK-RENDER, SE-WORKBENCH-SDK, les shaders et le nouvel OSG, tout ca windows et linux 32 bits, et le scenario que j'utilise.

[apajot]

C'est uploadé.

[abakleriche]

Problème corrigé, je ferme.