Unreal Engine 5.1 Airplane starts underground
johndcollins opened this issue · 27 comments
I'm submitting a ...
- [x ] bug report
- feature request
- support request => Please do not submit support request here, see note at the top of this template.
Describe the issue
When starting the game the aircraft starts halfway underground
What is the current behavior?
What is the expected behavior?
Aircraft starts above ground.
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Other information
Can you confirm if you edited or changed any settings in the default project or settings?
For example did you load a different flight model, other than the 787?
If you can attach the UE5 log or paste the relevant snippet of it. As well as the flight debug info, press the D key to bring up the debug info.
I haven't updated my own UE5 to 5.1 yet, I will confirm later if once I update to 5.1 if I find any obvious bugs or not.
Nothing was edited or changed.
I'm not sure what log entries you're looking for:
LogJSBSim: Display: UJSBSimMovementComponent::LoadAircraft 787-8
LogJSBSim: Display: Initializing JSBSimFlightDynamicsModel using Data in 'F:/Games/Projects/jsbsim-master/UnrealEngine/Plugins/JSBSimFlightDynamicsModel/Resources/JSBSim'
LogJSBSim: Display: Model 787-8 Loaded successfully !
LogJSBSim: Display: PrepareJSBSim - Setting Initial Conditiond and computing initial state
LogJSBSim: Display: Trim Complete
I updated to UE5.1 and can confirm this bug exists in the default reference project. It's likely some issues with the Geo plugin or UE world coordinates, as UE5.1 includes updates such as:
Large World Coordinates World Max Increase: New for this release, we raised the default world extents from 22 km to 88,000,000 km, allowing for much larger worlds to be created.
Not sure if that's exactly related but either way something broke related to ground/position/coordinate values. Should be an easy fix if it's just some single float values that need to be changes as doubles in the plugin.
But I won't be able to investigate/check for a few days.
Thanks!
Looking forward to see what the fix is.
Greetings! I just wanted to chime in that I too am experiencing this on a fresh clone of JSBSim with Unreal 5.1. The project works as expected in 5.0 but with 5.1, the result is variously (depending on how I have set up the aircraft and/or the georef plugin):
- The aircraft starts underground
- Getting NaN values when attempting to work out the ground level (which then affects subsequent Matrix operations)
- The aircraft reporting it is/has crashed
I am happy to try to reproduce or try out solutions if any of you would find that helpful.
Please find attached the result of a Play in Editor session (Standalone). A screenshot (not very interesting) and the Saved log file.
I can see from the image posted by @johndcollins that the landing gear are not getting terrain information. The WOW (Weight On Wheels) should be 1. It seems something else, perhaps the fuselage contact points, are keeping the model from sinking fully into the Earth. The height AGL is about four inches in that image. In JSBSim height AGL is the distance from the ground elevation to the aircraft CG.
The aircraft starts underground, it doesn't sink into the ground.
I've spent a little time trying to debug and find where the issue is. I couldn't find the root cause but here's my work around to at least take-off from the ground in UE5.1: First I had to manually add collision to the terrain/runway meshes. Open the mesh and add collision box mesh is easiest way, while also changing the collision settings to "Use Simple as Complex".
I'm not sure right now if my project update to UE5.1 "lost" the collision for those terrain/runway meshes, or it applies to everyone who uses the reference JSBSim plugin project with UE5.1. It might also simply be a change in the way UE5.1 returns collision queries compared to UE5.
Regardless, even with collision meshes added, the 787-8 still starts below ground level. So the work around for that is to set Start on Ground to false in BP Airliner in the Details of the editor.
For some smaller aircraft, seems you can still use Start on Ground.
@AlbanBERGERET-Epic After the holidays would you have any time to help look at this UE5.1 JSBSim ground issue?
If Start on Ground is not working, I'd investigate the computations in UJSBSimMovementComponent::GetAGLevel which is the method that returns the ground height below each landing gear (i.e. <contact> in JSBSim XML model files). We've had similar issues with FlightGear and in some cases the problem was due to a bug in the class inheriting from FGGroundCallback.
The other root cause could be that JSBSim method FGTrim::trimOnGround() fails to find a stable position on ground. In that case the work around would be to drop the aircraft from a few feet above the ground (i.e. spawn the aircraft a few feet above the ground) and check that the ground reactions are correctly handled at the landing gears (i.e. the aircraft does not fall through the ground). I guess you'd need to disable mesh collision for this test as I'd anticipate that it could prevent gear compression.
Hello guys,
I'm just back from the holiday break and see this thread.
Well, it seems to be a weird issue.
From the top of my head, the collision system and the georeferencing plugin should not have changed. But some threshold variables might have changed with the latest LWC updates.
That's interesting to know the actual reason. I'll try to allocate some debugging time and keep you posted.
Hi there,
Quick update.
The screen was black because the FGGroundCallback trace lines did not touch anything, and the trim fails. JSBSim is not to blame, it is just that combined with the georeferencing system, we receive a Nan location...
The issue is that the large triangles from the runway and terrain don't end up in the complex collision shapes we query against in the FGroundCallback, so we hit nothing! What is strange is that the smallest parts like marking are in. That could explain why depending on your location, you might have the gears working on the marking...
@gallonmate workaround is correct so far, as it adds a box in the complex collision data. And on my project, freshly converted to 5.1, the aircraft drives correctly on the runway without sinking.
My current bet is something related to the triangle sizes, or maybe to the geometry asset itself. I opened a conversation with the physic team, and will let you know when we find a reason. But this is clearly a regression that needs to be understood.
Hi,
Thanks for reporting this problem. Indeed, there was a regression in 5.1. Some optimizations in the way we created the BHV for physics meshes skipped the large triangles during the queries.
The good news is that we just fixed this issue in the engine following this report. It will make it for the 5.1.1 hotfix release that will be released in a few weeks.
If you can't wait until then, you can use the "simple mesh" workaround, or use a source code build from GitHub. Make sure you select the 5.1 branch and wait for some hours from now for the GitHub repo to be synched with our internal repo. The fix is in CL#23599716.
@bcoconni I don't know if you want to Close that bug or keep it in an Open state until the 5.1.1 version is released.
@AlbanBERGERET-Epic Great news that you found and fixed the bug! Thanks for looking into this and happy new year!
@johndcollins can you or anyone else confirm if Start on Ground works with the 787-8 with the Simple Collision work around? Because I still have the Start on Ground issue with the 787-8, where the plane is started half way into the ground. It would be good know if the 787-8 with Start on Ground bug is just for me or applies to others as well.
@gallonmate it works fine on my machine, just using the latest GitHub version.
What could explain the behavior your are facing is that the simple collision shape is not aligned with your runway geometry. Make sure you have the right definition in Collision/Primitives/Boxes.
I can reproduce the sinking plane effect if I alter the center location of the collision box.
@AlbanBERGERET-Epic I see what you mean, with the default reference project fresh from Github, it appears as if the 787-8, starts on ground but it actually doesn't, it just spawns close to the ground. If you position the BP Airpliner, further from the ground, you can see that Start on Ground does not function for the 787-8 when using the runway mesh.
If you switch to something like F15 or c172p aircraft, the plane Starts on Ground. But more interesting if you move the 787-8 airplane over onto the terrain or above another generic mesh with good collision, 787-8 with Start on Ground places the airplane half-way sunk into the ground/mesh, unable to fly.
@bcoconni I don't know if you want to Close that bug or keep it in an Open state until the 5.1.1 version is released.
Hi @AlbanBERGERET-Epic, I'd rather keep this ticket open until the underlying issue is fixed in UE. At the very least this discussion is documenting that the problem is currently being taken care of.
I just did a quick test of rebuilding the plugin with the 5.1.1 version which was released recently, and this issue doesn't occur anymore.
Is it also OK on your side? If yes, I think this issue can be closed...
The collision generation appears to be fixed in UE5.1.1 but the Start on Ground function is still broken for the 787-8, which I mentioned in my previous comments. Move the aircraft forward or anywhere else from it's default location and this is the result:
Before play:
After start play:
I have not had time to debug or investigate why it's happening.
Hello,
Any news on this? I'm fine with runway but when the airplane is on air for few seconds, I got some NAN values in GetAGLevel which crashes the airplane instantly. Anyway to fix it?
I tried to hardcode a value of 10000 in GetAGLevel (GroundCheck and MovementComponent) and it allows me to get a bit more in air. But after more seconds, I get ghost collisions and new NAN values.
Hi @bcoconni
I had a quick look at it this afternoon, and I might have an idea. The GetAGLevel in the ground callback seems to query altitudes from points that are already some meters below the ground surface. I'm not 100% sure of when, because this callback is called often, but it seems to be happening during the Trim phase.
If the trim does an iterative approach, it could be understandable. But why was it working before? Did something change there to bring more stability or trim success?
Anyway, if inside the callback I raise the height of the raycast query start point, it does pick the terrain, returns the expected signed HAT, and it works.
FVector LineCheckStart = StartEngineLocation + 1000 * Up; // issue #786 - start 10m above the input point to be sure to hit the ground.
But before submitting a fix, I wanted to be sure of this Query behavior, because I ran several times into similar problems in my life, especially when you want to do ground clamping on vehicles that are supposed to be able to go under a bridge or inside a tunnel. (Ok, I admit that aircrafts are not supposed to do this kind of stunt).
Is it OK if when considering the input point location I raise the start point altitude, or it could have side effects?
Bonus question : Is this margin somewhere defined in JSBSim so that I can use the same threshold as you?
Alban
I am currently stuck with the same issue. UE crashes when the aircraft is placed on the cesium generated terrain. Works fine on the runway mesh.
I had a quick look at it this afternoon, and I might have an idea. The GetAGLevel in the ground callback seems to query altitudes from points that are already some meters below the ground surface.
The aircraft altitude is measured from the aircraft CG which is located approximately at the same waterline than the wings. So when the aircraft spawns at an altitude of 0ft, its belly and landing gears are in most cases located below the ground indeed.
I'm not 100% sure of when, because this callback is called often, but it seems to be happening during the Trim phase. If the trim does an iterative approach, it could be understandable. But why was it working before? Did something change there to bring more stability or trim success?
The last modifications that have been made to src/initialization/FGTrim.* and src/input_output/FGGroundCallback.* are related to the PR #644 which allowed to build JSBSim as a DLL. Before that the code has remained unchanged since the Summer 2020. So I'd say it's unlikely that the issue is linked to a modification in JSBSim trim code or ground callback.
Anyway, if inside the callback I raise the height of the raycast query start point, it does pick the terrain, returns the expected signed HAT, and it works.
FVector LineCheckStart = StartEngineLocation + 1000 * Up; // issue #786 - start 10m above the input point to be sure to hit the ground.But before submitting a fix, I wanted to be sure of this Query behavior, because I ran several times into similar problems in my life, especially when you want to do ground clamping on vehicles that are supposed to be able to go under a bridge or inside a tunnel. (Ok, I admit that aircrafts are not supposed to do this kind of stunt).
Well, I wouldn't say that users will never try to fly under bridges 😆 But I guess that for a start your fix makes sense. If someone complains later on that they couldn't fly below brides, we'll advise.
Is it OK if when considering the input point location I raise the start point altitude, or it could have side effects? Bonus question : Is this margin somewhere defined in JSBSim so that I can use the same threshold as you?
Not sure what threshold you're talking about. In JSBSim landing gears and more generally contact points are always assumed to be at the ground level when a contact is detected and gears legs are assumed to adapt their length (i.e. compression) instantaneously. But this choice has some undesired side effects as is exposed in discussion #819 so we might revisit the current design at some point.
Just added a PR To fix that issue...
Just added a PR To fix that issue...
Thanks @AlbanBERGERET-Epic 👍 I suggest we wait for people who have reported the bug to confirm that your PR has fixed the problem to close this issue.
Everything appears works. Nice fix Alban!
I suggest closing the issue.
Everything appears works. Nice fix Alban! I suggest closing the issue.
Great! Thanks everyone for having reported the bug, submitted fixes and conducted tests.
This issue is closed.