Bevor ich auf den eigentlichen Vorschlag eingehe, möchte ich einmal kurz darauf eingehen, Blaupausen "als 1 Objekt" zu handhaben bzw. stattdessen als Modell/.obj Datei zu laden, da dieser Wunsch häufiger geäußert 
Ich möchte dabei nicht auf den spielerischen Vorteil eingehen (zB dass Blaupausen einfacher wieder entfernt werden können, wenn sie aus 1 Objekt bestünden), sondern nur auf den technischen Aspekt (um den es hier ja scheinbar auch in erster Linie geht?)
Tatsächlich ist es bereits so, dass das Spiel alle Bauelemente innerhalb eines Chunks zu einem Mesh kombiniert, d.h. man hat ohnehin nicht tausende Objekte, sondern technisch nur 1 Objekt pro Chunk. Korrekter ausgedrückt werden eigentlich auch nicht die Elemente kombiniert, es wird von vornherein nur ein einziger Mesh generiert.
Das geschieht bereits auf die technisch effizienteste Weise und auch der generierte Mesh ist auf minimalsten Memoryverbrauch hin optimiert (d.h. alle Daten pro Vertex - bis auf die Position - werden bereits als 8-Bit Wert gespeichert).
Würden Blaupausen fortan nur noch ein Modell laden (zB die exportierte .obj Datei), würde sich an der allgemeinen Performance nichts ändern. Was hingegen schneller geschehen würde wäre das Generieren des Chunks (da nicht erst der Mesh generiert werden muss, sondern sofort ein fertiges Modell geladen würde). Gleichzeitig würden aber im Multiplayer enorme Probleme hinzukommen, da ein gespeicherter Mesh wesentlich mehr Daten enthält als eine Blaupause: Derzeit ist ein einzelnes Bauelement 110 Bytes groß. Würde dieses Bauteil durch ein klassisches Modell repräsentiert (zB durch eine .obj Datei), wäre es hingegen ca. 1500 Bytes groß, also mehr als 13x soviel. Im MP müssten also wesentlich mehr Daten synchronisiert werden...
Und wie gesagt, die Performance wäre am Ende exakt dieselbe, lediglich das Generieren des Chunks wäre schneller (zumindest im Singleplayer). Gleichzeitig wären nachträgliche Änderungen (Bauteil entfernen o.ä) aber auch nicht mehr so einfach möglich.
Wenn man mit vielen kleinen Bauteilen arbeitet und Performanceprobleme feststellt, dann liegt das in erster Linie an der Anzahl der Polygone bzw. genau genommen die Vertexdichte. Wenn die Framerate alleine durch das Betrachten des Bauteils zu niedrig ausfällt, dann ist die Grafikkarte am Limit. Hier muss man aber auch immer unterscheiden, ob das Bauwerk selbst wirklich für die Performanceprobleme zuständig ist, oder ggf. andere Dinge wie die Anzahl der Lampen/Lichtquellen, Npcs o.ä.
Wenn die Framerate hingegen erst beim Berühren des Bauteils nach unten geht, dann kommt das eher von der Physik-Engine, denn diese kommt mit so feingradiger Kollision nicht gut zurecht. Das Problem kennen viele vmtl. auch noch aus der Java-Version, vor allem aus den trickreicheren Zeiten, als zB gerne mal mehrere Planken gedreht platziert wurden, um einen Zylinder zu erhalten - beim Berühren dieser Elemente ging die Performance dann in den Keller.
Aber auch hier gilt, dass man leider nichts gewinnen würde, wenn das Spiel zB stattdessen eine .obj Datei laden würde... offenbar ist das eines der häufigeren Probleme.
Unity verwendet von Haus aus PhysX 4.x, welche nicht schlecht ist (deutlich performanter ist als die Physik-Engine damals in der Java Version), aber leider nicht mehr ganz der Höhe der Zeit entspricht... in Unitys ECS gibts zwar stattdessen eine Eigenentwicklung ("Unity Physics") sowie optional auch Havok (welches definitiv performanter ist), aber ECS steckt leider generell noch in den Kinderschuhen. Theoretisch ist aber in dem Bereich noch Luft nach oben.
___________
Was das Spiel nicht macht ist eine Polygonreduktion. Das wäre in den meisten Fällen (also bei komplexen Bauwerken) leider nicht performant umsetzbar... sowas wäre ohnehin nur i.V.m. "Blaupausen werden als .obj geladen" denkbar, aber auch ein polygonreduziertes Modell würde immernoch wesentlich mehr Speicher belegen als eine Blaupause (und die o.g. Multiplayer-Probleme mit sich bringen).
Trotzdem wäre die Ersparnis nicht in allen Fällen so groß, da nur gleichartige Bauteile kombiniert werden können, d.h. Bauteile die dieselbe Textur und Farbe haben. Außerdem müssen die Bauteile exakt aneinanderliegen und die gleiche Ausrichtung haben, also so platziert sein, dass sie problemlos mit einem einzigen Bauteil repräsentiert werden könnten.
Insgesamt sind eigentlich nur folgende Optimierungen möglich bzw. denkbar:
- Andere Physik-Engine. Das würde helfen bei Performanceproblemen beim Betreten/Berühren komplexer Bauwerke. Zum aktuellen Zeitpunkt in Unity aber leider keine Option. evtl. aber in Zukunft
- Man könnte Bauwerke, die in der Ferne sichtbar sind, als "3D Imposter" darstellen (d.h. das 3D Modell wird in der Ferne durch einen "Screenshot" ersetzt). Sowas ist aber relativ kompliziert umzusetzen und wäre nur bei dicht bebauten Welten vorteilhaft (zB bei einer großen Stadt). Optisch könnte der Schwindel u.U. auffliegen
- Um die Geschwindigkeit beim Laden der Chunks zu erhöhen, könnte das Spiel bzw. der Client den fertig generierten Mesh auf der Festplatte cachen. Solange es dann keine Änderung gab, müsste der Chunk beim nächsten Mal nicht neu generiert, sondern der fertige Mesh könnte von der Platte geladen werden. Nachteil ist, dass das idealerweise eine SSD erfordert (die man für RW am besten eh haben sollte), und dass aber auch relativ viel Speicher für sowas draufgehen kann (gerade bei vielen oder komplexen Welten)
___________
Um aber auf den ursprünglichen Vorschlag zurückzukommen, sowas wäre grundsätzlich denkbar. Das wäre dann tatsächlich darauf beschränkt, dass die zu kombinierenden Bauelemente so liegen müssen, dass sie problemlos durch ein einziges Bauteil ersetzt werden könnten. Wenn zB mehrere Zylinder genau übereinandergestapelt werden, könnten diese dann hinterher durch einen langgezogenen Zylinder ersetzt werden. Oder wenn ich mehrere 1x1x1 Blöcke als Fläche oder in Reihe platziere, dass diese durch einen einzigen, breiten Block ersetzt werden könnten.
So eine Mechanik ist aber auch nicht ganz trivial umzusetzen. Es ist in erster Linie ein mathematisches Problem, kein technisches Problem
Bei Glas wäre die Verbindung tatsächlich interessant für gebogene Fenster & dergleichen.
Da ist sonst immer die Naht so stark zu sehen, besonders bei Klarglas 
Ich fürchte, dass das auf dem Screenshot oben nicht funktionieren würde, da es sich hier ja um versetzt platzierte Bauteile handelt... die könnten ja nicht durch einen einzigen Block repräsentiert werden.
Dass die Naht sichtbar ist wäre leider durch alle o.g. Maßnahmen nicht verhinderbar... dafür müssten ja die Flächen, die sich teilweise berühren, aufgebröselt und der sich überdeckende Teil entfernt werden - das ist leider aus Rechensicht noch viel komplexer, sodass man sowas leider nicht auf performancefreundliche Art umsetzen könnte 
Sinnvoller wäre hier eher, dass das Spiel Glaselemente anders rendert, sodass immer nur die vorderste Glasfläche sichtbar ist. Das ist aber möglicherweise nicht immer gewollt 
Unity bietet sowas schon an.
Z.B.
Mesh.CombineMeshes() aus Unitys Mesh-Klasse, um mehrere Blöcke zu einem Objekt zu verschmelzen.
Oder
aus der Unity asset store
[...]
Display More
Die Unity-API zum Verbinden von Meshes hat leider das Problem, dass hier Meshes quasi "wie vor 20 Jahren" verbunden werden Leider ist der Großteil der Unity-API (einschl. der CombineMeshes() Methode) nicht multithreading-kompatibel, was für RW ein KO-Kriterium ist... von Asset-Lösungen hingegen bin ich persönlich ohnehin kein Freund, da man hier essentielle Kontrolle abgibt... 
Aber wie gesagt, es gibt ohnehin nur einen einzigen Mesh, der beim Laden des Chunks dynamisch zusammengebaut wird, d.h. gar nicht erst mehrere Meshes, die verbunden werden müssten 
Grundsätzlich werden Admins wählen können, ob sie entweder selber Areas vordefinieren wollen (die dann "claimable" sind), oder ob ein Spieler eigene Areas erstellen darf, d.h. er kann sein "Claim-Objekt" platzieren und dort herum eine Area definieren (die dann natürlich nicht mit anderen Areas kollidieren darf) 
This message indeed occurs for all events which are unknown to the native side (originally it was mainly added as a reminder that a particular event does not yet have a native representation). You can ignore this message (it won't cause any trouble), but I will also fix this with the next update 
Dabei muss entweder der Server bzw. das Spiel beendet werden (oder ins Hauptmenü zurückkehren), oder alternativ kann auch der Konsolenbefehl worldbackup benutzt werden, womit von der aktuellen Welt ein Backup erstellt wird 
Dann muss ich mir die anderen 4 auch gleich mal angucken 
I will fix that with the next update (unfortunately it won't fix cooking grates that were already placed on these campfires)
