@stingray_SIX_TWO:
The models I was referring to are one model and object the questio is do I add the necessary vertices to the model to connect it all (it will result in more tris anyway you cut it) or do leave them unattached?
I can’t say specifically for BMS programming. I don’t know much about D3D…but I do have a good bit of OpenGL mesh import & procedural mesh generation experience. Also from opengl 2+ and d3d 9+ they have programmable pipelines, so I assume the pipeline capabilities and requirements are similar. If someone has more relevant experience, please correct me.
Anyways, I think that it will make things slower if you combine those objects in the way you are suggesting. First you’ll have to add more vertexes and tris, as you have foreseen, but it could be even worse: in OGL, the vertex pipeline wants parity between vertexes, texcoords, and vNormals. These little detail pitot tubes will almost certainly need separate texture coordinates than the fuselage, so to get parity the mesh importer would then need to duplicate vertexes you merged and then you still have all the extra tris you added, which effectively un-does your work.
You could still minimize draw calls by combining the objects (select both, then Ctrl+J), but I think trying to make it all nice and “sealed” is a bad idea. The only way I could see it helping is for depth buffering (it could z-thrash slightly on intersection) but at the distances your model will be viewed from it shouldn’t matter at all.
Going to try to illustrate how I typically do it in OpenGL: a cube in blender has 8 vertexes, and 6 faces. If there’s a single square texture to use for each side of the cube, then we’ll need 24 texture coordinates. We need vertex normals for lighting, we want a sharp faceted look, so each side of the cube will have 4 identical normals, but we’ll need 24 vertex normals as well.
So I run my importer and from that blender mesh it generates 6 separate squares (each made of two tris), one for each side of the cube, each with unique texcoords and vnormals. it’s all in a single 24 vertex mesh, so still one draw call.
vertex buffer: 24
texcoord buffer: 24
vnormal buffer: 24
and a triangle element array: with 36 elements. 6 sides x 2 triangles_per_side x 3 vertex_indexes_per_triangle.
and when I draw, I bind the vertex, tc, and vnormal buffers, and then draw using the indexes from the element array, it jumps around lightning fast and draws them all. Even if they aren’t continuous, like the element array were just the top and bottom tris of the cube, it would make no difference.
All that being said, and even if my assumptions are correct regarding d3d, there could be ancient remnants in the BMS mesh format from 1997. I think the quake2 mesh exporter would break the mesh up into triangle strips and triangle fans because they could wring more performance out of it back in the days of the fixed pipeline.