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.

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

Postby Richard » Thu Jul 12, 2018 4:00 pm

Thorsten wrote in Thu Jul 12, 2018 2:58 pm:
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.


Nasal is pretty efficient as is JSBSim; I don't think you can realistically state performance as a reason for using one or the other (although I still recommend not using Nasal for simulation loop tasks).

Maybe one day I'll measure the performance of the two; but for now it is just not interesting; using JSBSim for simulation is the right thing to do and having a simulation loop inside Nasal is probably not, but expert developers have the right to ignore this general recommendation and use Nasal for anything they see fit.
Richard
 
Posts: 609
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 4:45 pm

using JSBSim for simulation is the right thing to do and having a simulation loop inside Nasal is probably not,


As I said earlier, it really depends on

a) how often does the thing you simulate change?
b) how many conditional branches are there?
c) how complex is the stuff to be executed dependent on the conditionals?

For the task at hand, JSBSim is the tool of choice, but that's not generally true, I've ran into several examples which get pretty ugly really pretty fast in JSBSim which are a no-brainer in Nasal.
Thorsten
 
Posts: 9896
Joined: Mon Nov 02, 2009 8:33 am

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

Postby Richard » Thu Jul 12, 2018 7:16 pm

Thorsten wrote in Thu Jul 12, 2018 4:45 pm:a) how often does the thing you simulate change?


Just to be clear when I said simulation loop; I mean something like a timer firing every frame and doing calculations in this timer loop. It is quite easy to add inefficient or overly burdensome code into a Nasal loop and ruin the frame rate[1]

Also as I said "expert developers have the right to ignore this general recommendation and use Nasal for anything they see fit"; there are a lot of folks who don't really understand what to use where - which is why I'm stating a simple rule "JSBSim for simulation; Nasal for event handling, unless you know what you're doing".

---------------
[1] Like I did with the F-15 radar.
Richard
 
Posts: 609
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 7:51 pm

It is quite easy to add inefficient or overly burdensome code into a Nasal loop and ruin the frame rate[1]


Amen.

Dependent on the exact meaning, I just disagree with - simulation code should be inside the JSBSim model (or not - see below)

Consider the simulation of an electrical system for instance. It can be done as a JSBSim system alright, but upon closer reflection, it

* changes state instantaneously when certain events (switches mostly) occur, there's no transients at the timescale of a framerate
* has lots of conditionals if it is sufficiently complex
* has nested conditionals (i.e. you never need to evaluate all of them)

So when implementing it in JSBSim, most of the time you're just evaluating an unchanged set of conditionals, and that's all branches of the lot. If done in Nasal and by listeners, you evaluate the conditionals for the specific branch once for every state change and otherwise do nothing (because nothing changed). Algorithmically this beats the crap out of doing JSBSim.

(You can of course do it in Nasal per frame, add some inefficient property I/O, and you get it much slower - it's not that Nasal is better or worse, but Nasal offers you a flexibility for designing systems models - especially those in which you have discrete state changes - that is not so easily gained in JSBSim.)

(If on the other hand, you mean by 'simulation vs. event handling' essentially the difference between continuous and discrete state changes, then we're in agreement... It's just not so clear to me what you mean by 'simulation')
Thorsten
 
Posts: 9896
Joined: Mon Nov 02, 2009 8:33 am

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

Postby abassign » Thu Jul 12, 2018 8:25 pm

Thorsten wrote in Thu Jul 12, 2018 2:58 pm:With a due sense of futility:


:shock:

Honestly I do not understand the meaning of what you write ... I would like to remind his lordship that I made SW simulation with the same technique of JSBSim, as already written in the premise of this post, so I can understand how it works ... and for this I can also know how it is possible to parallel it since I have also developed algorithms for the parelization of simulators derived from CSMP (Continuous Systems Modeling Package http://www.smrcc.org.uk/members/g4ugm/csmp1130.htm from which also JSBSim derives). However, many of these simulators with RT capabilities use the technique of running a module only if indeed its input variables have been changed (binary flags are used), my feeling is that JSBSim does so, noting the fact that a switch if it points to a nonexistent parameter, it does not report the error until it is actually executed ... just like your wonderful NASAL.

Personally I prefer, if possible, to use JSBSim instead of NASAL because JSBSim is much easier to keep it in time also by other programmers (as indeed all the languages derived from the methods introduced 50 years ago by the CSMP CSMP / 1130 http://media.ibm1130.org/1130-002-ocr.pdf). NASAL is a jumble of languages, maintained by someone (perhaps one or two programmers) and little documented! This fact has long generated a complaint of those who would like to replace NASAL with Python!

Flightgear has a few nice things in terms of programming languages: XML for managing graphic objects and JSBSim. Whenever I am forced to use NASAL, maybe within the XML as sometimes happens, I get nervous and sad because I understand that I am putting in the code a piece.

Thorsten wrote in Thu Jul 12, 2018 2:58 pm: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


If instead his lordship real height, read the meaning of what you write, he would have discovered that my question was how to perform an animation in XML with smooth movement without using NASAL! As it is clear that NASAL disgusts me! Is it clear or not?
My surprise, in this post, was to read that is possible efficiently replace parts of NASAL with JSBSim code because is possible slow down the single channel. So I immediately wanted to verify by taking one NASAL code of the G91R1B and take it, in an orderly manner, in JSBSim ... and I noticed that it works very well, which is execute when really necessary and with a reaction time that with NASAL I dreamed because JSBSim processes are performed with a very efficient batch technique .... not only, but the code is readable!

Now I wait, if you want, to receive your apologies for having moved the topic of this post from a technician to your personal upsets, without giving a valid help ... a help that instead others have given in this post that I find very interesting and instructive. However, as already happened, from now I no longer respond to what you write in this post, as I am sure it is a perfect waste of time. :evil:
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 » Fri Jul 13, 2018 3:58 am

Honestly I do not understand the meaning of what you write ...


Hence the sense of futility...

without giving a valid help ... a help that instead others have given in this post that I find very interesting and instructive


Hm... given that I've recommended the very same thing Richard did, that's a rather interesting statement. Don't let whatever personal feelings you may have in this matter guide your responses please.
Thorsten
 
Posts: 9896
Joined: Mon Nov 02, 2009 8:33 am

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

Postby Richard » Fri Jul 13, 2018 6:18 am

Thorsten wrote in Thu Jul 12, 2018 7:51 pm:(If on the other hand, you mean by 'simulation vs. event handling' essentially the difference between continuous and discrete state changes, then we're in agreement...


We're in agreement.
Richard
 
Posts: 609
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 » Fri Jul 13, 2018 6:45 am

As it is clear that NASAL disgusts me! Is it clear or not?


This is clear, but here lies the problem keeping me in this thread - your personal dislike for Nasal is not a valid basis for recommending best practices to others - only understanding based on experience and performance measurements is.

If you dislike Nasal, chances are you never spend the time to learn how to code efficiently (things like data providers, stored property pointers - in your sample code, you've used the maximally inefficient way to retrieve a property for instance - shared update loops,...) and as a result your code is badly performing, hence you see your dislike of Nasal validated.

This, however, has more to do with you than with Nasal.
Thorsten
 
Posts: 9896
Joined: Mon Nov 02, 2009 8:33 am

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 2 guests