I assume this could be due to the wall being in the way however there seems to be no true way to hide a group

"Suppress this group's solid model" ?

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

is poor Z-buffer resolution, and I don't know of any good way to solve it.

As I know, in Blender if projection set to "Orthographic" you will never got such issue.

I assume this could be due to the wall being in the way however there seems to be no true way to hide a group

"Suppress this group's solid model" ?

ah admittedly I didn't see that

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

I did wonder if going through the effort of expanding every measurement to millimetres (I've been doing it in centimetres because I'm using a tape measure) would help, but then the same issue doesn't manifest on the individual models prior to assembling.

I did wonder if going through the effort of expanding every measurement to millimetres (I've been doing it in centimetres because I'm using a tape measure) would help,

SolveSpace has no "centimeters" dimensions units; only "milimeters", "meters" or "inches".

but then the same issue doesn't manifest on the individual models prior to assembling.

You could import parts in assembly scaled (so no need remodel each part from mm to m manually)

More generally, the issue you're hitting is poor Z-buffer resolution, and I don't know of any good way to solve it.

That has nothing to do with the units or dimensions in your design--it's purely a rendering artifact that depends on the relative sizes and distances with regards to the viewport.

SolveSpace has no "centimeters" dimensions units; only "milimeters", "meters" or "inches".

this is true, so dimensions are technically entered at 1/10th scale

That has nothing to do with the units or dimensions in your design--it's purely a rendering artifact that depends on the relative sizes and distances with regards to the viewport.

I think I understand what you're saying. so basically the renderer internally uses relative measurements based on the largest measurement, thus it treats the zoom level as such a small fraction that errors are more likely to happen?

so basically the renderer internally uses relative measurements based on the largest measurement, thus it treats the zoom level as such a small fraction that errors are more likely to happen?

More or less, yes. See this page, and in particular this answer.

I would classify this as a bug in SolveSpace, but not a high priority one, or one with a straightforward fix. There are a few relatively easy solutions one could try, like floating point Z-buffer (easy to add, poor hardware support, unexpectedly low payoff because of precision issues elsewhere in the rendering pipeline) and logarithmic Z-buffer (a bit more complex to add since it requires changes to shaders). Any enthusiastic graphics programmer who would like to help is welcome to look into this.

Also, this can be projection / modelview matrix issue. not correct Znear / Zfar or loosing precision during computation.