leurre froid

[abakleriche]

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

[apajot]

je regarde

[apajot]

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

[abakleriche]

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.

[apajot]

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.

[apajot]

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

[abakleriche]

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.

[apajot]

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

[abakleriche]

Problème corrigé, je ferme.