SDK Question 2D Panel mesh structure

[Blake]

Orbiter uses left hand, or 'clockwise' ordering of the triangle list to control face visibility.

From 3DModelpdf: "Only the “clockwise” (CW) side of each triangle is rendered: the side which, if you look at
it, has the vertices arranged in a clockwise order. The opposite “counterclockwise” (CCW)
side is invisible."

However, in Martin's blog post on 2D panel geometry there is this layout:

static DWORD panelW = 1280;
static DWORD panelH = 400;
float fpanelW = (float)panelW;
float fpanelH = (float)panelH;
static NTVERTEX VTX[4] = {
{ 0, 0,0, 0,0,0, 0,0},
{ 0,fpanelH,0, 0,0,0, 0,0},
{fpanelW,fpanelH,0, 0,0,0, 0,0},
{fpanelW, 0,0, 0,0,0, 0,0}
};
static WORD IDX[6] = {
0,2,1,
2,0,3
};

The DG in 2010 and in the beta appears to have a similar layout. Unless I'm reading this wrong this is counter clock-wise rotation. I have also noticed I need to flip the normals in my usual script to get the 2D panel to appear. The UV settings are then messed up which may be an un-related issue.

Does the 2D panel mesh geometry not follow the 'left hand' rule? Or am I doing something wrong?

Thanks.

 

[jedidia]

Unless I'm reading this wrong this is counter clock-wise rotation.

You're reading it wrong the vertices are declared counter-clockwise, but that isn't what matters. What matters is the order in which they appear in the triangles.

This is what's declared in the vertex list:

static NTVERTEX VTX[4] = {
{ 0, 0,0, 0,0,0, 0,0},                        //Vertex 0, upper left corner
{ 0,fpanelH,0, 0,0,0, 0,0},                //Vertex 1, lower left corner
{fpanelW,fpanelH,0, 0,0,0, 0,0},        //Vertex 2, lower right corner
{fpanelW, 0,0, 0,0,0, 0,0}                //Vertex 3, upper right corner
};

The definition of the two triangles that make up the panel background, however, is as follows:

static WORD IDX[6] = {
0,2,1,             //Triangle 0, from Vertex 0 to Vertex 2 to Vertex 1: upper left, lower right, lower left; clockwise
2,0,3              //Triangle 1, from Vertex 2 to Vertex 0 to Vertex 3: lower right, upper left, upper right; clockwise
};

As you can see, the order in which the vertex positions are defined really doesn't matter. What matters is in what order they appear in their respective triangles.

 

[Blake]

Thanks, I do understand the triangle list. What I was not doing was flipping the y axis so that (0, 0) is the UPPER left hand corner instead of the LOWER left hand corner. Your explanation reminded me of that.

I'm trying to setup Blender so I can layout a panel and have the geometry correct. I'll need to account for that.

 

[francisdrake]

One thing I learned the hard way:
If the panel mesh is created in the modelling program, it needs to have a UV-map defined and a texture rendered on it. No matter which texture, it will be overwritten anyhow. But if no texture is defined, the panel surface stays dark.

This may be different with other modelling programs, but if you are scratching your head why the MFD is not rendered, try this.

 

[jedidia]

What I was not doing was flipping the y axis so that (0, 0) is the UPPER left hand corner instead of the LOWER left hand corner. Your explanation reminded me of that.

It might be a bit counterintuitive because it's basically a definition for a mesh, but it's in screen coordinates. Once you're throwing bitmaps at it, however, you're really glad for that. All bitmaps have 0/0 in the upper left.

I'm trying to setup Blender so I can layout a panel and have the geometry correct. I'll need to account for that.

The panels are designed to be 2-dimensional. All you're defining here is a drawing surface where you can then draw your bitmap panel elements on. If you want a 3-d cockpit, you should go for a virtual cockpit, not a complex panel geometry.

If the panel mesh is created in the modelling program, it needs to have a UV-map defined and a texture rendered on it. No matter which texture, it will be overwritten anyhow. But if no texture is defined, the panel surface stays dark.

This is not just the case if you create the panel mesh in a modelling program. drawing bitmaps on it is the sole purpose the whole 2d panel architecture is designed for.

 

[Blake]

...

The panels are designed to be 2-dimensional. All you're defining here is a drawing surface where you can then draw your bitmap panel elements on. If you want a 3-d cockpit, you should go for a virtual cockpit, not a complex panel geometry.

...

The benefit of the mesh approach is to create mesh objects which can then be animated or 'edited' at run-time without the need to deal with bitmaps. They are only 2D in the sense that the Z value is always 0. In theory you can then share code between your virtual cockpit and the 2D panel. I'm putting that theory to the test.

My [ame="http://www.orbithangar.com/searchid.php?ID=6777"]SR-71-r[/ame] project has a functional virtual cockpit, but it does not have a 2D panel cockpit. I would like to see if I can get the logic that drives the virtual cockpit elements to also drive the elements in the 2D cockpit.

I have not gotten to the MFDs in the 2D cockpit, but in the virtual cockpit I have to assign them a texture just so that they get a UV map (basically of 0 and 1). The actual texture does not matter, and I really should update my script so that the MFD mesh does not ask for a texture but just applies the UV mapping. The HUD mesh is similar.

 

[jedidia]

The benefit of the mesh approach is to create mesh objects which can then be animated or 'edited' at run-time without the need to deal with bitmaps. They are only 2D in the sense that the Z value is always 0. In theory you can then share code between your virtual cockpit and the 2D panel. I'm putting that theory to the test.

Hmmm... if I understand you right, you want to use the same drawing routines for displays in the virtual cockpit and the panel (which is perfectly reasonable). Personally, I think rendering them to a generic texture surface and throwing it from there either to the texture surface in the virtual cockpit or onto the panel at the apropriate position would be an easier solution. You can still reuse all the drawing code, all you have to do is blit the end result to a different surface depending on what mode is active.

EDIT: no, wait... it seems like you want to put actual mesh animations in there. I have no idea how feasible that is. Let me know how it turns out!

 

[Blake]

...

EDIT: no, wait... it seems like you want to put actual mesh animations in there. I have no idea how feasible that is. Let me know how it turns out!

Yes, from Martin's blog posts here: New style panels

 

[jedidia]

I went through that a few years ago, but I can't remember anything about mesh animations...

 

[Bibi Uncle]

If someone is interested, I have a few classes to write 2d panel instruments easily for Orbiter. It creates the mesh for you and you can easily populate it without having headaches with the triangles. There is basic ordering of the groups (for background and top elements) and every panel element sharing the same texture are grouped together for better performances. I wrote it for Project Mercury a few years ago. I can put it on GitHub if anyone is interested.

 

[llarian]

Bibi Uncle: It would be interesting to see it anyway. Please post or fire it to me via email, pls.

Cheers

 

[Bibi Uncle]

There it is : https://github.com/bibiuncle/projectmercury

Not very well documented, but it should be fairly easy to understand.