F8 Tool Option zum Verbinden von Blöcken

Gute Idee! Allgemein ein "Bauwerk-Simplifizierungs-Werkzeug". Das ist gar nicht mal so unwichtig für Rising World, da man über die Zeit extrem viele Bauteile auf kleinem Raum hat und die Performance somit vielleicht noch ein wenig verbessern könnte.

Ich meine, dass das Spiel fürs Rendern schon einige Performance-Tricks anwendet aber die Reduzierung der Bauteile würde wahrscheinlich den Arbeitsspeicher (und Weltgrößen) weniger belasten. Ich weiß leider nicht, wie signifikant das am Ende ist, aber auf Papier klingt das schon gut.

Mein Vorschlag wäre ein Menü zur Verwaltung von Objektdateien. Eine .obj Datei im Spielverzeichnis sollte von dort aus praktischerweise direkt erkannt und platziert werden können. Ein Einklickwechsel zwischen Objekt- und Blueprint- Menü würde den Kreis schön abrunden. Vom Blueprint Menü aus geht die Objekt Datei dann rüber ins Objekt Menü.

Objektdateien haben ja nur eine Oberfläche und es gibt sogar jetzt schon die Möglichkeit Blueprints als .obj zu speichern und zum Beispiel in 3D auszudrucken. Hat da mal jemand was gemacht?

Dass sich mehrere Blöcke zu einem verbinden fände ich ansonsten nur bei Glas interessant.

Quote from Nebeltrinker

Mein Vorschlag wäre ein Menü zur Verwaltung von Objektdateien. Eine .obj Datei im Spielverzeichnis sollte von dort aus praktischerweise direkt erkannt und platziert werden können. Ein Einklickwechsel zwischen Objekt- und Blueprint- Menü würde den Kreis schön abrunden. Vom Blueprint Menü aus geht die Objekt Datei dann rüber ins Objekt Menü.

Objektdateien haben ja nur eine Oberfläche und es gibt sogar jetzt schon die Möglichkeit Blueprints als .obj zu speichern und zum Beispiel in 3D auszudrucken. Hat da mal jemand was gemacht?

Dass sich mehrere Blöcke zu einem verbinden fände ich ansonsten nur bei Glas interessant.

Deine Idee ist, dass man Blaupausen auch zu Objekten konvertierten kann für mehr Performance? Wenn ja, stimme ich dir zu, dass das praktisch wäre. Allerdings enthalten .obj-Dateien nur geometrische Informationen und keine Texturen, weswegen das leider nicht so einfach ist. Zudem müsste die Geometrie für Objekte noch zusätzlich optimiert werden wegen Voxeln, die nicht sichtbar wären usw.

Also aus Sicht der Performance macht es einen enormen Unterschied mit wie vielen Teilen man baut bzw. auf wie engem Raum. Weshalb ich mir ja Jahre lang den Mund fusselig geredet habe (Denke dran, du willst das Gebäude noch einrichten usw.) Seit Beginn der Unity arbeite ich deshalb fast immer mit Teilen in passender Größe. Lässt sich meiner Meinung nach auch viel besser mit Arbeiten, bei 3 Mio Punkten an der Wand würde ich verrückt werden.

Vom bemalen & abreißen fange ich besser gar nicht erst an

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

Im Folgen Bild sieht man die Nähte ziemlich gut. Die Glasblöcke liegen im Gegensatz zum Mauerwerk bündig ineinander (Die Stufen in der Mauer wurden erst im nachhinein erstellt)

Dinge wie dieser Teppich lassen sich übrigens auch nicht mit 1x1 Blöcken bauen, hier werden klare Mittel - & Endpunkte benötigt

Bei getrübtem Glas sieht das ganze dann schon besser aus, bzw. fällt es nur auf, wenn man direkt davor steht

Ich habe schon mit (und für) Unity modelliert und programmiert.

Einfach gesagt, es geht: vereinfachen, verschmelzen oder Meshes aufteilen.

Technisch möglich, nur rückgängig (aufteilen) ist nicht so einfach wenn ihr die gleichen Teile wieder haben wollt.

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

- Absolute Mesh Combiner

Kombiniert Meshes und Submeshes in einem einzigen Objekt,

passt UVs an, Optimierung der Polygonanzahl.

- Advanced Merger Toolkit

- Mesh Baker

- 3D Collider Utility 2 - Merge and Combine

Sorry, musste dieses Bild einfach nochmal ausbuddeln weil es einfach perfekt zum Thema passt.

Es zeigt meinen bisher schwierigsten Umbau.

Zielobjekt: Rüdis Bus

Eine der besten Blaupausen, welche je geteilt wurden

Die Umsetzung ist makellos & wunderschön. Wenn man sich den Reifen aber zu sehr genähert hat, wurde man praktisch hinein gesogen & war so gut wie Bewegungsunfähig (auch im Flugmodus)

Deshalb kommen Dinge mit zu vielen Teilen (so schon & detailliert sie auch sein mögen) in die Kategorie "Schwarzes Loch"

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

Quote from Forscherdrang

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

Quote from Kryssi_79

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

Glaube ich habe ungefähr die hälfte davon verstanden ( vielleicht auch nur die hälfte der Hälfte )

Am besten alles so lassen, wie es ist

Denn eines steht fest, ich die Kontrolle in RW über alles.

Nirgendwo sonst kann man so schön Gott spielen

Zum Thema Glas habe ich hier noch 2 Bilder aus dem selben Turm wie oben.

Im Inneren wurde nämlich eine 3-fach Verglasung angewendet.

Während man aus dem Flur in die Räume hinein gucken kann ,

sind sie zur selben Zeit aus Sicht der Räume getönt

Quote from SonoBionda

hat auch was beruhigendes 1x1x1 Blöcke mit der Spitzhacke weg zu kloppen

Ist mir neu, könnte da jedes mal komplett ausrasten GEFAHR

Ab 20 Teile muss Die Bohrmaschine oder das kreative Lösch-Werkzeug ran

Quote from SonoBionda

nö nö ... mein ursprünglich simpler Vorschlag scheint ja nicht unmöglich zu sein

worum ging es nochmal, der Spawner oder das Elemente verbinden ?

- NPC Spawner

- Teile verbinden ( selbst ist die Frau oder auch der Baumeister )

Besiege deinen inneren Schweinehund & erwecke den Drachen der Erbauer in dir

Quote from Nebeltrinker

Mein Vorschlag wäre ein Menü zur Verwaltung von Objektdateien. Eine .obj Datei im Spielverzeichnis sollte von dort aus praktischerweise direkt erkannt und platziert werden können. Ein Einklickwechsel zwischen Objekt- und Blueprint- Menü würde den Kreis schön abrunden. Vom Blueprint Menü aus geht die Objekt Datei dann rüber ins Objekt Menü.

Objektdateien haben ja nur eine Oberfläche und es gibt sogar jetzt schon die Möglichkeit Blueprints als .obj zu speichern und zum Beispiel in 3D auszudrucken. Hat da mal jemand was gemacht?

Dass sich mehrere Blöcke zu einem verbinden fände ich ansonsten nur bei Glas interessant.

Ja, das funktioniert tatsächlich ganz gut 😊

Die .obj-Datei kann man einfach in Blender importieren und anschließend als .stl exportieren.

Damit lässt sie sich dann problemlos in einen Slicer laden und auf dem 3D-Drucker ausgeben.

Auf die Idee bin ich übrigens durch meine gute Freundin swuerzi68 gekommen – danke nochmal dafür! 👍

red51 Also ist jeder Chunk eine Art akualisierbares Objekt, das war das fehlende Puzzleteil.

Durch die Verdeutlichung mit dem Bus ist der ursprüngliche Vorschlag erst eingesickert.

Ich finde es elegant, vielleicht könnte man es mit einer Röntgenbrille abrunden.