Closed abakleriche closed 7 years ago
je regarde
c'est corrigé, je vous envoie un correctif dès que j'ai fait un autre truc, sur le sous-pixellique (je vais devoir trouver un moyen pour que les plans objets/distance/radiance soient parfaitement cohérents, pour que les calculs d'intensité de validation soient corrects).
Parfait ! Par curiosité, quelle était la cause de ce problème étrange ?
Le 19/09/2017 à 13:40, apajot a écrit :
c'est corrigé, je vous envoie un correctif dès que j'ai fait un autre truc, sur le sous-pixellique (je vais devoir trouver un moyen pour que les plans objets/distance/radiance soient parfaitement cohérents, pour que les calculs d'intensité de validation soient corrects).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/14#issuecomment-330512748, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2hKg2wzmDdP3udMCIh6JRwzUPLqUks5sj6gXgaJpZM4PY8mT.
C'est...hum...c'est gênant.... :D En fait on ne mettait pas à jour les materiaux user à chaque frame mais seulement à la première (c'est un oubli, on doit le faire vis à vis des non-hypothèses de l'API, qui permet aux matériaux de changer à tout moment), ce qui fait que les matériaux user ajoutés après la première frame étaient tout bonnement ignorés.
Je viens d'uploader une mise à jour, qui devrait corriger ce problème et fournir des résultats exacts pour le sous-pixellique (donc tout pixel qui recoit une contribution non nulle d'un objet devrait avoir l'objectId et la distance associés à l'objet, si c'est l'objet d'ID minimal sur le pixel).
OK Merci Anthony.
Nous testons ça cet après-midi à DGA MI. Quand penses-tu pouvoir nous fournir la version "officielle" (complète et finale ) ?
Le 20/09/2017 à 10:49, apajot a écrit :
Je viens d'uploader une mise à jour, qui devrait corriger ce problème et fournir des résultats exacts pour le sous-pixellique (donc tout pixel qui recoit une contribution non nulle d'un objet devrait avoir l'objectId et la distance associés à l'objet, si c'est l'objet d'ID minimal sur le pixel).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/14#issuecomment-330787806, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2ol1LVIJMMRlxrkP5Kt_cA1JFGaxks5skNGYgaJpZM4PY8mT.
Quand tu nous diras que tout marche de votre côté et que notre cahier de recette interne passera de notre côté (on en est pas loin ici).
Problème corrigé, je ferme.
En attendant de pouvoir utiliser les leurres avec la précision étendue, Jonathan a fait des essais dans VHEDAA sans mettre les leurres en précision étendue. Il a fait un scénario avec un cube au format EMIR (donc converti en bdd + collection d'ATH) et un leurre EMIR. Un leurre EMIR, c'est comme un leurre RENULIR, mais plus simple (une seule facette). Le scénario se déroule bien avec SE-RAY. Avec SE-FAST, le leurre apparaît froid, et en creusant on voit que la callback qui donne la luminance du matériau n'est pas appelée (ce qui explique qu'il est froid). Bizarrement, il a le même comportement avec un leurre RENULIR, alors que j'ai des tests unitaires VISEO avec des leurres RENULIR qui marchent. Il a exécuté le scénario VHEDAA en mode logging, donc je te joins les deux log d'exécution (SE-RAY et SE-FAST). Le scénario générait 500 images, j'ai tronqué les log à 65 images. Le leurre apparaît à partir de l'image 37. Je te joins les images 65 obtenues avec le setk_player sous Windows avec les options -user_radiance 300 et -user_transmission 0 (Le problème apparaît également sous Windows). Dans l'image SE-RAY, c'est le leurre qui est au centre l'image (car le capteur a suivi le leurre, plus chaud), alors que dans l'image SE-FAST, c'est le cube. cube_et_leurre.zip