Amerio.Stephane Posted March 8, 2021 Share Posted March 8, 2021 Hello, We are facing a discrepancy between angles computed by our simulator and geo position used in Unigine. First, let's be clear: we don't know if the problem described here-after lies within Unigine or within our code. It's totally possible we are doing something wrong. So, here is the scenario, implemented with a rounded GlobalTerrain in 2.13.0.1. A camera is embarked inside a moving IG entity. The camera is oriented with fixed Euler angles {azim,elev}, looking at some point on the ground. Then, on some pilot action, the camera must remain "locked" to the last point on the ground it was aiming at, meaning now {azim, elev} will be computed so the camera will rotate to look at the same point. The problem is, because the FOV of the camera is so small (1°), even a small error (0.1°) will look unacceptable. With Unigine, we can easily get the point on the ground given the Euler angles and the geo position of the camera. Then we send the geo position of the hit point to our simulator, which will compute the new azimuth, elevation} so the camera can track the point. But we always have an error in the 0.1° range, whatever the geo position of the camera or the camera angles. Here is the view from the 1° camera: Here, the cyan point is always at the center of the field of view, and represents the intersection point of the line of sight of the camera. Based on this point, the yello azimuth and elevation are computed and a new ray is cast with this direction, giving the yellow dot on the ground. As you can see, the error is far too important. Here is a world view: The ray is cast from the entity toward the green round earth. Attached: sample source code and project.TestLOS.zip Note: In the future, as all geodetic computation are highly dependent on the IG geodetic converter, maybe it would be great to have some sort of reusable code to be included on our side to do such calculation, that would work for both flat and round earth, and Terrain and Landscape. This would be really great! Thanks! 1 Link to comment
silent Posted March 8, 2021 Share Posted March 8, 2021 Hi Stephane, Thanks for the test scene. It for sure will take some time to understand what is going on here. We will report back as soon as we would find something useful. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
cash-metall Posted March 9, 2021 Share Posted March 9, 2021 Hello the problem is converting flat coordinates to geo coordinates if you try to add ObjectTerrainGlobal under GeodeticPivot - ig start working in curved mode, and everything is fine. but in flat mode we can't get away from distortions of directions and sizes... (i dont know how to correct these distortions on your side ) you can try to use GDAL(GeodeticPlugin) to convert flat world coordinates to geo and back. for switch IG to work with GeodeticPlugin you need remove GeodeticPivot from world and init GeodeticPlugin in AppSystemLogic auto geodetic_plugin = GeodeticsTransformer::get(); if (!geodetic_plugin) { Engine::get()->addPlugin("Geodetics"); geodetic_plugin = GeodeticsTransformer::get(); } if (geodetic_plugin) { geodetic_plugin->setProjectionEpsg(epsg, geodetic_origin); // specify epsg projection } and use GDAL (or other library to work with epsg projection) 1 Link to comment
Amerio.Stephane Posted March 9, 2021 Author Share Posted March 9, 2021 1 hour ago, cash-metall said: if you try to add ObjectTerrainGlobal under GeodeticPivot - ig start working in curved mode, and everything is fine. You are right! So having a GeodeticPivot by itself is not enough, we actually need a ObjectTerrainGlobal below it, even if empty. Now, for the future, when we'll move to Landscape, there won't be a GeodeticPivot in the scene any more, right? So the IG will detect the Landscape and auto-load the Geodetic plugin (or must I add it manually in the command line?) Is there a way to get the EPSG code of the landscape terrain back, from the IG or geodetic plugin? (so I can send it back to the simulator) When generating a Landscape, we set the projected EPSG code, but not the origin. so exactly what should go in geodetic_plugin->setProjectionEpsg(epsg, geodetic_origin)? If we try to use GDAL API on our side, we'll need to know the EPSG code or WKT for the current TerrainGlobal and GeodeticPivot. How do we get these? Thanks! Link to comment
silent Posted March 9, 2021 Share Posted March 9, 2021 Quote Now, for the future, when we'll move to Landscape, there won't be a GeodeticPivot in the scene any more, right? So the IG will detect the Landscape and auto-load the Geodetic plugin (or must I add it manually in the command line?) Yes, that's correct. Quote Is there a way to get the EPSG code of the landscape terrain back, from the IG or geodetic plugin? (so I can send it back to the simulator) You can do it by checking the variable assigned to the node: if (terrain->hasVariable("sandworm_epsg")) { epsg = terrain->getVariable("sandworm_epsg").getInt(); wkt2 = terrain->getVariable("sandworm_projection").getString(); geodetic_origin = terrain->getVariable("sandworm_origin").getDVec3(); } 1 How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
silent Posted March 9, 2021 Share Posted March 9, 2021 TerrainGlobal currently has no EPSG code assigned (only LandscapeTerrain have this). We plan to add it in the upcoming 2.14 update. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Recommended Posts