Board index FlightGear Development New features

It would be nice to have smooth translations and rotations

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

It would be nice to have smooth translations and rotations

Postby abassign » Mon Jul 09, 2018 6:38 pm

This is the example of some animations that I get with the G91R1B overflow, as you can see the hand of the volmeter (bottom right) and that of the fuel level (close to the blue light), are instantaneous, but in reality it is not. I tried inserting a NASAL code for the yellow handle at the top, the effect is much more real, but it costs a lot NASAL code and complex to implement.



would be nice to be able to introduce smooth translations and rotations in XML animation by a table that defines in addition to the position also a second column with the rate of variation, plus a parameter that indicates whether the variation must start and end with an aceleration / deceleration or not. This must work for both linear displacement and rotation.
What do you think ?
abassign
 
Posts: 725
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: It would be nice to have smooth translations and rotatio

Postby Richard » Mon Jul 09, 2018 7:22 pm

Generally[1] this should be in your systems model; there should be a "voltage" and a "displayed voltage"; the displayed voltage can simply use a lag controller (jsbsim systems) to simulate the gauge.

I can see why it looks attractive to do this in the animation itself; however that does increase the complexity of the animations, and again[1] it's not really the right place to do this.

Personally I don't think that the handles actually need to animate at all much; I did some of the handles / buttons in the F-15 using a mouse drag (slider) rather than a click animation; simply because this felt more realistic to me.

-----------
[1] and IMHO of course
Richard
 
Posts: 601
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: It would be nice to have smooth translations and rotatio

Postby Thorsten » Tue Jul 10, 2018 5:04 am

Agreed with Richard - it doesn't make sense to have this animation-side because it really is something that is happening systems-side.

That also gives you a lot of flexibility given the various property rules etc. we have available.

It is generically true that complex motions require a lot of complexity (and nothing you do will change that), but since we can run Nasal or systems 'as needed' but have to run animations pretty much unconditionally, it is also more efficient to model in systems.
Thorsten
 
Posts: 9803
Joined: Mon Nov 02, 2009 8:33 am

Re: It would be nice to have smooth translations and rotatio

Postby abassign » Tue Jul 10, 2018 7:08 pm

Honestly for the voltmeter the use of a filter is certainly the best solution, even if this increases the load of the system in just as JSBSim works at 120 Hz. But for the various doors of the plane, the handles, or everything that is activated manually, and as you can see, currently for the G91R1B are several parts (I think at the end of the project will be a few tens), for each of them insert the NASAL code is really hard for the programer, generates a code that is difficult to maintain and with heavy message handling.



My idea could be simpler, using something like the landing gear or the flaps. It would be enough to have a ramp generator that is activated by an event, generator that could have 3-4 parameters:

    Value one
    Value two
    Duration

    + another couple of parameters:
    Ramp value one-> two or ramp value one-> two-> one
    cyclical with the number that defines the number of seconds between one cycle and the next

This ramp generator could be an animation XML command. It would also be very useful for other things, such as making intermittent lights, sounds etc ...
Excuse my utter lack of joy in using the NASAL to do these things, but I find the FGFS XML (like the JSBSim XML), but I find the FGFS XML (like the JSBSim XML), very elegant and practical solutions that make FGFS very interesting for developing good aircrafts and maintaining them over time.
abassign
 
Posts: 725
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: It would be nice to have smooth translations and rotatio

Postby Richard » Wed Jul 11, 2018 1:10 am

abassign wrote in Tue Jul 10, 2018 7:08 pm:...increases the load of the system in just as JSBSim works at 120 Hz.

But for the various doors of the plane, the handles, or everything that is activated manually, and as you can see, currently for the G91R1B are several parts (I think at the end of the project will be a few tens), for each of them


There isn't a problem with performance of systems in JSBSim as you can specify that JSBSim systems run at a slower rate using the execrate attribute on your system (i.e. <system execrate="4">); execrate of 4 means to run every 4th frame (120/4 = 30hz).

Personally I think it's wrong to add this sort of thing into the animations, it's just the wrong place.

- It adds complexity to the code. The animations work well and have an elegant design in the way they are responding to property changes.
- To change the animations to have to be called each frame to ramp values is going to add another layer that is doing exactly the same thing as the autopilot, JSBSim systems.
- simulation code should be inside the JSBSim model
- there will be situations where you need to control fully the property, for example if something is powered by hydraulics and you run out of hydraulic pressure, with a simple ramp animation the element would keep moving. This is why it all belongs in the JSBSim system.

I'm still recommending[1] that you do all of this, doors, gears, needles, in a JSBSim system; I changed the F-15 canopy from Nasal to a JSBSim kinematic and it was just much nicer and easier to work with.

--------------------------------
[1] I generally do not recommend using Nasal for simulation logic; and even display needle position is simulation logic as far as I'm concerned. The only thing that I'd probably still do in Nasal is the master caution logic as that's very tedious in a JSBSim system - but it can be done.
Richard
 
Posts: 601
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: It would be nice to have smooth translations and rotatio

Postby abassign » Wed Jul 11, 2018 6:45 am

Richard wrote in Wed Jul 11, 2018 1:10 am:
There isn't a problem with performance of systems in JSBSim as you can specify that JSBSim systems run at a slower rate using the execrate attribute on your system (i.e. <system execrate="4">); execrate of 4 means to run every 4th frame (120/4 = 30hz).


In Italy they say: "Wallpapers An open door" or: I would also avoid using NASAL to solve the problems of animation!

Flightgear has three official programming languages: JSBSim, property tree XML, NASAL ! They are obviously too many and not only, but almost all of them are executed on one thread.
Therefore, to be able to conveniently use the JSBSim for all the functions of animation I think it would be the best solution ever! Relegating the property-Tree XML only to the role of interface to graphic objects in full MVC logic.
I worked in the creation of a simulation language as a university thesis (about 1985 with technologies now no longer in use, I used the APL as a programming language) and I therefore know the logic of such programs, which seems to me to be respected by the engine too jsbsim.

Currently our FIAT G91R1B uses JSBSim for many functions, such as fuel systems and level management, switching from external to internal tanks in the aircraft logic. It uses JSBSim for the hydraulic system and simulation of its default and reduction in flow according to engine speed. JSBSim I'm inserting it for the management of the opening of the airbrake according to the hydraulic system pressure and the aerodynamic drag. I am currently implementing the electrical part with over 150 values to follow the G91 wiring diagram quite accurately.

My perplexity concerns the question: how much can I use JSBSim to manage the aircraft's systems, in addition to its primary task of managing the position in space?

Theoretically, since JSBSim is an algorithmically complete programming language, I can theoretically do everything and completely replace NASAL! I would do this right away, but JSBSim works in the main program thread and this means that if I load it too much it immediately has a frame-rate slowdown.

Using the execrate switch for individual channels (I think it's a channel switch http://wiki.flightgear.org/JSBSim_Systems) is very interesting, but it does not solve the problem that a more important use of JSBSim has a cost that for complex aircraft like our G91R1B (I do not speak of your F15 and Su15!) could become very high.

I looked quickly at the JSBsim code and noticed that it would not be difficult to move, on a different thread, the heaviest processing part that is executed in FGFDMExec exactly in the Run () section.

Code: Select all
 {
   bool success=true;
   Debug(2);
   for (unsigned int i=1; i<ChildFDMList.size(); i++) {
     ChildFDMList[i]->AssignState( (FGPropagate*)Models[ePropagate] ); // Transfer state to the child FDM
     ChildFDMList[i]->Run();
   }
   IncrTime();
   // returns true if success, false if complete
   if (Script != 0 && !IntegrationSuspended()) success = Script->RunScript();
   for (unsigned int i = 0; i < Models.size(); i++) {
     LoadInputs(i);
     Models[i]->Run(holding);
   }
   if (ResetMode) {
     unsigned int mode = ResetMode;
     ResetMode = 0;
     ResetToInitialConditions(mode);
   }
   if (Terminate) success = false;
   return success;
 }


This section is followed exactly here:

Code: Select all
for (unsigned int i = 1; i <ChildFDMList.size (); i ++) {
      ChildFDMList [i] -> AssignState ((FGPropagate *) Models [ePropagate]); // Transfer state to the child FDM
      ChildFDMList [i] -> Run ();
 }


If the logic of the JSBSim is similar to other continuous simulators (I should check...) this point activates the pseudo-parallel execution of the processes in order to define the vector of the outputs as a function of the vector of the values obtained in the previous cycle. My university thesis was really made in finding an algorithm to optimize this cycle according to the objects that really had to be calculated because an input state had been changed in the previous cycle.

However it would be interesting to be able to put this part in separate threads (I do not know if there are any side effects) so that you can fully exploit the current 2-8 core processors. I think this could be an interesting test to do and if possible, if successful, change the official JSBSim code by adding multithread management. So, in this case I do not think there will be problems using JSBSim for all the animations, and if this is possible we will have the chance to "throw away" the NASAL section in all our airplanes!
abassign
 
Posts: 725
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: It would be nice to have smooth translations and rotatio

Postby Thorsten » Wed Jul 11, 2018 7:06 am

They are obviously too many and not only, but almost all of them are executed on one thread.


They all have their function, so there's nothing 'obvious' here for me, but maybe you can discover that yourself.

Therefore, to be able to conveniently use the JSBSim for all the functions of animation I think it would be the best solution ever!


So what exactly are we discussing about then?

how much can I use JSBSim to manage the aircraft's systems, in addition to its primary task of managing the position in space?


A lot. You can manage a near feature-complete set of Space Shuttle systems with it.

The division of labour is simple:

- things you need to execute 'often' - JSBSim with the execrate set as needed
- Complex logic you need to execute 'once' (e.g. when flicking a switch) - Nasal
- Animations which are relevant during a certain time - JSBSim executed only when you need to run the channel.

Theoretically, since JSBSim is an algorithmically complete programming language, I can theoretically do everything and completely replace NASAL! I would do this right away, but JSBSim works in the main program thread and this means that if I load it too much it immediately has a frame-rate slowdown


Not if you make good use of the division of labour as above - clearly if you insist in doing complex logic evaluations at 120 Hz.

if successful, change the official JSBSim code by adding multithread management


Good luck...

(Just to recap - you're suggesting that because JSBSim *might* not be able to do your animations - which you can already run 'as needed' - wow!)
Thorsten
 
Posts: 9803
Joined: Mon Nov 02, 2009 8:33 am

Re: It would be nice to have smooth translations and rotatio

Postby Richard » Wed Jul 11, 2018 9:34 am

abassign wrote in Wed Jul 11, 2018 6:45 am:Flightgear has three official programming languages: JSBSim, property tree XML, NASAL ! They are obviously too many and not only, but almost all of them are executed on one thread.
...
However it would be interesting to be able to put this part in separate threads (I do not know if there are any side effects) ... do not think there will be problems using JSBSim for all the animations, and if this is possible we will have the chance to "throw away" the NASAL section in all our airplanes!


Probably you meant JSBSim, autopilot/property rules and NASAL. There is a potential small performance benefit from running on multiple threads, for the F-15 this would be a maximum of 6ms, but I am aware that the cockpit mesh could be improved to avoid state changes which would probably have a similar impact.

Before I get into what will be probably a long message about multi-threading the summary is yes, you certainly should move all Nasal code that you can into JSBsim systems. As Thorsten said Nasal is good at managing this, handling property listeners and gluing it all together as an event based system, but Nasal should not have the minimum amount of code that is run each frame, limited to logic that can't be done in JSBSim, Canvas updates etc. My F-15 has too much Nasal and I'm not citing the F-15 as an example of how to use Nasal.

Anyway, onto multi-threading. Yes, you're right there are side effects of multi-threading and it would require a lot of work to make FG multithreaded.

Multi-threading is something that seems like it should help, but it doesn't help as much as it should; primarily because you can't get more performance out of OpenGL or your GPU by using multiple threads. What we could get is around 10% of the total (for most aircraft).

It's been said before, but multi-threading in C++ is very hard to make stable, I know this because the SwiftIOS kernel has to handle multiple threads and processes and it took me a lot of time to make this stable, working with code that was designed to be multi-threaded. Even now it isn't 100% right as each process has to sit on a single CPU (CPU affinity) otherwise after a while it deadlocks. This is another case where using all of the multicore CPU doesn't make any real difference as SwiftIOS is more than fast enough as it is. Yeah it'd be nice to get it using all cores, but long term reliability is way more important than improving something that is frame locked at 20hz; it's no good if the sim had one lockup every 100hours as that impacts training.

I've done a lot of analysis and work on multithreading in FG; I've even had a prototype multithreaded version of FG[1] that uses two threads, one for the rendering and another for everything else. There is pretty much no point have more than one thread for everything else, as even at 120hz there is still idle time (for the F-15).

My F-15 has around 6ms of total non visual rendering time at a JSBSim frequency of 120hz; around 3ms of this is the total time for the JSBSim model; the rest is Nasal.

However most of the time in FG is taken up with the rendering. an extra 1 or 2ms isn't going to dramatically impact your frame rate. Trying to optimise the JSBSim systems time is rather like painting your coal cellar black; you could do it but actually it's not likely anyone will notice.

This is how the frame time breaks down for the F-15 on my system[2]

3d aircraft 11.44 ms
3d terrain 15.60 ms
Nasal 2.99 ms
JSBSim 3.10 ms

Total= 33.12ms
FPS= 30.19

A theoretically optimum multithreaded FG would give you

If you could make FG reliably multithreaded you'd get a maximum FPS boost of 6.8 for the F-15 (see below); which is good and ideally someone would be doing this; but if it makes FG less reliable those extra FPS don't matter a jot. Reliability is more important to FG (IMO) than performance. It's no fun to be 2 hours into a flight and have FG crash.

CPU0
3d aircraft 11.44 fps
3d terrain 15.60 fps

CPU1
Nasal 2.99 fps
JSBSim 3.10 fps

3d time (ms) 27.03 fps
FPS 36.99 fps
Increase 6.6 fps
--------------------------------------
[1] https://imgur.com/HC7NgqZ
[2] my system is R9-290, i7-4790K, 24gb ram.
Richard
 
Posts: 601
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: It would be nice to have smooth translations and rotatio

Postby abassign » Wed Jul 11, 2018 10:53 am

Richard wrote in Wed Jul 11, 2018 9:34 am:
3d aircraft 11.44 ms
3d terrain 15.60 ms
Nasal 2.99 ms
JSBSim 3.10 ms


At this point I would say that you are encouraging me to continue working on the replacement of the NASAL code (where this makes sense ...) with JSBSim, I admit that I like it as much better miter with that method of programming especially on RT programs like these.

As soon as I can, I make the channels that define the drive mechanisms and try to work with the gauges as you indicated to me. I'm curious and I hope a good job comes out.

P.S:

One thing, I think for you trivial: how do you get the statistics so well grouped? If I use system visualization I get this and it is not really easy to group the items presented by the statistics.

Image
abassign
 
Posts: 725
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: It would be nice to have smooth translations and rotatio

Postby WoodSTokk » Wed Jul 11, 2018 7:38 pm

I use filters to animate mechanical parts like needles.
Write in your filter.xml:
Code: Select all
    <filter>
        <name>fuel lowpass</name>
        <debug>false</debug>
        <type>exponential</type>
        <filter-time>0.5</filter-time>

<!-- take this input if the instrument receive power -->
        <input>
            <condition>
                <greater-than>
                    <property>systems/electrical/outputs/bus</property>   <!-- use your electric property and value -->
                    <value>20</value>
                </greater-than>
            </condition>
            <property>consumables/fuel/tank/level-lbs</property>
        </input>

<!-- otherwise take this input -->
        <input><value>0.0</value></input>

        <output>consumables/fuel/tank/level-lbs-display</output>
    </filter>

Write in your model.xml lines like:
Code: Select all
    <animation>
        <type>rotate</type>
        <object-name>fuel.needle</object-name>
        <property>consumables/fuel/tank/level-lbs-display</property>
<!-- set the following values as you need it -->
        <factor>8.0</factor>
        <offset-deg>-80</offset-deg>
        <center>
            <x-m>0.00200</x-m>
            <y-m>-0.00160</y-m>
            <z-m>0.07690</z-m>
        </center>
        <axis>
            <x>-1</x>
            <y>0</y>
            <z>0</z>
        </axis>
    </animation>

I don't know how strong the filters have a impact on the performance and FPS.
It will be nice if someone can tell us what have more impact, filters, nasal or other systems.
WoodSTokk
 
Posts: 51
Joined: Tue Oct 17, 2017 2:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: OE-WST
IRC name: WoodSTokk
Version: 2018.2.2
OS: Debian Buster/Sid

Re: It would be nice to have smooth translations and rotatio

Postby abassign » Thu Jul 12, 2018 9:11 am

I confirm the goodness of Richard's statement about the use of JSBSim for the rotation effects of the gauge hands is very interesting and allows avoiding the use of NASAL programs, substantially simplifying the programming code!

At this point, also to help other friends to make more realistic aircraft, I want to insert some notes that better explain the method that was discussed on this post and that it would be interesting to investigate with an article on the Wiki.

This is the result, observe the level meter and below the voltage that still does not have the filter. The switch on the right is to activate the instrument supply BUS (BUS 1) and the voltmeter indicates that it is actually powered.


The precedent NASAL code:

Code: Select all
# Fuel System Collect_tank_2_all_tank

var set_fuel_pounds_display = maketimer(0.5, func() {
    var isOperative = props.globals.getNode("fdm/jsbsim/systems/electric/bus[1]/V",1).getValue();
    var isFuseOn = props.globals.getNode("fdm/jsbsim/systems/electric/bus[1]/fuel-level-indicator/fuse",1).getValue();
    if (isOperative > 18 and isFuseOn > 0) {
        var collectTank_2_AllTank = props.globals.getNode("fdm/jsbsim/systems/electric/bus[1]/fuel-level-indicator/sw",1).getValue();
        if (collectTank_2_AllTank > 0) {
            var tank5Lbs = props.globals.getNode("fdm/jsbsim/propulsion/tank[5]/contents-lbs",1);
            setprop("sim/G91/fuel/fuel_pounds_display",tank5Lbs.getValue() * 2.7);
        } else {
            var tank_012 = props.globals.getNode("fdm/jsbsim/propulsion/tank[0]/contents-lbs",1).getValue();
            tank_012 = tank_012 + props.globals.getNode("fdm/jsbsim/propulsion/tank[1]/contents-lbs",1).getValue();
            tank_012 = tank_012 + props.globals.getNode("fdm/jsbsim/propulsion/tank[2]/contents-lbs",1).getValue();
            setprop("sim/G91/fuel/fuel_pounds_display",tank_012);
        }
    } else {
        setprop("sim/G91/fuel/fuel_pounds_display",0.0);
    }
});
set_fuel_pounds_display.start();


The JSBSim code + the filter low pass:

Code: Select all
    <channel name="Cockpit Fuel Pounds" execrate="4">
       
        <summer name="systems/gauges/fuel-pounds/fuel_pounds_0-1-2">
            <input>propulsion/tank[0]/contents-lbs</input>
            <input>propulsion/tank[1]/contents-lbs</input>
            <input>propulsion/tank[2]/contents-lbs</input>
        </summer>
       
        <pure_gain name="propulsion/tank[5]/contents-lbs-27">
            <input>propulsion/tank[5]/contents-lbs</input>
            <gain>2.7</gain>
        </pure_gain>
       
        <switch name="systems/gauges/fuel-pounds/libs">
            <default value="0"/>
            <test logic="AND" value="systems/gauges/fuel-pounds/fuel_pounds_0-1-2">
                systems/electric/bus[1]/V GE 18.0
                systems/electric/bus[1]/fuel-level-indicator/sw == 0
            </test>
            <test logic="AND" value="propulsion/tank[5]/contents-lbs-27">
                systems/electric/bus[1]/V GE 18.0
                systems/electric/bus[1]/fuel-level-indicator/sw == 1
            </test>
        </switch>
       
        <lag_filter name="systems/gauges/fuel-pounds/display-libs">
            <input>systems/gauges/fuel-pounds/libs</input>
            <c1>5.0</c1>
        </lag_filter>
       
    </channel>


There are many things that make the use of JSBSim advantageous in place of the NASAL code:

The NASAL program is activated with a timer every 0.5 seconds making the time delay perceptible. It is not convenient to decrease the timer in NASAL as it would increase the system load. The NASAL code is still quite confusing, I do not think it's just my programming quality problem, but because it has to manage different information (presence of a minimum operating voltage (18V) and the switch that reads the tank level engine pickup (a kind of reserve that also serves for critical flight, for example backward flight or high G).

The code written in JSBSim is much more compact, it is executed in a time interval of 1/30 sec. The greater compactness of the JSBsim code (and I would also say its greater readability) is due to the fact that JSBSim uses a typical language for continuous system simulation that does not need to perform a fixed sequencing of the program lines, but simply declare what we want obtain!

A note on execrate = "4" following the channel declaration:

execrate = "4" is a simple method that allows to reduce the workload of the CPU simply "wake up" the code every n execution steps, for example 4 means that the code will be executed not at 120 Hz but at 30 Hz. but remember that unfortunately the execrate parameter does not modify the delta-t (dt) that is defined inside the block (channel) and this creates a sort of local time distortion that requires to adjust the parameters that refer to the time! For example the low-pass filter has its parameter C1 that at 120 Hz works well at 1.25 but at 30 Hz it should be set to 5.0 otherwise the hand moves too slowly.
abassign
 
Posts: 725
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: It would be nice to have smooth translations and rotatio

Postby AndersG » Thu Jul 12, 2018 10:52 am

That you need to adjust the C1 parameter when using execrate ought to be a bug in JSBSim, in particular as I don't think I have seen that effect when changing the overall FDM rate. Can you report it on the JSBSim bug tracker?
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2413
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: It would be nice to have smooth translations and rotatio

Postby Richard » Thu Jul 12, 2018 11:36 am

abassign wrote in Thu Jul 12, 2018 9:11 am:I confirm the goodness of Richard's statement about the use of JSBSim for the rotation effects of the gauge hands is very interesting and allows avoiding the use of NASAL programs, substantially simplifying the programming code!

...local time distortion that requires to adjust the parameters that refer to the time! For example the low-pass filter has its parameter C1 that at 120 Hz works well at 1.25 but at 30 Hz it should be set to 5.0 otherwise the hand moves too slowly.


I'm pleased (but not surprised) that it worked out well doing it in JSBSim.

When I did the execrate for JSBSim I missed the fact that the _filter components calculate the coefficients when initialized. So the "local time distortion" is a bug that will be fixed.
Richard
 
Posts: 601
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: It would be nice to have smooth translations and rotatio

Postby Richard » Thu Jul 12, 2018 2:07 pm

abassign wrote in Wed Jul 11, 2018 10:53 am:One thing, I think for you trivial: how do you get the statistics so well grouped?


I did it the hard way using Excel and working out each part individually based on the total simulation time[1]; e.g. I took out all of the Nasal in the -set file and that's where I got the JSBSim figure from.

------------------------------------------------------
[1] I added some code into the core to measure the total time spent doing simulation tasks. This might make it into 2018.3 if I can get it right.
Richard
 
Posts: 601
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: It would be nice to have smooth translations and rotatio

Postby Thorsten » Thu Jul 12, 2018 2:58 pm

The NASAL program is activated with a timer every 0.5 seconds making the time delay perceptible. It is not convenient to decrease the timer in NASAL as it would increase the system load. The NASAL code is still quite confusing, I do not think it's just my programming quality problem, but because it has to manage different information (presence of a minimum operating voltage (18V) and the switch that reads the tank level engine pickup (a kind of reserve that also serves for critical flight, for example backward flight or high G).

The code written in JSBSim is much more compact, it is executed in a time interval of 1/30 sec. The greater compactness of the JSBsim code (and I would also say its greater readability) is due to the fact that JSBSim uses a typical language for continuous system simulation that does not need to perform a fixed sequencing of the program lines, but simply declare what we want obtain!


With a due sense of futility:

The argument that if you decrease the Nasal timer you increase the system load is, well, funny, because running JSBSim at a higher rate also increases the systems load - if you write the code well, likely near-identical.

With JSBSim, you're using a lot of 'invisible' infrastructure (like the presence of a loop) - which dependent on your use case is good or bad. But it shouldn't trick you into thinking that less lines mean less performance impact.

Note that the way you've structured the JSBSim file, you're executing everything regardless of the switch state (i.e. even without voltage on the bus, you're still computing everything in spite of the result always being zero. This is a problem for more complex conditionals - whereas Nasal can be structured more easily to run the code that's actually needed based on the condition. So it depends really on such factors what you should do, not on anything else.

The actual performance impact between solving an equation Nasal-side or JSBSim-side is something I've never been able to measure - usually it's other factors which decide what is better.

Personally, I find it odd that a day after you could be persuaded to do an implemention JSBSim-side (which you called too big a performance drain before) feel the need to now lecture others on the relative merits of JSBSim vs. Nasal - you simply don't have the experience to do that after a day :D
Thorsten
 
Posts: 9803
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 3 guests