|
||
| Thema: Re:Crosspost aus einem anderen Forum ... | Antwort auf: Re:Crosspost aus einem anderen Forum ... von nazgul | |
| >>Da gibts durchaus noch weitere Vorteile ... dieses angesprochene "you can change the mountaintop" zb ist auch hier missverstanden worden. Natuerlich ist es prinzipiell an die Contentersteller gerichtet. Aber es hat auch ganz konkrete Vorteile fuer implementierbare Spieleraktionen weil es bei dieser Technik die Performanz nicht beeinflusst. > >Das verstehe ich wieder mal nicht. Irgendwo müssen die neuen geänderten Geometriedaten der veränderten Oberfläche/Textur doch dauerhaft gespeichert werden, was irgendwann die Performanz beeinflussen muss. > >In Red Faction war z.B. nicht alles zerstör- und veränderbar, weil dies ansonsten die "Statik" innerhalb des Spieles zerstört hätte. > >Wenn ich mir diese zwei Punkte ansehe, welchen Vorteil für den Spieler hat die neue Engine dann? Du darfst bei Veraendern nicht gleich an Zerstoeren von Geometriedaten denken. In der Basis ist das immer noch eine MegaTEXTURE. Nehmen wir also das einfache Beispiel von Einschussloechern. Realisiert ueber Decals. Bisher im tilebasierten Textureassetrendering (Begriff von mir kreiert!! ... also nicht woertlich nehmen :): Fuer jedes Einschussloch wird die Position gespeichert und dann als uebergeblendete Textur auf die Wand gepappt. Je mehr Schuesse du abgibst desto mehr dieser Decaloperationen sind noetig. Jedesmal wird eine Textur (also ein Polygon) in die Renderpipeline uebergeben, diese muss gerendert und geblendet werden. Wie man sieht skaliert der Aufwand linear mit Anzahl der Schuesse. Bedenkt man dass es Flaschenhaelse geben kann (Batschaufrufe pre DX10 sind zb sehr teuer) kann es mal zu einem fatalen Framerateneinbruch kommen. Nicht zu vergessen unschoene Effekte die auf eine unsauebere Implementierung zurueckzufuehren sind. Wie zb "schwimmende", "schwebende" und anderweitig von der Wandtextur eindeutig abgetrennten Einschussloecher. Hast du sicher mal gesehen wenn du genauer hingeschaut hast. Unique Texturing: Du *arbeitest* direkt auf der Leveltextur (bzw genauer wohl einer Kopie der Originaldaten die auf dem Datentraeger gespeichert ist). Jeden Pixel der Leveltexturen kannst du damit direkt und unmittelbar veraendern. Du brauchst keine neuen Polygone erzeugen und per Blending rendern. Du hast keine "Schwimm"-Effekte. Du hast keine Beschraenkung wieviel Einschussloecher du darstellen kannst. Nach jedem Schuss muss lediglich (und das klingt trivial ... ist es aber sicher nicht, wenn man die drunterliegenden Datenstrukturen samt Mipmapping Hierarchie bedenkt) eine Textur modifiziert werden. Danach musst du die Textur nicht mehr anfassen ... Get the idea? Dieser ganze, an sich intuitive Ansatz Texturen direkt und on the fly zu modifizieren, funktioniert bei Texture Tile Asset Rendering ebend darum nicht, weil eine Textur unter Umstaenden zig mal in einem Level eingesetzt wird. Und keiner moechte das selbe Einschussloch an jedem Haus wiederfinden nur weil diese identisch texturiert wurden, oder? >>Weiss denn niemand mehr wie Decals (die frueher oft fuer Einschussloecher benutzt wurden) die Performance mit der Zeit ins Bodenlose sinken haben lassen? Warum die meisten Decals nur temporaer in tilebasierten Texturengines integriert wurden und nach einer gewissen Zeit "verschwinden"? > >Die werden heute noch eingesetzt. Spiele mal die 360-Demo von "Blacksite" und du wirst feststellen, dass die Decals dort sogar noch schneller verschwinden als damals in "Goldeneye" auf dem N64. >>So eine Megatexture hat immer den gleichen Memoryfootprint. Man kann auf ihr arbeiten und sie veraendern und die Performanz sinkt eben nicht ins Bodenlose. > >Das mit dem Memoryfootprint ist mir klar. Das mit der Performance kann ich mir im Moment nicht vorstellen, weil: Wird so eine Megatexture gestreamt? Sicherlich. Jo wird sie. Die Textur wird von der Engine natuerlich in Tiles zerlegt und diese gestreamed ... aber es sind immer individuelle Tiles und von daher weder fuer dich als Endnutzer noch fuer den Contentersteller von Belang. >Was passiert dann beim Nachladen einer bereits veränderten Texture bzw. direkt beim Verändern? Siehe oben, von wegen "dauerhaft gespeichert". Nun ja, erstens sind die 20GB nicht woertlich zu nehmen. Das laesst sich glaubhaften Angaben zufolge im Faktor 10:1 packen. Das heisst die Txturdaten fuer einen Level liegen weit drunter und auf einmal im handhabbaren Bereich. Wie das Veraendern jezt genau ablaeuft kann ich dir nicht sagen und ich vermute es auch nur ... bei Rechnern oder Konsolen mit Festplatte wuerde ich sagen liegt es nahe auf einer Kopie der Originaldaten zu arbeiten. Man darf auch nicht verwechseln dass so ein (hochgestochen formuliert) Paradigmenwechsel in der Datenstruktur weitaus staerkere Konsequenzen nach sich zieht fuer den Workflow als zb die Art der Schatten die eine Engine benutzt (Stencils oder Shadowmaps zb). Ein Moderator im beyond3d Forum hat es kurz angedeutet und ich moechte ihn kurz zitieren: To implement MT you'll need: An editor that allows painting huge textures in real time. A dedicated shader that handles all the filtering and mip-map chain complexities. A proprietary file format to store all this information (MT is more than graphics, it also handles physics interactions). An efficient algo to stream pages into memory, fill dirty pages, flush, etc. An efficient algo to decompress the huge texture (this is optional but even if you get all the above working correctly, unless you can somehow fit all the huge textures your game will use into a DVD (or two) it's not going to be practical). Finally, to see and measure the benefits of reduced polygon usage you'll need new meshes. MT steht fuer Megatexture so wie id ihr unique Texturing Konzept versteht. Wie man sieht aendert sich der Workflow grundlegend, aber durchaus zum besseren. Wie man (meiner Meinung nach) eindrucksvoll darin bestaetigt sieht, dass die Demo in 10 Tagen erstellt wurde. gruss |
||
| < Auf diese Nachricht antworten > | ||