• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

VC gauge 3D needle animation smoothness

B21

B21

Messages
149
Country
unitedkingdom
This has to be a classic question....

If a needle for a VC gauge is implemented as a 3D animation with 100 steps, is there any way to improve the motion appearance so the individual steps are less noticeable? With a max reading of +10, the frames represent 0.1 increments, and the reading on the gauge might go (say) 1.2, 1.3, 1.4, 1.5 over a period of a few seconds and this is noticeable as stepping motion in the needle. I'm assuming exactly the same issues arise in other animations.

I.e. can FSX itself do some kind of smooth animation interpolation *between* the frames defined in the animation, if so how do you program for this? Or is it normal to have (say) 400 animation steps to ensure smooth motion?

The fallback would be to use a 2D gauge with rotation, but that should only be necessary if 3D gauges using animation is a known non-starter.

thanks,
B21
 
I *think* the problem is solved... it seems you can send a *floating point* number to drive the animation and FSX smoothly interpolates between adjacent frames based on the fractional part. Previously I assumed for a 100-step animation you should use the 'int'.

This sound right??

thanks
B21
 
How were you even getting an integer return from the XML A:var to begin with? They should all be returned as a FLOAT64 value...

Where you using a "cast to integer" via the XML script token 'int' ???

But yes, float values are required for smooth interpolation by the sim's rendering system.
 
thanks n4gix - the design is simple (for the best...) - I'm controlling the animation with a single L: variable in the range 0..100, and I write to this variable from within an XML gauge. Even though it's an electrically driven analogue dial I'm modelling many specific actual use cases - the blip you get when the instrument is turned on, the momentary odd behaviour as the 'static' is switched and a few others. It turns out the code for all the 'special' cases far outweighs the basic algorithm computing the normal reading, but makes for a more realistic gauge of this type than the current standard.

And yes you are right on the money, in generating the L: animation frame number value appropriate to my internal analogue reading, I cast to an 'int' in the mistaken belief that the animation system needed the actual 'frame number'. I'm actually fairly impressed that FSX can do the (presumably linear) interpolation of the model coordinates when presented with an intermediate value.

It seems this would mean if you have an animation that has a simple linear motion, you would only need to model the start and end point?

thanks,
B21
 
Last edited:
B21 said:
It seems this would mean if you have an animation that has a simple linear motion, you would only need to model the start and end point?
Click to expand...

Yes, for strictly linear movement that's all that's required.

In an actual gauge (XML script or C), we can create a non-linearity table that will allow for rather precise calibration.

However, for XML scripting of 3d gauges via modeldef.xml (or MakeMDL.parts.xml) things become much more difficult...

...for those, you have to develop a run-time algorithim that will apply a scalar to the driving variable based on defined ranges, which means a LOT of nested and nasty if{ xxx } sections! :D
 
Last edited:
thanks - all seems to make sense.

is there actually a good reason to put the script in modeldef.xml? Or is it better to put a single L: variable in modeldef.xml and put all the script in an XML gauge on the VC panel - perhaps one without display elements? I wonder if a complex script is easier to develop in an XML gauge, but then I've never actually compiled a 3D cockpit model... I understand a trivial gauge script like (A:INDICATED ALTITUDE, feet) can be placed in modeldef.xml but even then you'll probably still have to code for units conversion as needed by the user settings.

B21
 
It's much easier to "program" in an XML gauge script. There's only so much that can be done within a modeldef.xml entry...
 
You must log in or register to reply here.
Back
Top