simovni2:specs

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
simovni2:specs [2022/01/14 17:12]
laurentc 		simovni2:specs [2022/10/20 22:42] (current)
laurentc [Implementation]
Line 1: Line 1:
 ====== Simovni 2 Specifications ====== ====== Simovni 2 Specifications ======
- 
-===== Context ===== 
-The context is the problem of the quality of UAP observation reports. 
- 
-A written description is ambiguous. A picture is worth a thousand words. A 3D animation can fully describe the visual and spatio-temporal aspects of an observation.\\ 
-By simulating physics (even very simplified) or ensuring at least some internal consistency in the trajectories, the simulation can help test/reject hypotheses.   
- 
-===== Purpose ===== 
-Obtain better and more elaborate estimates of the observation parameters.  
- 
-===== Motivations ===== 
- 
-  * The availability in 2021, on the consumer market of standalone (untethered) Head Mounted Displays (HMDs) for Virtual Reality (VR) and Augmented Reality (AR). These new HMDs do not even need to work in a fully controlled environment. They don't need "reference bases" or pattern targets to be placed around.  
-  * The availability of free frameworks for the development of applications targeted on these devices. Namely : Unity 3d. 
-  * all the reasons that motivated the invention of the [[simovni2:specs#simovni_history|SIMOVNI]]. 
- 
-Some of the issues with SIMOVNI are solved, some appear. Many new things can be done that were impossible. 
- 
-Solved with some HMDs 
-  * unobstructed view solves the issue of the under estimation of angular sizes when looking through an opening (eyepiece of a refractor or binoculars for example)  
- 
-The new or remaining issues with HMDs are developed below. 
- 
-We expect better and more elaborate parameters estimations with such a tool than with the basic methods used by the investigators. 
- 
-===== Philosophy ===== 
-KISS (Keep It Simple Stupid) and remain pragmatic. 
- 
-One of our goals in this development, is to over specify and explore the theoretical/practical potential of the technology, yet limit ourselves to the most simple developments and proceed progressively and evolve the software based on the field results.\\ 
-We thus also define a minimum implementation. 
- 
-Before doing anything, we need to be sure we can obtain something of interest (see limitations).  
- 
- 
- 
 ===== Estimates ===== ===== Estimates =====
 ==== List ==== ==== List ====
Line 50: Line 15:
   * Level of blurriness   * Level of blurriness
   * **Position of the UAP** : 2 operating modes.   * **Position of the UAP** : 2 operating modes.
-    * **Direction relative to the witness** (*) (azimuth and angular height) +    * Polar by **Direction relative to the witness** (*) (azimuth and angular height) 
-    * Position relative to the witness (cartesian coordinates, X,Y,Z) +    * Cartesian by position relative to the witness (cartesian coordinates, X,Y,Z) 
   * Shape & Surface state / Texture   * Shape & Surface state / Texture
   * Evolution over time of all the estimates    * Evolution over time of all the estimates 
Line 78: Line 43:
 ==== Normalization==== ==== Normalization====
  
-In the session process, make the witness estimate by memory the characteristics of some known things for reference.+On site, make the witness estimate by memory the characteristics of some known things for reference.
 Typically for example : the moon. Size and luminosity. Typically for example : the moon. Size and luminosity.
  
Line 92: Line 57:
     * no problem     * no problem
   * Size | Angular size : star like to 160°   * Size | Angular size : star like to 160°
-    * Star-Like : we are limited by the resolution. FIXME How star-like does a single lit pixel feels like ? +    * Star-Like : we are limited by the resolution. How star-like does a single lit pixel feels like ? Calibrations,  computations and comparisons with stars can answer that. Voir [[simovni2:doc:lightbooth#sources_ponctuelles|sources ponctuelles]] 
     * Big things : We are limited to the field of view of the displays. Can be as low as 35° or as high as 90°     * Big things : We are limited to the field of view of the displays. Can be as low as 35° or as high as 90°
   * Distance   * Distance
-    * We deal with UAPs at distance of more than 6 meters. Beyond that distance there is no issue of accommodation conflict provided the HMD projets the virtual image at infinity.+    * We deal with UAPs at distance of more than 6 meters. Beyond that distance there is no issue of vergence-accommodation conflict provided the HMD projets the virtual image at infinity.
   * Color   * Color
     * The color gamut depends on the display technology. Ultra violet and deep red colors cannot be rendered well. But that is not a huge problem as far as the witness can tell the problem.      * The color gamut depends on the display technology. Ultra violet and deep red colors cannot be rendered well. But that is not a huge problem as far as the witness can tell the problem. 
Line 103: Line 68:
     * The display system is not limiting. Here the difficulty is not the display system, but our ability to know what the witness saw. The limitation is the ability of the witness to describe what he saw.  The human eye may be able to discriminate some additional characteristic of the light (polarization) but we won't go that far.      * The display system is not limiting. Here the difficulty is not the display system, but our ability to know what the witness saw. The limitation is the ability of the witness to describe what he saw.  The human eye may be able to discriminate some additional characteristic of the light (polarization) but we won't go that far. 
   * Apparent Luminosity: From the brightness of a star/satellite to a blinding electrical arc ?    * Apparent Luminosity: From the brightness of a star/satellite to a blinding electrical arc ? 
-    * That would be one of the most interesting parameters to measure accurately. FIXME. Question : how contrasted and luminous are these HMDs screens ?  Luminosity of a pixel ? FIXME. How do they compare to a mag -1 star or the moon ? Because this parameter is not calibrated at all (not even by product) there is a need for a calibration file per product and we will have to do it. This is a unique need. It makes this project innovative. +    * That would be one of the most interesting parameters to measure accurately. Question : how contrasted and luminous are these HMDs screens ?  Luminosity of a pixel ? How do they compare to a mag -1 star or the moon ? Because this parameter is not calibrated at all (not even by product) there is a need for a calibration file per product and we will have to do it. This is a unique need. It makes this project innovative. Calibrations,computations and comparisons with stars can answer that. Voir [[simovni2:doc:lightbooth#sources_ponctuelles|sources ponctuelles]].
   * Level of blurriness   * Level of blurriness
     * no problem     * no problem
Line 109: Line 74:
     * no problem.     * no problem.
   * Evolution over time of all the estimates   * Evolution over time of all the estimates
-    * The display frame rate are quite high (90hz+). High speed changes can be simulated. The HMD is not the limiting factor.+    * The display frame rate are quite high (60 or 90hz+). High speed changes can be simulated. The HMD is not the limiting factor. Smoothness of trajectories can be obtained by having the keypoints copied inside the HMD and the interpolation done on the HMD (not the case right now).
  
  
Line 124: Line 89:
  
 The parameters should be tunable in real time by the investigator and/or the witness.  The parameters should be tunable in real time by the investigator and/or the witness. 
 +
 +Starts with a calibration phase if necessary to be sure the witness properly sees through the HMD. (eye/device/ipd calibration). 
 +Set the brightness of the screen to a known and adapted level. 
  
 ==== Static Parameters ==== ==== Static Parameters ====
Line 136: Line 104:
     * In Mode 1 : absolute Yaw, Pitch, Roll.      * In Mode 1 : absolute Yaw, Pitch, Roll. 
     * In Mode 2 : billboard, always facing witness. No control.      * In Mode 2 : billboard, always facing witness. No control. 
-  * Direction relative to the witness : **Altitude**, **Azimuth** this is done by looking or pointing the HMD in the wanted direction. +  * Direction relative to the witness : **Altitude**, **Azimuth** and **North Direction** this is done by looking or pointing the HMD in the wanted direction. 
-  * Color ? How ? FIXME +  * Color ? How ? FIXME 
 ==== investigator side parameters & controls ==== ==== investigator side parameters & controls ====
  
Line 149: Line 116:
     * In Mode 2 : billboard, always facing witness. No control. Yaw, Pitch are computed in real time. Roll can be controlled      * In Mode 2 : billboard, always facing witness. No control. Yaw, Pitch are computed in real time. Roll can be controlled 
   * Direction relative to the witness : **Altitude, Azimuth** (*)   * Direction relative to the witness : **Altitude, Azimuth** (*)
 +  * **North Direction** (*)
   * Color ? How ? FIXME   * Color ? How ? FIXME
  
 and also and also
  
-  * **North Direction** (*) 
   * Selection of Orientation mode : 1 or 2.    * Selection of Orientation mode : 1 or 2. 
   * Level of blurriness   * Level of blurriness
   * **Distance**. Can be arbitrary if it is unknown. If arbitrary, distance should be set to a fixed value of more that 25m (for invisible stereo parallax), but not too far in order to remain closer than the back clipping plane of the rendering engine. (*)   * **Distance**. Can be arbitrary if it is unknown. If arbitrary, distance should be set to a fixed value of more that 25m (for invisible stereo parallax), but not too far in order to remain closer than the back clipping plane of the rendering engine. (*)
-  * Size : 2 operating modes. What's best ? Depends on the case. The origin of the 3D model should rather be defined close to its "center of gravity". The bounding box of the model at scale 1 is what is used for these computations. Since the size is a bit ill defined concept, the parameter that is controlled at low level is the scale of the 3D model. +  * Size : 2 operating modes. What's best ? Depends on the case. The origin of the 3D model should rather be defined close to its "center of gravity". The 3D model is supposed to just fit in a 1m width cube. The scaled cubic bounding box of the scaled model is what is used for these computations. Since the size is a bit ill defined concept, the parameter that is controlled at low level is the scale of the scaled 3D model. 
-    * **Size**. The size considered is the longest side of the bounding box <del>as seen from the witness</del>.  What is used as a parameter to interpolate is that max size in meters. The scale to apply to the model is computed accordingly. (*)  +    * **Size**. The size considered is the width of the scaled cubic bounding box, it is directly in meters.  What is used as a parameter to interpolate is that size in meters. (*)  
-    * Angular Size. The __max angular size__ over the 3 axis __**as seen from the witness**__ is what is used. What is used internally as a parameter to interpolate is the size (as defined just above) that produces that angular size.  ... FIXME not very satisfactory.+    * Angular Size. is computed as angular_size = 2*atan(size/(2 x distance)). This simple definition has the advantage of ensuring a constant angular size when the UAP rotates over itself. Even if its wrong in a way, it is a more satisfactory in the practical situations where we want to tune it visually. That does not prevent from having "another more correct" angular size computed, displayed and used in the report. What is used internally as a parameter to interpolate is the size (as defined just above). 
   * **Apparent Luminosity** (*)   * **Apparent Luminosity** (*)
   * 3D animation for the evolution of the Shape & Surface state / Texture animation time : anim_time   * 3D animation for the evolution of the Shape & Surface state / Texture animation time : anim_time
Line 169: Line 136:
  
   * addition/removal of key points (in order to control the evolution over time of all the parameters).    * addition/removal of key points (in order to control the evolution over time of all the parameters). 
-    * Each time a new key point N is inserted, one should specify the list of parameters for which this key point plays a role. All the other parameters will remain interpolated linearly from N-1 to N+1. +  * User sets a time for each key point. Then one should be able to change the duration of each segment (seconds) ; in that case, the time for each key point is re-computed.
-    * Each time a key point is removed, before removal, the user is recalled the parameters it did play on. +
-  * User sets a time for each key point ? No. Rather only a duration for each segment (seconds). The time for each key point is computed.+
  
 === play the simulation === === play the simulation ===
Line 183: Line 148:
 All parameters using "Système International" units. Degrees for angles. All parameters using "Système International" units. Degrees for angles.
  
 +====== Implementation ======
 +[[simovni2:implementation]]
 +----
 +
 +{{:simovni2:simovni2_canal_2022.png?600|}}\\
 +OVNI(s) S02E01 production Canal+ 2022 
  • simovni2/specs.1642176751.txt.gz
  • Last modified: 2022/01/14 17:12
  • by laurentc