Limitations on editing meshes from plugin code?

[cjp]

Hi,
I recently started creating my first Orbiter plugin project. I'm not having any major problems so far, and everything seems to work :woohoo:, so now I want to reach more ambitious goals than just an empty DLL with a custom vessel class.

What I want to do is to create a binding between Orbiter and my libProcTer procedural terrain library. Currently, the only way to use complicated dynamically generated meshes in Orbiter seems to be in vessels, and therefore I'll make my terrain a special kind of vessel.

Now, I don't need to play with engines, wings, docking ports etc., but do I need full control over the vessel's meshes. This is what I found out so far:

• Meshes can only be created by loading a .msh file. There doesn't seem to be a construction method that doesn't involve a .msh file.
• The number of mesh groups in a mesh seems to be a constant: you cannot add or remove mesh groups dynamically
• The number of textures in a mesh seems to be a constant too.
• Each mesh group can only be attached to a single texture
• You can add and remove meshes dynamically
• You can edit the vertex positions, the number of vertices, the triangles and the number of triangles dynamically
• You can edit textures dynamically

Is this correct?

The number of textures in my surface changes continuously, so, if the above is true, then I have two options:

• Use a .msh file with a very large number of groups and textures, and disable certain groups if the current number of active textures is smaller than the number of groups & textures in the .msh file
• Use a very small .msh file with only one group and texture, and add/remove this mesh multiple times according to the number of textures in my model

The last option is of course the most elegant because you don't have an upper limit on the number of textures. Does anyone know whether any of these approaches would give a large performance penalty?

 

[Urwumpe]

What about writing a temporary mesh file?

 

[cjp]

What about writing a temporary mesh file?

That would be a nice dirty hack :lol:

I doubt if this would really add anything to existing solutions. Maybe it would be a solution for the "large .msh with lots of groups" option: if the number of groups+textures is not sufficient, then create a larger .msh file and reload the mesh.

For the rest: if the actual vertices and faces can be edited freely, then the .msh only needs a very small default shape, which can then be replaced with the actual shape by the plugin code.

To give you some idea of the required performance: when flying fast at low altitude, you can expect multiple texture loads/unloads per second (actually just as fast as possible), and a different mesh shape in every frame. There are typically around 8 to 20 triangles per texture, with more triangles per texture at higher velocities, because then the most detailed textures fail to be loaded in time.

Generating a temporary .msh file would add extra filesystem access calls.

 

[Urwumpe]

creating a mesh in memory would be better, but many small meshes would result in lower performance finally - mesh group switches and material switches (to the same material even) make Orbiters current renderer slower.

 

[cjp]

creating a mesh in memory would be better, but many small meshes would result in lower performance finally - mesh group switches and material switches (to the same material even) make Orbiters current renderer slower.

I don't think I can avoid that: I will have many textures anyway. The only thing I can do is sort the faces based on texture, and place all faces with the same texture in the same mesh group.

Is there an additional penalty for using multiple meshes, compared to using a single mesh with multiple groups?

There has to be a penalty for loading and unloading meshes. How large would it be? Would it help to make a system that doesn't really unload meshes, but instead keeps them (inactive) in memory for re-use when a new mesh is requested?

 

[CaptnDave]

Just out of curiosity, is it possible to add/remove mesh groups or even just make them invisible. I saw that there is something to modify groups. Would scaling them to 0 work? If so, how do I work that command (the guide is rather cryptic)? Or is there a better way to do this?