408
edits
FIAT G91R1B: Difference between revisions
Jump to navigation
Jump to search
→Philosophy of realization of the simulated model
No edit summary |
|||
| Line 33: | Line 33: | ||
The first two years of development were mainly used for collecting information material, drawings, manuals and testimonials from pilots. Then slowly we started by creating various parts, for example the first was the front landing gear, useful for learning some 3D modeling techniques and XML and JSBSim scripting. I personally think that a good model should always start from landing gear and not from the fuselage as many do. The reason is that the cart is a complex part that has a precise and easily measurable size. Its construction subsequently allows easy sizing of all the other parts. A mistake in this model was not to start initially with the cockpit and canopy as these parts are also critical in terms of size and constrain the correct sizing of the fuselage. The engine was also built in the early stages of the project using the original blue-prints, which made it possible to make the subsequent construction of the rear section easier. | The first two years of development were mainly used for collecting information material, drawings, manuals and testimonials from pilots. Then slowly we started by creating various parts, for example the first was the front landing gear, useful for learning some 3D modeling techniques and XML and JSBSim scripting. I personally think that a good model should always start from landing gear and not from the fuselage as many do. The reason is that the cart is a complex part that has a precise and easily measurable size. Its construction subsequently allows easy sizing of all the other parts. A mistake in this model was not to start initially with the cockpit and canopy as these parts are also critical in terms of size and constrain the correct sizing of the fuselage. The engine was also built in the early stages of the project using the original blue-prints, which made it possible to make the subsequent construction of the rear section easier. | ||
From the beginning the JSBSim program was used for FDM, this allowed us to obtain a high dynamic fidelity, but also reduce the need to use NASAL for many system functions. In the development it was verified that JSBSim is much more productive than NASAL especially for the parts that operate in real-time regime. The reason is mainly due to the poor documentation of NASAL and to its lack of adequate debugging support. JSBSim is a functional 'data driven' language written in XML that makes it more difficult to make errors of a logical nature and this was an important aspect of realizing good code. | From the beginning the JSBSim program was used for FDM, this allowed us to obtain a high dynamic fidelity, but also reduce the need to use NASAL for many system functions. In the development it was verified that [[Howto_talk:Methods_to_replace_the_NASAL_code_with_JSBSim_code|JSBSim is much more productive than NASAL]] especially for the parts that operate in real-time regime. The reason is mainly due to the poor documentation of NASAL and to its lack of adequate debugging support. JSBSim is a functional 'data driven' language written in XML that makes it more difficult to make errors of a logical nature and this was an important aspect of realizing good code. | ||
I believe that this project can teach a lot to those who want to try and build high-fidelity aircraft. I think it is useful to list some points that may be useful for other authors: | I believe that this project can teach a lot to those who want to try and build high-fidelity aircraft. I think it is useful to list some points that may be useful for other authors: | ||
* Using dense polygons we do not believe that it is a crime and does not produce a real slowdown of the PC on which the aircraft is run. But it has the result of obtaining a pleasant and realistic aircraft both externally and internally. The G.91R1/B has more than 3 million polygons and always flies rather well on machines of the current generation (2019). Obviously it is not a plane to fly with PC 10 years ago with I3 and Intel GPU with 2GB of RAM, although many pilots have told us that it still flies even in these low configurations. | * Using dense polygons we do not believe that it is a crime and does not produce a real slowdown of the PC on which the aircraft is run. But it has the result of obtaining a pleasant and realistic aircraft both externally and internally. The G.91R1/B has more than 3 million polygons and always flies rather well on machines of the current generation (2019). Obviously it is not a plane to fly with PC 10 years ago with I3 and Intel GPU with 2GB of RAM, although many pilots have told us that it still flies even in these low configurations. | ||
* | * [[Howto:Methods_to_replace_the_dial_gauge_bit_mapped_texture_with_vectorial_objects|A characteristic of the gauge produced for this aircraft is to be full 3D]] both in the 3D model,there is no 2D gauge, and in the characters and colored parts printed on the front of the gauge. This approach has been adopted in order to avoid the use of many 1024x1024 maps for the graduated scales of the gauges (I remember that the model was designed for 4K videos) used previously that led to an unsustainable slowdown in performance and even to failure of the FGFS program for PCs with 2 GB GPUs (For example, the GPUs integrated in the Intel I5-I7). The complete vectorization of the graduated gauges has completely solved the problem and allows the use of the aircraft even on relatively small machines The complete vectorization of the graduated gauges has completely solved the problem and allows the use of the aircraft even for relatively small machines, obviously with more contained performances (6-7 fps obtained, for example, in I5 machines built in 2010). | ||
* The plane was designed to be used with a 4K monitor and therefore the cockpit needed to have a resolution of 1/10 mm in order to make each instrument readable even in the most complete view of all the instruments (CTRL-V ). This choice was used noting that in many FGFS planes, made with lower resolution analogue gauges, they make the reading of the cockpit gauges especially difficult in the overall views. A characteristic of this model is precisely that of having an easy reading of all the gauges, exactly as it happens in reality. | |||
* Unfortunately, the extensive use of vector coloring does not seem to allow the correct use of Rembrandt, while for Compositor some tests have been made that appear to be promising, even though Compositor is still in development. | * Unfortunately, the extensive use of vector coloring does not seem to allow the correct use of Rembrandt, while for Compositor some tests have been made that appear to be promising, even though Compositor is still in development. | ||
* The GUI is currently made without the use of canvases, the reason is due to the fact that writing a GUI in canvas requires a lot more work than it does in XML, maybe in the future someone will do it, even if I suggest creating a framework that is more consistent and better documented for GUI in canvas, perhaps directly using the XML and not the NASAL script language. | * The GUI is currently made without the use of canvases, the reason is due to the fact that writing a GUI in canvas requires a lot more work than it does in XML, maybe in the future someone will do it, even if I suggest creating a framework that is more consistent and better documented for GUI in canvas, perhaps directly using the XML and not the NASAL script language. | ||
* The Documentation folder has been created in various parts, both in the direcory root of the project and in the individual parts. This allows anyone to take the files used and modify them and access the documentation files used. This procedure is unfortunately rare in FGFS and makes it even more difficult to update an aircraft. | * The Documentation folder has been created in various parts, both in the direcory root of the project and in the individual parts. This allows anyone to take the files used and modify them and access the documentation files used. This procedure is unfortunately rare in FGFS and makes it even more difficult to update an aircraft. | ||
* The 3D models were made in Blender for the parts with double curvature (fuselage, canopy, tanks etc ..), while Freecad was used for the parts for which the use of CAD is convenient, and for example the inside of the cockpit and some specific objects. In documentation there are all the CAD parts in Freecad format in order to be able to modify them by anyone who wants to do it. | * The 3D models were made in Blender for the parts with double curvature (fuselage, canopy, tanks etc ..), while Freecad was used for the parts for which the use of CAD is convenient, and for example the inside of the cockpit and some specific objects. In documentation there are all the CAD parts in Freecad format in order to be able to modify them by anyone who wants to do it. | ||