API Question oapiMeshGroup: retrieving vertices.

[Zatnikitelman]

I've been exploring the API here and ran across the oapiMeshGroup method. It returns a pointer to a MESHGROUP struct which has among other things an NTVERTEX struct. According to the API this "...defines a vertex..." but the only coordinates I can find from it are for a single point. I'm probably reading something wrong, but in the MESHGROUP struct it indicates NTVERTEX is a vertex list. In NTVERTEX's definition, it shows position, normal, and texture coordinates. I'm confused as how this is a vertex list and what exactly the coordinates are for.
Thanks for any help,
Zat

 

[escapetomsfate]

I think the vtx member of that struct is a pointer to an array of size nVtx. If you wanted to iterate through every vertex in the mesh group:

	MESHGROUP* group = oapiMeshGroup(MyMesh, 0);

	for(int i = 0; i < group->nVtx ; ++ i)
	{
		NTVERTEX vert = group->Vtx[i];
	}

If we could transform the vertices to vessel local co-ordinates (and that would just be a case of adding the mesh offset, AFAIK) that would be a good start towards generic collision detection.

 

[Zatnikitelman]

Thanks, Hielor also explained it to me via IRC last night. It is indeed a pointer to an array.

 

[martins]

This may be a good opportunity to insert a word of caution about oapiMeshGroup:

From the next version, the use of this function is no longer recommended (bar one exception, see below), for two reasons:

1. Directly editing the vertex buffers requires to lock the buffers in main memory. With T&L drivers, this may require copying the buffers from video to system memory and back, with associated performance penalties, if it's done frequently (e.g. every frame).
2. (and more importantly), the function is not supported with external graphics clients, because orbiter doesn't know in what format an external client stores the mesh (or if it is accessible at all). Therefore it can't return any pointers to the internal structure.

The single instance where oapiMeshGroup will still be supported is immediately after loading a mesh from file with oapiLoadMeshGlobal, before the mesh is passed on to the external graphics client for device-specific conversion. For this purpose, there will be a new variant of oapiLoadMeshGlobal which supports a callback function for editing the raw mesh template, before it is handed on to the client.

You've been warned ...

 

[cjp]

This may be a good opportunity to insert a word of caution about oapiMeshGroup:

From the next version, the use of this function is no longer recommended (bar one exception, see below), for two reasons:

1. Directly editing the vertex buffers requires to lock the buffers in main memory. With T&L drivers, this may require copying the buffers from video to system memory and back, with associated performance penalties, if it's done frequently (e.g. every frame).
2. (and more importantly), the function is not supported with external graphics clients, because orbiter doesn't know in what format an external client stores the mesh (or if it is accessible at all). Therefore it can't return any pointers to the internal structure.

The single instance where oapiMeshGroup will still be supported is immediately after loading a mesh from file with oapiLoadMeshGlobal, before the mesh is passed on to the external graphics client for device-specific conversion. For this purpose, there will be a new variant of oapiLoadMeshGlobal which supports a callback function for editing the raw mesh template, before it is handed on to the client.

You've been warned ...

So, what will be the proper place for 'complicated animations'?

I can imagine this is problematic when the mesh is stored on the video card or in an external graphics client. I can imagine that taking mesh data from video card to main memory isn't an optimized operation, and that communication between Orbiter and graphics client is completely uni-directional by design.

But isn't it possible to keep a 'local copy' of the mesh inside the Orbiter executable, which can be edited freely by a plugin? After editing has finished, Orbiter can re-upload it to the video card or the graphics client.

I don't see how animation is possible otherwise.

 

[martins]

The problem with oapiMeshGroup is that it returns a pointer and leaves it entirely to the addon what to do with it. Even if it pointed to a "mesh template" copy in main memory, orbiter wouldn't know when a change needs to be forwarded to the client.

As an alternative, I am currently tinkering with an "oapiEditGroup" function. This will pass the modified group directly as a parameter, and orbiter will simply pass the edit request through to the client (which hopefully will know what to do with it). It won't be as convenient as editing the group directly in place, but that is the price of device-independence.

 

[cjp]

The problem with oapiMeshGroup is that it returns a pointer and leaves it entirely to the addon what to do with it. Even if it pointed to a "mesh template" copy in main memory, orbiter wouldn't know when a change needs to be forwarded to the client.

As an alternative, I am currently tinkering with an "oapiEditGroup" function. This will pass the modified group directly as a parameter, and orbiter will simply pass the edit request through to the client (which hopefully will know what to do with it). It won't be as convenient as editing the group directly in place, but that is the price of device-independence.

Sounds good. It won't be compatible with the previous API, but as I understand you'll leave the idea of compatibility anyway.

Don't let me talk you into making the thing too complicated. People are already waiting for years for a new version.