Einzelnen Beitrag anzeigen
Alt 25.01.2013, 10:05   #852 (permalink)
flickflack
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

Zitat von burns Beitrag anzeigen

All die Einzelteile erhöhen aber (und jetzt kommt mein Laienverstand der Sache) den Sectioncount des Modells, und somit die Anzahl der zu ladenden Texturen erheblich.
Das ist schon bei "normalen" Modellen wie Hubschraubern oder Autos, wovon man evtl. mal 10-20 Stück gleichzeitig auf der Karte sieht, wichtig zu beachten.

Bei Häusern wo die ganze Insel mit zugepflastert ist wohl noch eher.


Nicht unbedingt dasselbe Problem aber ähnlich: Irgendeinen Grund muss es ja haben das Zargabad noch schlechter läuft als sowieso schon, wenn man per Funktion im 500m Radius alle Häuser zerdeppert.

Glaub ich nicht - für alles was NICHT RV ist

Es gibt ja Textur-Koordinaten. Damit bestimme ich auf einem Objekt, wie die Texel einer Textur auf dem Objekt zu sehen sind.
Dafür schreibt man sich noch nen Imageparser, der eine große Textur (Bild) hält und in der Lage ist, mittels Rectangle-Coords eine Textur (den Ausschnitt) aus einem bestimmten Bereich des Bildes zurückzuliefern (In irgendeiner Engine heißt s.ä. imho Supertexture oder sowas). Im Grunde also ne uralte Sprite-Mechanik.
Wenn alle Objekte zusammen eine Oberfläche "Hauswand" ergeben, dann entsteht so auch ein komplettes Bild der Wand.
Fehlt ein Stück, fehlt eben auch der Bereich der Textur, der an dieser Stelle angezeigt worden wäre.

Man muss da nicht zwingend mehrere Texturen aus dem Filesystem laden, oder sie prozedural erzeugen. Ich lade eine Textur, die die gesamte Wand darstellt und referenziere für die Zerstörungsobjekte eben einen Satz an "Ausschnitten" aus einer riesen Textur. Dass Speicher anfällt, wenn viele dieser Objekte zu sehen sind, ist nicht verhinderbar ne. Das VRAM will schon etwas gebürstet werden. Aber man kann tricksen, in dem man einfach versucht bspw. BUS-Bandbreite zu sparen. Alles was schon auf der GPU läuft und da im VRAM rumhängt, kann man eigentlich auch direkt im VRAM kopieren. Besonders bei Allem was gleich aussieht, oder leicht gruppierbar ist: Gras (5 Arten), Büsche (10 Arten), Häuser (20 Arten).

Die Kosten für viele Häuser in einer Szene könnte man mit Geometry Instancing (Kopieren eines Objekts mehrfach in der Szene) unten halten. Allerdings müsste man mal probieren, wie sich das mit einer semi-dynamischen Zerstörbarkeit der Häuser zusammenpacken lässt. Ich glaube das funktioniert nur dann noch, wenn es die aktuelle, leicht statische Implementierung der Zerstörung ist, weil es da ja vllt maximal 4 Zustände (dufter Zustand -> bissel kaputt -> noch doller kaputt -> total im Arsch) gibt, die triggerbar wären. Es ist iirc ne Grundvoraussetzung für Instancing, dass nur wenige Parameter unterschiedlich definiert werden können. Also meinetwegen die Framepositionen in einer Animation der Spielfigur, die unterschiedlich sein können. Hier könnte man ja ansetzen. Falls nicht schon ist, was ich glaube.

€: Das Geruckel kommt wohl auch daher, dass lauter Partikel gespawnt werden, wenn ein Haus teilweise, oder komplett zerstört wird. Wenn man die Partikel jetzt mehrfach zündet, ... Das Partikelsystem ist ja auch etwas betagt.
flickflack ist offline   Mit Zitat antworten