API Question Animating a VC MFD with buttons

Lisias

Space Traveller Wanna-be
Joined
May 31, 2015
Messages
346
Reaction score
3
Points
18
Website
www.youtube.com
Hi.

I'm stuck with this problem.

I have a vessel like this:

GXyEypguj3jvMP3mB91V4cyf3zHSe3ixaFlugCIzIAndY1lYi-2ynG4XhMZ8fhF6I1w_te2XiaBHEcBDJu21Rb7VdIPJjK0GpgxrMhAE1i_ok99NNOj1ZXuQ3hfdHvl1XlGxemijaYtpEOmNqxQjQvCQuro5e1cCUkHQz8LjZ9x33J9rFkBWRTW243JLlu8h8hEcEmGTqTjBita-BabG5toJCoL0PG3Zoott3f6xpjTZSAzJnbhjVqvgQW6fqlTmV4QxDO5cpJXmEMOZvbqRR5WdPy73BhbT7qVU5-Y5Ey3JOBEp9-9gZNv-5pM-51ZVYxwg7qxKKipg2n4PdbktcidheC6WyeUKoj-LJr2InhHJgtTDfmaYAd2ymNohuV95yuxgT1dVTfER-Jr8i-mTxgt_6TNMzSy6kBiLR5rtg3IRD6Bzm-EiE77sxFOQMK-vITtIzGGrrNuyBqWyDS9phois-lXvd2g2vOvIUfafJhZ-Mv6hk3TO_QQ-Vpx4i0E7xVJRLYnuTqNlqOdOeAZBoBfb9M97x1cF4s28Y1b4wxY=w466-h390-no


The red strip is the MFD screen, and the pink strip is the PWR/SEL/MNU buttons, and are defined in a separated mesh. They are visible only on Virtual Cockipit.

The "cockpit" animates using MGROUP_ROTATE, CreateAnimation and AddAnimationComponent into this:

Nqe-PbzKbpjP5TxgQISxt7y7KQT00Jm0Hl3fGjqErjtLDPQa7MV_FKvezmSv13h4F-oduKLrIWxjpX2Chbeb1QdTRE3fCFR9FJi4MU_wUjFUmi7UBZ7PwzFj6OOGUb_uRJ6_AzHqqGkAurM6Xlcpo7J8DnkLxFfLqDgq7yWUZ0dd-YDc1o7DgLC9WyLVW86dXSfHwolow6B1JAoUK7gH48jKeTH8vwneZ8cbdgjMww-CFesFGG5qcD-5ocMU_IXsC5MtCwsNlquT2fPFWtv7Q9mlJvIyci6fyjO1bsJTu1R9NIjbQVkPXrZJEcIYO8Jo73cQe3hDTC-Cqc8_mh9Lzl24CUaAX55_uvE9RCwG3BgR4YWC-SWnh0exigUeL5--d0mPRybwe126wv01tHJtXyyhyl5YtKpswkhNi6SAyb2d1bOVL734qBJnpIqEXYlv_Esiof1kn89sHvGYlEG47nsL_43_g04AttQw2KznOn_PtJpNmZ0HNw8-uq_SCnlzk4LBdGj38rohRPPM_qkbxsyKpqLV2PcLXSH_tQ7qAnQ=w456-h581-no


Everything works fine but the MFD Buttons. By trial and error, I found that if I animate the mesh just a bit, the empty area where the button used to be are still clickable.

So I conclude that the oapiVCRegisterArea, oapiVCSetAreaClickmode_Quadrilateral and oapiVCSetAreaClickmode_Spherical API functions use vessel coordinates, not "local mesh ones".

I use a intermediary function that takes a MESHGROUP and calculates the coordinates from it - so I don't have to bother calculating positions, the function calculate the quadrilateral directly from the vertices. [I forgot to add this info while posting]

Calling again oapiVCSetAreaClickmode_Quadrilateral after animation don't help. This function appears to be locked on the original mesh position, not the transformed new position.

How I can tell Orbiter the new VC mesh coordinates in order to get clickable buttons on all stages of the animation (and not only on the original, mesh load time, one?)
 
Last edited:

Hlynkacg

Aspiring rocket scientist
Addon Developer
Tutorial Publisher
Donator
Joined
Dec 27, 2010
Messages
1,870
Reaction score
3
Points
0
Location
San Diego
I'm assuming that you have the button positions defined as constants.

You need to make them variable so that they can move along with the mesh.
 

Blake

Addon Developer
Addon Developer
Joined
Mar 9, 2009
Messages
225
Reaction score
104
Points
58
Location
Lehi, Utah
According to the SDK you should be able to do what you want to do:

oapiVCSetAreaClickmode_Spherical
( int id,
const VECTOR3 & cnt,
double rad
)
...
"This function can be called repeatedly, to change the mouse-sensitive area."


I imagine the ID needs to be the same and only the 'cnt' parameter change, which is vessel coordinates. I've never actually tried this myself.

If that is not working, a (ugly hack) work around may be to register both locations in your mouse handler and check the state of your animation to see if the correct hot-spot was hit.
 

Lisias

Space Traveller Wanna-be
Joined
May 31, 2015
Messages
346
Reaction score
3
Points
18
Website
www.youtube.com
I'm assuming that you have the button positions defined as constants.

No. I use a function that takes a MESHGROUP - so I don't have to bother calculating positions, the function calculate the quadrilateral directly from the vertices.

This works fine as long as the mesh is not animated - as it appears, Orbiter applies a transformation matrix on the original mesh every time before drawing the screen.

---------- Post added at 06:59 PM ---------- Previous post was at 06:55 PM ----------

If that is not working, a (ugly hack) work around may be to register both locations in your mouse handler and check the state of your animation to see if the correct hot-spot was hit.

I forgot to add a crucial information, sorry: the oapiVCSetAreaClickmode_Quadrilateral is fed by a intermediary function that takes a mesh group and calculates the points from the vertices.

However, your ugly hack gave me a idea to try. Thx! :)
 

Hlynkacg

Aspiring rocket scientist
Addon Developer
Tutorial Publisher
Donator
Joined
Dec 27, 2010
Messages
1,870
Reaction score
3
Points
0
Location
San Diego
You realize that animations are stored outside the mesh don't you?

The vertices stored in the meshfile don't move so neither will any function that reads their position.
 

Lisias

Space Traveller Wanna-be
Joined
May 31, 2015
Messages
346
Reaction score
3
Points
18
Website
www.youtube.com
You realize that animations are stored outside the mesh don't you?

Animations are transformation matrices exposed in a user friendly way.

So one applies that matrix to an array of vertices, and uses this new array of vertices to feed the triangles and you get your mesh "animated".

So you need a copy of the "transformed" mesh in order to draw it, and this is what I'm aiming to "reuse" to redefine the moving MFD's clickable areas.


The vertices stored in the meshfile don't move so neither will any function that reads their position.

Being that the reason I tried to read the vertices in memory, iterating on the Vtx[] property of a MESHGROUP struct. :)

What I'm concluding from this is that mesh handler gave by oapiLoadMeshGlobal is never changed - Orbiter makes a copy to apply the transformations and never touches the original, in memory, copy.

What I have to admit, makes sense - this is a handler to a Global mesh... :facepalm:

I'll search a way to get a local copy of the mesh and see what happens.

Thanks for the heads up.

---------- Post added at 08:53 PM ---------- Previous post was at 07:53 PM ----------

Following the hint from Hlynkacg, yes I had messed up by acquiring the buttons position from the *Global* mesh. (sigh).

I managed to get the handler from the copy from the vessel local mesh group - what can be obtained using VESSEL::GetMesh when a visual is created.

However, I don't bother to try it because it creates two problems:

1) The mesh is only valid between Visual Created and Visual Destroyed events - once the vessel gets out of the eye sight, his local meshes can be destroyed. But my animations can happen while the vessel is not visible.

2) It will not work on D3D9 (or any other external graphic client).

The problem 1 is manageable by setting a flag to prevent the Click Area redefinitions when appropriate, and to force it on the first PostStep after a Visual Created event.

But the problem 2 is a show stopper, I don't intent to create vessels that cannot be used on external clients. :(

I still want to pursue the idea - using the very mesh to locate the controls are the best solution possible, and it already works for static cockpits.
 
Last edited:
Top