It would be nice to be able to see it from different angles, as in the case of vintage aircraft.
I understand that the flight dynamics are made as simple as possible. The simplifications are mostly appropriate. But maybe it makes sense to replace the vertical speed control with the height control? After scrolling the mouse wheel, the helicopter makes a transition to a new height, after which it stops without the player’s actions. Now, as I understand it, the mouse wheel sets the vertical speed value. This logic makes it difficult to stabilize the altitude.
Also, I think it would be better to remove the influence of the mouse on the heading angle. If each input has its own isolated output, control will become even easier.
Press the “I” (information) key and all your questions will be answered.
The first screen notes that you can also control the helicopter with the keyboard. You can use the arrow keys instead of the mouse.
The next screen describes all the keys you can press for different views. To pan around the aircraft, hold down the shift key and use the mouse.
Because the range of motion for a helicopter is so limited (no loops or rolls), the mouse directly controls the pitch and bank angles. It sounds like it would be helpful if you could adjust the sensitivity. One feature that may make things seem odd is that the Huey has a rotor that pitches and banks about 15 degrees before the fuselage starts pitching or banking. This is known as a “teetering” prop and is how a helicopter is able to start moving from zero airspeed. Because of a helicopter has a natural tendency to oscillate, I removed all delays.
I was not able to use the same method for altitude because the altitude range is so large that you would have worn out the mousewheel trying to dial in the right altitude. Here, the mousewheel inputs a change in speed (up to a max) so that there is a little bit of a delay and it may continue moving up or down after you have stopped moving the mouse. Would it help if I added a routine that would cause the change in altitude to settle down to zero (the same way an airplane tends to return to wings level after you release the controls)?
Essentially, the controls work like those on a real helicopter. The mouse is like the “cyclic” which functions like a joystick and controls direction and speed. The mousewheel is like the “collective and throttle” which are on a handle that is pulled up and down and are used to control altitude. The cyclic is very sensitive. The collective and throttle are less sensitive.
Let me know if the keys work better for you. And don’t forget to press “s” to get that helicopter sound!
It looks great!
As always, I started the game without reading the instructions
I agree with the presence of some degree of realism in the existing player input.
My comment about the separation of roll and yaw should be attributed to the category of subjective preferences. Of course, this will not add realism to the game. But I think it would be nice for an extremely simple game. I would explain my idea with a diagram.
The change I proposed would be strictly correct if it improved one parameter, at least without making the other worse (inside ABC). Of course, it is impossible to say this objectively.
I think it depends a lot on the user’s mouse itself. I like the keys better, even though the difference is small.
The issue of height control is not so obvious. I will try to give a detailed comment soon.
Let’s look at the height control from the side of realism.
Here it is important to separate the special modes. I would put two areas in this category:
Low altitudes with a surface effect.
High altitudes with the exhaustion of the helicopter’s ability to climb further.
Let’s leave aside the great heights for now. How does the control work near the surface? The position of the “collective and throttle” handle corresponds to a certain hover height. If you slightly reduce the position of the handle, the vehicle will move down and set the hover in the new position.
Of course, the physical process takes place with smooth velocity and acceleration curves. The exact transition process is quite complex. However, the position of the mouse wheel sets the final height directly. It is not difficult to write algorithms for smooth movements between the set values.
This is exactly how it happens. And this is most noticeable near the surface. The mouse wheel differs from the joystick in the absence of position feedback.
I think that it is better to create a special mode for flying near the surface. This should benefit both simplicity and realism. But this, as in the case of my previous post, is nothing more than a subjective opinion
For altitude control, I think what you are suggesting is something like an autopilot. You dial in the altitude you want and the helicopter goes there. I considered using that approach and, you are right, it would probably help with hovering or flying just above the ground - which helicopter pilots seem to enjoy doing.
The flight model could definitely use improvement. It does not currently model loss of lift as air density decreases - which would automatically limit the altitude of the helicopter. It does not model ground effect, which decreases the left required a few feet about the ground. It does not model transitional lift - the increase in lift which results when the helicopter reaches a forward speed of around 15 mph. And it does not fully model the decrease in power required to maintain lift at middle speeds. I should be able to make all of these improvements without making the controls more complicated.
The mouse control gives you 360 degree control over the direction you want to move laterally. However, this changes as speed increases because of the effect of weather-vaning, which is modeled in the simulation. As speed increases in any direction, the helicopter tends to turn and align with the direction of flight. At higher speeds, the controls behave like those on an aircraft. Moving the mouse left and right does not cause the helicopter to “strafe” sideways, but results in a curving turn.
Regarding controls in general, I generally prefer to assume that my pilot persona will automatically handle all the details. I am in the position of telling him where to fly and he handles all the details.
There is a common belief among some (not you, obviously) that more complexity is good because it means more reality. However, such tasks are often not fun for real pilots. And no simulation - however complex - will replicate the effect of turbulence or high-g turns - which can make even simple tasks almost impossible. Instead, I try to make things simple and add to the complexity only if it adds to the story.
If you think it will help, I will change altitude control to act more like an autopilot and we can see if that is an improvement.
Perhaps as part of the autopilot, I could add a limiter that would prevent you from descending below a certain level if your speed is above a certain amount? That would help avoid the need to stare at the altimeter or altitude setter, when you should be enjoying the view.
Of course, this would have limitations. For example, it would not stop you from flying into elevated terrain. But that is why the user is supposed to be watching the view - to prevent that from happening.
Perhaps you can consider this as a special autopilot mode. But in reality, this is the most realistic model of behavior. Any other model of hovering near the surface is less realistic.
Approximately, I suggested just that. To be more precise, the height “dial” tool is “collective and throttle”.
Each position of the handle corresponds to its own height of steady hovering.
The higher the value, the higher the height. In the roughest version, you can make a linear model.
A more subtle implementation is based on the parabolic approximation.
Here I am talking about the ground effect. The proposed behavior of the helicopter is explained by the simplest description of this effect. https://en.wikipedia.org/wiki/Ground_effect_(aerodynamics)
An important detail should be added to the explanation from Wikipedia and your phrase about reducing the required left.
The additional thrust, as well as the reduction of the required left, is not a constant.
Its value depends on the height of the hover. At zero height, the effect is shown as much as possible. At a height equal to 1.5 main rotor diameters, the effect disappears completely. Between these heights, the effect increases as you get closer to the ground.
Here we will achieve two things at the same time. Realistic and simple. Move up and to the right on the chart
I think your height control logic should not change for heights greater than 1.5 main rotor diameters. It should also work the same way at lower altitudes at higher horizontal speeds, when the ground effect disappears.
This decision is a step towards an arcade game. You can’t tell if it’s better or worse. You can definitely say that this would be less realistic, but more easy. Which of the two factors is stronger is a matter of personal preference. Someone likes to play platformers, and someone likes hardcore 3D shooters.
I think you need some concept of realism, a definition of the target audience. A good solution is to create two models. Then you don’t have to worry about finding a balance. One model will be very easy to play. By choosing this model, the user can enjoy the beauty of flight without training. The second model will be for aviation enthusiasts. It will have the maximum level of realism.
The latest version of the FM2 simulation is now working, with animated waves computed using the iFFT method. I am getting 60 fps. But, if others are not, I can crank down some of the settings.
The nearest grids use both a normal map and displacement map. The farthest grids use only a normal map. As you can see, the transition between the two seems fairly seamless.
Now that this seems to be working, I plan to try to break the program into modules and to add an AI opponent.
ADDITION
The simulation has been updated to r152 and incorporates the new ColorManagement changes which are supposed to improve colors and shading. (You may have to hit “reload” to see it.) To compare, here is the old r150 version. I believe r152 a vast improvement since the waves now appear sharper and even more detailed.
EDIT
The increased level of detail also caused a reappearance of the tiling issue. So I have doubled the size of the grids. It still looks sharper and more detailed than the r150 version.
Here is a side-by-side comparison of waves generated in the Dunkirk movie and waves generated in three.js using the modified Li-Albert-Bouny iFFT Wave Generator.
The wave generator is exactly what i need. I have the whole earth in its original size and I can get the landmasses very well with the NASA maps. But I was still missing something for the oceans.
Thanks for pointing this out. If you press “I”, you can see a full list of key commands.
You mostly use the mouse to fly (what may be causing confusion is that you roll the mouse down to pitch up). My normal takeoff procedure is to:
roll the mouse wheel to increase power;
hit “V” for outside view
around 120, roll the mouse down to take off and roll left to bank left (which is about where that picture was taken).
I generally fly out to the carrier or try to form up with the plane that is circling the field.
Let me know if this is not working.
Here is a webpage that discusses different methods of creating ocean waves. The iFFT method is discussed near the bottom. There is a link to a CodePen that contains the entire revised Ocean code. The Ocean subroutine creates a displacement map and a normal map that you can use with three.js textures. It works well within a certain range, but could be significantly improved with the addition of cascading - which prevents tiling.
It has touch inputs.
Just to check, I tried running the program on my “world’s oldest MS Surface” (6 fps). The regular -/= keys work and you can use the touchpad to fly (scroll down to climb). I have only tested the program on Chrome so far.
If it helps, here is a version of the FM2 Flight Demo that uses a simple non-animated texture for the ocean.
Let me know if none of these work.
I can change “CoefLift” by scrolling up/down, but as long as the plane has 0 speed and -/= do nothing, I can’t take off.
edit: this was all in FF, I tried in Chrome and I think the scroll worked differently as the plane moved. but I eventually drove off the runway into the water any way.
If your = key is not on auto-repeat, you may have to keep hitting it until you get full throttle. On the display on the upper left, you should see the throttle value increase from 0.00 to a maximum of 1.00.
It looks like I’ll have to see how FF handles keyboard inputs. I am using:
// Keyboard - Down
function onDocumentKeyDown(event) {
let keyCode = event.which;
***
// Engine More
if (event.keyCode == K_EngM) InpPwr = 0.01;
// Engine Less
if (event.keyCode == K_EngL) InpPwr = -0.01;
***
}
There have been several major developments relating to my collection of flight simulation programs.
First, I have moved my main components of my collection to a GitHub repository. This means that everyone now has access to the latest version of my programs and resources, including the Flight and Ocean modules. You can [1] visit the collection and view and download the latest source code; [2] run the programs from your browser, as explained in the ReadMe file; [3] download and modify the programs and run them locally without CORS problems; [4] create your own programs that can run locally using the resources without CORS problems. Also I no longer have to worry about trying to update my webpage to make the latest versions of these programs and modules available for download.
Second, the Ocean module has been significantly improved with the use of nodes and the addition of large-scale textures that modify the color and reflectivity of the ocean surface. This may be the epitome of the WebGL2 version of the Ocean module because Nodes no longer works with WebGL2. We are able to make the module work, only by using a legacy file from r163 (not recommended). Converting to a WebGPU version may take a few months. In the meantime, you can enjoy the programs showcasing Blender models of the FM2 and B29 airplanes. Both use the WebGL2 Ocean module and include some wispy clouds created using sprites.
Third, the collection now includes a simple program (fdem_ez.html) which contains a small version of the Flight module. You can use the mouse controls to fly the airplane (with some effort) and you can activate the autopilot which allows you to use the arrow keys to change pitch and bank. This allows you to more precisely explore the performance envelope of a real airplane. It also as a cockpit view with animated flight instruments. This program is intended as the final illustration in a series (in process) showing how the Flight module simulates real flight.
Finally, both flight simulation demos (FM2 and Pup) appear to be working fairly well. There are some small problems, but the basics seem solid (although I think there is still a problem with landing the FM2 on the carrier).
I want to thank all the people who have helped and encouraged me through this years-long process, including Attila Schroeder (Ocean module), Witold Jaworski (Blender aircraft models), prisoner849 (3d animation guru) and many, many others.
I am still maintaining my Aviation webpage and will continue to use it to discuss and explain the programs and modules in more detail.
the only control that worked for me was SPACE (it played ratatatata sound)