D'accord, je comprends mieux... du moins si j'ai bien compris ce que tu appelle un "masque de relief" (le fait de "ne pas voir" un objet caché derrière le relief ?) Oui en effet, le "masque de relief" est l'une principale difficulté, et dans les méthodes que je conçois au jugé, je vois mal ED laisser l'accès aux développeurs de modules pour faire ça eux-même, car:DeeJay a écrit : ... Je dirais plutôt "le masque de relief" ... et si ça c'est "enfantin" à calculer., je pense qu'il et possible que cela dépende du moteur terrain.
MavJp qui est le le programmeur qui nous a refait entièrement le moteur du modèle de vol ainsi que le FLCS du F-16 de BMS en a "un peu" chier avec ça je crois (cependant, je ne suis pas sûr à 100% qu'il en ait chier (?)) mais en tt cas, le moteur terrain a posé des problèmes notamment pour le TFR (Terrain Following Radar).
1) Dans les différentes méthodes (selon ce qu'on veut faire, on a plusieurs options), ça requière de toute façon de la programmation "bas niveau", c'est à dire qu'on travail au niveau du mesh (model 3D) du terrain, ou au niveau du moteur de rendu.
2) C'est potentiellement un "frame-rate killer", parce-que si c'est mal fait, mal optimisé, c'est un gouffre à ressources.
C'est ce qui me fait dire que ED a déjà programmé ça en natif, d'une manière d'une autre, et que l'API donne la possibilité aux développeurs de l'utiliser facilement, et je pense même que ça fait partie de la fonction "radar" de base, car, les IA y sont soumises comme tout le reste, donc l'algo existe, et il serait idiot de faire refaire tout ça (qui est vraiment de la hard-programmation) par les développeurs de module. C'est un peu comme si on demandait aux développeurs de module de reprogrammer une partie du moteur physique... ça n'a pas de sens.
