How to set up MVVM for highly dependent hierarchical objects with 3D representation

Question

Imagine a program that designs plates with geometric cutouts. You start with a rectangular plate. A plate can have one or more rectangular depressions carved out of it. Each of these can have one or more circular holes cut out of it. I have attached an image with a few sample plates to illustrate what I'm talking about.

Each of these plates is defined by it's width and height. Each rectangular cutout is defined by its position, width and height. Each Circle is defined by it's position and radius. For the sake of simplicity, assume that nothing overlaps or hangs off of edges.

Here is a very basic UML diagram of the class structure:

In order to draw this in 3D you have to generate geometry from the hierarchy starting at the bottom and then working up, so first generate the inner hole surfaces, then generate the depression faces, and finally generate the plate faces. It seems like all of the code that generates these vertices and triangles should be in view models, not in the model. What does that class structure look like?

Here are a few thoughts I've had:

Any thoughts on how best to mesh these models with their view models? All of the MVVM articles I've found are either very high-level and talk about application level architecture where the view model is a single box or they are very low-level and talk about databinding and commands.

Answer 1

I think there is several things going on here.

Generating a mesh for visualization

This would be a typical "constructive solid geometry" (CSG) problem. I would guess that the best approach would be to start with the plate first, and then subtract holes and depressions from this. Starting with the holes first could cause problems in case holes intersect. I would not put this in the ViewModel since this could be useful without any UI.

Looking at some commercial software like fusion360, instead of combining meshes directly, they seem to have a fairly nice intermediate model with a more abstract description of edges, surfaces etc. But I do not have the faintest idea how they are doing it.

Representing the hierarchy in the UI

For this I would suggest your right-most alternative in the image. I.e. that each model-type have a corresponding ViewModel type. The visitor pattern can be used for this pattern, i.e. you can declare an interface for a visitor in the model, while the visitor is implemented in the viewModel, mapping each model-type to the corresponding ViewModel type. This should allow you to separate the model and viewModel into separate projects without any issues with circular dependencies.