12-19-2019, 12:38 PM
I am glad that you find a working algorithm.
When changing the positions it is (as you have found out) very slow to work directly on Positions in MeshGeometry3D. There each access to Position (e.g. "var p = mesh.Positions[i]") also requires a call to check the thread (to prevent access from another thread - this is done in the getter). Also, the positons are stored in a FrugalStructList that complicates access to values (I really do not understand why this was choosen for positions collection). What is more, each setting of a position checks the thread and also triggers change notifications.
One way to optimize this is to disconnect mesh from the parent GeometryModel3D - set model.Geometry to null, then do the changes and then set the Geometry back to the mesh.
An even better option is to use simple list or array objects to store the positions:
- copy all Positions to a list (List<Point3D>) or even better an array (Point3D[]) and when you need to read them, read the values from array and not from MeshGeometry3D.Positions
- when changing the positions, also do all the changes in an array (or list). When you are done with the changes, set the new positions with: mesh.Positions = new Point3DCollection(myPositions)
If this does not work fast enough, then you may need to generate / update meshes in multiple threads. To make this work, you will need to have separate MeshGeometry3D objects for each thread (one MeshGeometry3D object cannot be updated in multiple threads) - so you can create one MeshGeometry3D object in one background thread. To use that object in the main UI thread, you will need to call Freeze on it - this will prevent any changes and allow it to be used on the main UI thread.
If even this will not be fast enough, then you will need to use Ab3d.DXEngine and its MeshObjectNode or some other low level object - see "Advanced Ab3d.DXEngine usage" section in Ab3d.DXEngine samples for more info.
And one last and probably the most important tip: do not optimize the code without first profiling it and seeing where the actual reasons for slow performance are!
When changing the positions it is (as you have found out) very slow to work directly on Positions in MeshGeometry3D. There each access to Position (e.g. "var p = mesh.Positions[i]") also requires a call to check the thread (to prevent access from another thread - this is done in the getter). Also, the positons are stored in a FrugalStructList that complicates access to values (I really do not understand why this was choosen for positions collection). What is more, each setting of a position checks the thread and also triggers change notifications.
One way to optimize this is to disconnect mesh from the parent GeometryModel3D - set model.Geometry to null, then do the changes and then set the Geometry back to the mesh.
An even better option is to use simple list or array objects to store the positions:
- copy all Positions to a list (List<Point3D>) or even better an array (Point3D[]) and when you need to read them, read the values from array and not from MeshGeometry3D.Positions
- when changing the positions, also do all the changes in an array (or list). When you are done with the changes, set the new positions with: mesh.Positions = new Point3DCollection(myPositions)
If this does not work fast enough, then you may need to generate / update meshes in multiple threads. To make this work, you will need to have separate MeshGeometry3D objects for each thread (one MeshGeometry3D object cannot be updated in multiple threads) - so you can create one MeshGeometry3D object in one background thread. To use that object in the main UI thread, you will need to call Freeze on it - this will prevent any changes and allow it to be used on the main UI thread.
If even this will not be fast enough, then you will need to use Ab3d.DXEngine and its MeshObjectNode or some other low level object - see "Advanced Ab3d.DXEngine usage" section in Ab3d.DXEngine samples for more info.
And one last and probably the most important tip: do not optimize the code without first profiling it and seeing where the actual reasons for slow performance are!
Andrej Benedik