[abenedik]

That are interesting result.

The load time is expected - much better but still takes quite long.

But the long rotation (=render) time is a surprise. If using MultiMaterialBoxes was faster here, than this can mean that it is better to use many Visual3D objects than many GeometryModel3D objects. So I would advice you to create a ModelVisual3D for each Model3DGroup - you can also try to put the transformation matrix to ModelVisual3D instead of Model3DGroup.

This way you could also reuse the "boxes" with same colors - they would use the same Model3DGroup that cold be frozen and than each "box" would have different ModelVisual3D with its own transformation.

You can use multiple cores to create objects that are frozen - if you would froze the whole Model3DGroup, than all the Model3DGroup can be created in parallel for - after they are created you can create ModelVisual3D objects on the UI thread.

You could also create a more complicated solution where Model3DGroup-s would be created on background threads and filled into a queue (optimized for many concurrent writers and one reader) - the queue could be read on UI thread and ModelVisual3D objects could be created there. I guess that this would be faster than previous multithreaded version - but cannot say for sure.

You can also try to set ClipToBounds on Viewport3D to false and (it not needed) set IsHitTestVisible to false.


WPF 3D is almost always CPU bound - so having very good graphics card does not help a lot.