Having proper face culling would be indeed helpful: It would greatly reduce memory consumption (RAM and VRAM). It would certainly also improve the framerate, although I wouldn't expect massive gains here (considering that most faces won't be fully rendered anyway due to early depth testing).
However, unfortunately it's almost impossible to implement this for the new version without killing the performance (in terms of world generation speed) 
Unlike the Java version (which had indeed face culling, at least for blocks), every element can have an arbitrary position, size and rotation now - so it's complicated to determine whether or not a face is fully occluded by another element. In a block world, this would be a lot easier to find out, because we just have to check if there is actually a block next to the current element - since blocks would always have the same size and orientation, they will definitely fully occlude a face.
But in addition to this, it's also a lot slower to find neighbour elements in the new version: In the Java version, each block was stored in a flattened 3d array, so we could simply calculate the actual array index from the block position (which was always an integer position) - this way it was very easy and blazingly fast to find all neighbour blocks. In the new version, there is no way to find an element depending on its position, so we still have to go through the whole list until we find the appropriate element. This results in lots of comparisons.
It would probably work on a small scale, but considering that some people create buildings consisting of thousands or even hundreds of thousands of construction elements, these calculations would quickly become a performance killer (in terms of generation performance) 
At the end of the day, I'm not sure if it's worth it to trade world generation speed for memory savings and smaller framerate improvements (as mentioned above) 
We want, however, offer a way to export buildings to .obj or .fbx files - there is would be certainly helpful to get rid of occluded faces (even if this is a costly operation). Once that's implemented, we could perform some runtime tests to find out the actual performance impact, but I'm skeptical about this...
Merging meshes into one (current approach) helps a bit, but only until amount of pieces will become really large.
Actually the current approach doesn't just merge meshes, the game does only generate a single mesh right from the beginning: It allocates a native buffer large enough to hold the vertices of all construction elements in a chunk, then the game goes through all elements and calculates their individual vertex positions (depending on the element rotation, size, surface offset etc) and stores them in the buffer. Eventually it generates a single mesh from the populated buffer. This is quite fast and also keeps memory allocations and garbage at a minimum 
Was für ein Windows verwendest du genau? Home oder Professional?
To a certain degree, this was actually already possible in the Java version, at least through the plugin API: An admin could just become invisible, then teleport to a player and watch what he's doing.
Glas mit zwei verschiedenen Seiten wäre zwar machbar, aber Spiegel sind generell etwas heikel - da stoßen die bisherigen Reflektionen, die wir drin haben (zB für Marmorböden), leider zu schnell an ihre Grenzen. Für richtige Spiegel brauchen wir andere Reflektionen, welche allerdings auch hinsichtlich der Performance deutlich teurer sind. Das ist zwar langfristig geplant, aber leider kann ich dazu momentan noch nicht viel sagen 
War das in der Java Version anders?
The current paint roller and color selection is just a placeholder 
Das werden wir mit dem nächsten Update beheben!
Auf MP Servern so oder so hilfreich, denn dort wird es immer spezielle Dinge geben, die durch ein Wiki nicht abgedeckt werden könnten (zB bestimmte Befehle für Plugins, Serverregeln, ggf. Links zu Website oder Discord usw).
