Octal450 wrote in Mon Feb 08, 2021 3:05 pm:No, the 757 (and 767) both had either a round ADI with a fast/slow indicator or a non-round ADI with a speed tape. That's all. In FG there is no canvas one.
We've been having these discussions repeatedly, even in the pre-Canvas days.
Basically, a 3D ADI ball is ideally not done in Nasal/Canvas space using the existing drawing primitives.
Thorsten has repeatedly pointed out the shortcomings of this approach based on his own experience coding the shuttle's ADI ball:
https://wiki.flightgear.org/Shuttle_ADI_ballOthers have been wanting to implement a 3D animated sphere-based instrument using properties for space craft (space ship one, vostok).
Given the amount of work involved in using Nasal/Canvas for this (and given the performance implications of doing so), it would be less work to extend the Canvas system to add a dedicated element for loading/transforming arbitrary 3D models using an osg::PositionAttitudeTransformMatrix that is bound to a handful of properties using either tied properties or James' propertyObject<> templates (C++ patch available):
https://wiki.flightgear.org/Howto:Exten ... _3D_modelsAlternatively, a while ago I was approached by another user who needed better plotting support inside FlightGear, i.e. beyond what Canvas.Path provides.
There's an OpenGL/GLSL-aware cross-platform variant of gnuplot available called "MathGL".
And we prototyped a simple Canvas element back in 2016, i.e. as another canvas drawing primitive (mode), just for plotting.
It's actually surprisingly straightforward, i.e. just the usual boilerplate to create/register a new Canvas element (not unlike the tail cam/view camera), but with a handful of properties to instead render a bunch of graphs to a texture (actually an osg::Image).
MathGL cannot only display hard-coded functions, but also take functions as strings and/or use gnuplot-like scripts.
So, displaying a sine() function is the same amount of work as displaying a full 3D mesh (no C++ changes at all):
https://wiki.flightgear.org/Howto:Exten ... ort_MathGLMathGL is also sufficiently flexible to also render fairly complex plots, including spheres - without requiring to go through Canvas.Path at all.
Which means zero Nasal/property overhead at all. This is all going through native C++/C code and the calculation can even be threaded out, too.
http://mathgl.sourceforge.net/doc_en/ea ... rth-sampleAdditional screen shots here:
http://mathgl.sourceforge.net/doc_en/Pi ... l#PicturesSo for more sophisticated plotting needs, this might become a neat option to reduce/avoid unnecessary Nasal and Property tree overhead.
Implementing a 3D ADI ball in Canvas space given our current drawing primitives is almost certainly not what we want to do - if in doubt, check back with Thorsten and the ADI ball on the shuttle
Again, look at the amount of code in Thorsten's code versus the 200 lines of C++ code to load/transform and render an arbitrary 3D model from disk.