I think that when building surfaces blitz assigns memory in chunks for the vert and the tri list. These chunks start out fairly small, and if exceeded a new larger chunk is assigned and data is copied to the new chunk. Not much you can do about that and I am not sure how much it slows things down though maybe a feature to specify the initial number of verts and tris expected when you define a surface would help.
Maybe resuse large surfaces using clearsurface? Would blitz reserve the surface memory though? I doubt it.
That 652 second time is well slow compared to the others. I think you need to whip up some code to demonstrate, and encourage further investigation.
Edit. I have just done a quick test (with debug off!) just adding some verts and triangles and it is slightly faster than creating an equivalent 64 seg sphere primitive. I would say times are comparable. Adding this mesh 10 times to create a larger mesh with 10 surfaces (by painting each sphere mesh a different color) takes about the same amount of time as creaing just one sphere.
It occurs to me if you are also using positionmesh and rotatemesh and scalemesh on large meshes then you are performing lots of accesses to the vertex data and memory. Your own routine may be able to speed things up in this respect, though you would have to code it so it will do them in the order you want. Of course taken individually blitz native code will perform these faster than anything you could write, but maybe (just maybe) if you are doing all these transforms then it may be faster to do them youself in a more optimised fashion (also when combining surfaces as part of the copy process). Taking this to extremes I guess you could read the vertex data into a bank and pass it to a C routine to do the transforms. A lot of hassle though, so if it still turns out slower don't blame me!
Good luck with the feature request! (Although Addmesh does merge two surfaces into one if they have the same properties - paint them with the same brush to see this.)
BTW, BRL. IMO addmesh should really be checking if the vert or tri limit would be exceeded when combining surfaces and if so create a new one.
Maybe resuse large surfaces using clearsurface? Would blitz reserve the surface memory though? I doubt it.
That 652 second time is well slow compared to the others. I think you need to whip up some code to demonstrate, and encourage further investigation.
Edit. I have just done a quick test (with debug off!) just adding some verts and triangles and it is slightly faster than creating an equivalent 64 seg sphere primitive. I would say times are comparable. Adding this mesh 10 times to create a larger mesh with 10 surfaces (by painting each sphere mesh a different color) takes about the same amount of time as creaing just one sphere.
It occurs to me if you are also using positionmesh and rotatemesh and scalemesh on large meshes then you are performing lots of accesses to the vertex data and memory. Your own routine may be able to speed things up in this respect, though you would have to code it so it will do them in the order you want. Of course taken individually blitz native code will perform these faster than anything you could write, but maybe (just maybe) if you are doing all these transforms then it may be faster to do them youself in a more optimised fashion (also when combining surfaces as part of the copy process). Taking this to extremes I guess you could read the vertex data into a bank and pass it to a C routine to do the transforms. A lot of hassle though, so if it still turns out slower don't blame me!
Good luck with the feature request! (Although Addmesh does merge two surfaces into one if they have the same properties - paint them with the same brush to see this.)
BTW, BRL. IMO addmesh should really be checking if the vert or tri limit would be exceeded when combining surfaces and if so create a new one.