Bump Mapping glänzt viel zu sehr

[blackbox]

Hallo,
Bump Mapping an sich finde ich nicht schlecht, aber was mich bisher immer gestört hat, dass das ganze dann doch ziemlich unrealistsch wird.
Gerade in Doom3 oder Far Cry wird Bump Mapping vielfach übertrieben dargestellt.
Wenn zum Beispiel Holz derart glänzt, dann wirkt das für mich wie Metall. Andere Beispiele sind Steine, Fliesen oder rostiges Metall.
Kann man dieses übertriebene Glänzen nicht abstellen?
Wäre es nicht besser, auf Bump Mapping zu verrichten, wenn der letztendliche Effekt wie poliertes Eisen aussieht?

[Spasstiger]

Bump-Mapping bringt gar nix zum Glänzen, sondern soll einfach nur Tiefe erzeugen.
Specular Mapping ist für den Glanzeffekt zuständig und natürlich kann man dieses auch abschwächen bzw. realistischer gestalten.

P.S.: Für Doom 3 (und Addon) gibt es einen Grafikmod namens "3mood" (Doom 3 rückwärts geschrieben), mit dem ein besseres Specular-Mapping-Verfahren angewandt wird. Man kann die Parameter für das Specular Mapping selber einstellen, vielleicht findest du Gefallen an dem Tool. Läuft aber nur mit Nvidia-Grafikkarten und richtig gut auch nur mit GeForce 6 Karten und den aktuellsten Beta-Treibern.

[Gast]

bei doom3 finde ich es eigentlich ganz gut, da ist ja praktisch alles aus metall, bzw. dieses organische etwas, das soll ja glänzen.

bei farcry ist es imo übertrieben, aber der grafikstil ist im ganzen so dass alles etwas übertrieben dargestellt wird, wie das blaue meer, ich nenn es mal "postkartengrafik".

du könntest dort z.b. den rendermodus "kalt" einstellen, das sollte auch die reflexionen etwas abschwächen.

HL2 setzt auch auf bump-mapping, glänzend ist da aber kaum was, der glanz würde erst vom specular-mapping kommen.

ziemlich gut gelöst finde ich das ganze in SC3. am anfang ist dort kaum ein glänzen vorhanden, wenn es aber zu regnen beginnt wird es schön stärker, um dann wieder schwächer zu werden wenn sam beispielsweise ein haus betritt.

[Oblivion]

Also bei D3 kann ich deinen Gedanken nicht ganz nachvollziehen - wenigstens etwas licht in dem Spiel und zweitens trägts eindeutig zur Atmosphäre bei - aber ok, Geschmäker sind verschieden

Ein Spiel wo mir das Specular Mapping besonders aufgefallen ist, ist Guild Wars - dort glänzt wirklich alles :wink:

aber es trägt auch irgendwie zur Atmosphäre bei

[Mr. Lolman]

iirc wollte Demirug mal nen Regler für die Intensität des Specularmapping in seinen DXTweaker einbaun...

[Coda]

Das ist doch gar nicht generell möglich. Das ganze ist ja nur eine mathematische Formel im Shader, die man auch beliebig abändern kann.

[zeckensack]

Hallo,
Bump Mapping an sich finde ich nicht schlecht, aber was mich bisher immer gestört hat, dass das ganze dann doch ziemlich unrealistsch wird.
Gerade in Doom3 oder Far Cry wird Bump Mapping vielfach übertrieben dargestellt.
Wenn zum Beispiel Holz derart glänzt, dann wirkt das für mich wie Metall. Andere Beispiele sind Steine, Fliesen oder rostiges Metall.
Kann man dieses übertriebene Glänzen nicht abstellen?
Wäre es nicht besser, auf Bump Mapping zu verrichten, wenn der letztendliche Effekt wie poliertes Eisen aussieht?Das wird deswegen gerne übertrieben, damit man es auf Screenshots richtig doll sieht, dass da Shader genutzt werden :uup:

Diese Einstellung hat durchaus Vorteile. ZB geben dann nicht mehr diverse Besserwisser so uninformiertes Zeugs wie zB "UT2k3 ist ein DX7-Spiel" von sich, und andere ähnliche Nullaussagen.
Es ist heute für Publisher und Entwickler enorm wichtig, dass ihre Produkte möglichst "modern"(!=realistisch) wirken. Spielezeitschriften und "fans" haben uns das eingebrockt.

[Spasstiger]

Es ist heute für Publisher und Entwickler enorm wichtig, dass ihre Produkte möglichst "modern"(!=realistisch) wirken. Spielezeitschriften und "fans" haben uns das eingebrockt.

Die Next-Gen-Spiele können aber auch sowohl mit moderner Optik als auch mit Realismus glänzen. Man schaue sich nur mal die Screens von Project Gotham Racing 3 an, das Lightning und die Lackeffekte sind eine Wucht.

[Gast]

Die Next-Gen-Spiele können aber auch sowohl mit moderner Optik als auch mit Realismus glänzen. Man schaue sich nur mal die Screens von Project Gotham Racing 3 an, das Lightning und die Lackeffekte sind eine Wucht.

bei einem rennspiel auch nicht schwer, der lack soll ja glänzen ;)

wenn man aber zu wenig szenen hat die glänzen, wird dieser glanz eben einfach irgendwie erzeugt ;)

[zeckensack]

Die Next-Gen-Spiele können aber auch sowohl mit moderner Optik als auch mit Realismus glänzen. Man schaue sich nur mal die Screens von Project Gotham Racing 3 an, das Lightning und die Lackeffekte sind eine Wucht.Zu PGR3 finde ich viele Bilder, auch ganz tolle Montagen btw, aber nur wenige (durchgängige) Screenshots.

Screenshots sehen ja eher so (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=4) aus, und toll finde ich das ehrlich gesagt nicht.

Wenn du mit dem Spiel hauptsächlich wegen der Grafik liebäugelst, würde ich dir dringend dazu raten das Teil erstmal aus der Videothek ausleihen ...

[Demirug]

Diese Einstellung hat durchaus Vorteile. ZB geben dann nicht mehr diverse Besserwisser so uninformiertes Zeugs wie zB "UT2k3 ist ein DX7-Spiel" von sich, und andere ähnliche Nullaussagen.

Der eine Pixelshader (aus Performancesgründen) macht den Bock aber auch nicht fett.

[Kladderadatsch]

Zu PGR3 finde ich viele Bilder, auch ganz tolle Montagen btw, aber nur wenige (durchgängige) Screenshots.

Screenshots sehen ja eher so (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=4) aus, und toll finde ich das ehrlich gesagt nicht.

aber der lack (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=2);)

[Coda]

Das ist allem Anschein nach eine HDR Cubemap :)

[zeckensack]

Der eine Pixelshader (aus Performancesgründen) macht den Bock aber auch nicht fett.Performance-Gründe sind auch gute und gültige Gründe für Shader. Die müssen einem nicht immer sofort ins Gesicht springen, finde ich. Es ist aber auch egal wie fett der Bock ist, wenn das Spiel die von den Entwicklern gewünschte Optik auf den Schirm bringt. Viele Wege führen nach Rom. Es gibt auch Leute die diffuse Bumps und per-pixel specular ganz ohne "Shader" hinkriegen, also wayne?

Und dass man zB die Nutzung von Vertex Shadern einfach nicht "sehen" kann, haben auch die wenigsten begriffen. Ganz voran die Leute die auch Zusammenhänge zwischen Engine-Fähigkeiten und matschigen Texturen zu erkennen glauben.

Es ist bestenfalls Zeitverschwendung, ein Spiel nach dem "Technologie-Level" zu klassifizieren. Entweder es sieht gut aus, oder eben nicht.

Ich habe auch schon mehrfach die Hände über dem Kopf zusammengeschlagen, wenn ich lesen musste dass zB Doom 3 "DX7-Level" sei ... weil es auf einer Geforce 1 läuft. Ich frage mich wem mit solchen "Erkenntnissen" geholfen ist. Mir jedenfalls nicht.

Was ich eigentlich sagen wollte war ja dass ein Spiel grafisch möglichst modern wirken muss, damit es vom Markt akzeptiert wird. Und dafür ist es eben zu vermeiden dass irgendjemand glaubt (!=weiß) es wäre "DXn-Level" mit n<=8. Im Konflikt dazu steht dann dass es eigentlich positiv ist, wenn man sich die Mühe macht ein Spiel auch noch auf MXen und ähnlich veraltetem Krempel nett aussehen zu lassen. Teufelskreis.

[Coda]

Es gibt auch Leute die diffuse Bumps und per-pixel specular ganz ohne "Shader" hinkriegen, also wayne?Klar, macht Doom 3 ja auch auf DX7 HW :)
Allerdings ist das gar nicht mal so ein Problem, wie du sicher weißt.

Es ist bestenfalls Zeitverschwendung, ein Spiel nach dem "Technologie-Level" zu klassifizieren. Entweder es sieht gut aus, oder eben nicht.Ack!

[zeckensack]

aber der lack (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=2);)Das ist kein Screenshot.

[Coda]

Das ist kein Screenshot.Ich bin mir da nicht so sicher... Das HDR Zeugs assoziiert man sofort mit einem offline-rendering, weil es das bisher noch nicht gab auf realtime HW.

[Demirug]

Performance-Gründe sind auch gute und gültige Gründe für Shader. Die müssen einem nicht immer sofort ins Gesicht springen, finde ich. Es ist aber auch egal wie fett der Bock ist, wenn das Spiel die von den Entwicklern gewünschte Optik auf den Schirm bringt. Viele Wege führen nach Rom. Es gibt auch Leute die diffuse Bumps und per-pixel specular ganz ohne "Shader" hinkriegen, also wayne?

Und dass man zB die Nutzung von Vertex Shadern einfach nicht "sehen" kann, haben auch die wenigsten begriffen. Ganz voran die Leute die auch Zusammenhänge zwischen Engine-Fähigkeiten und matschigen Texturen zu erkennen glauben.

Es ist bestenfalls Zeitverschwendung, ein Spiel nach dem "Technologie-Level" zu klassifizieren. Entweder es sieht gut aus, oder eben nicht.

Ich habe auch schon mehrfach die Hände über dem Kopf zusammengeschlagen, wenn ich lesen musste dass zB Doom 3 "DX7-Level" sei ... weil es auf einer Geforce 1 läuft. Ich frage mich wem mit solchen "Erkenntnissen" geholfen ist. Mir jedenfalls nicht.

Was ich eigentlich sagen wollte war ja dass ein Spiel grafisch möglichst modern wirken muss, damit es vom Markt akzeptiert wird. Und dafür ist es eben zu vermeiden dass irgendjemand glaubt (!=weiß) es wäre "DXn-Level" mit n<=8. Im Konflikt dazu steht dann dass es eigentlich positiv ist, wenn man sich die Mühe macht ein Spiel auch noch auf MXen und ähnlich veraltetem Krempel nett aussehen zu lassen. Teufelskreis.

Aus rein technologischer Sicht ist es doch aber OK zu ergründen welche Rendertechniken ein Spiel nutzt?

Für mich gehört Dot3 Bumpmapping noch eindeutig zur pre DX8 Technologie.

[zeckensack]

Ich bin mir da nicht so sicher... Das HDR Zeugs assoziiert man sofort mit einem offline-rendering, weil es das bisher noch nicht gab auf realtime HW.Wie bereits verlinkt, im echten Leben sieht das anders aus: Klück (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=4).

Die "Shots" sind größtenteils Montagen, die bewußt schwache Grafik bzw typische CGI-Fehler enthalten, um noch als echt durchzugehen.

Schau dir mal hier (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=3) den Straßenbelag an. Nee, oder? :usweet:

Auf anderen "Shots" ist's wieder genau umgekehrt, da sieht die Straße übel aus, dafür sind die Autos zu schön um wahr zu sein.

In dem konkreten Fall denke ich mir das so:
1)Die Windschutzscheibe ist die absichtlich schlechte CGI, damit's noch nach Screenshot aussieht. Ebenso die Bodentextur. Der Hintergrund ist eigentlich egal.
2)Der Schatten ist womöglich gar ein Photoshop-Job (kuckst du mal auf die Fransen, ja wo kommen die denn bitte her? Bumps? Hähä ja klaaar!)
3)Der Rest ist zu schön um wahr zu sein. Man beachte das Motion blur auf dem Rad. Wieviele temporale samples sind das denn? IMO mindestens fünf, oder gleich ein echtes "Drehungsintegral" aus der Bildbearbeitung deines Vertrauens.

Bonusfrage 1: was meinst du wie hoch die environment map aufgelöst sein muss, um die Spiegelung in dieser Qualität zu erreichen?
Bonusfrage 1,5: was genau spiegelt sich da eigentlich?
Bonsufrage 2: wo sind eigentlich die Lichter in dieser Szene?

[Oblivion]

Schau dir mal hier (http://www.gamespot.com/xbox360/driving/projectgothamracing3/screens.html?page=3) den Straßenbelag an. Nee, oder? :usweet:


Weiß wer wann der Screen gemacht wurde? Weil das Gitter kann man erst seit dem G70 so darstellen

[Coda]

Öhm nicht wirklich. Mit Alpha Blending geht das schon immer.

[blackbox]

Hey Leute, können wir zum Thema zurückkehren? :wave2:

Mir ist es völlig egal, welche Technik dahinter steht.

Auf jeden Fall gefällt mit dieses Glänzen nicht. Bisher habe ich es immer mit Bump Mapping verbunden, aber wenn dem nicht so ist, warum sieht es dann immer so metallisch aus? Als wenn jede Oberfläche einen frischen Lack erhalten hat.
Muss das denn so sein?
Wenn durch Bump Mapping Tiefe erzeugt werden soll, das Ergebnis aber wie Metall aussieht, dann kann ich gerne darauf verzichten. Dann sollen meinetwegen andere hochaufgelöste Texturen benutzt werden.
Leider habe ich keine Geforce6 und kann deshalb den Grad des Glänzens auch nicht einstellen.

[Coda]

Muss das denn so sein?Nein - siehe Half-Life 2.

[TrigPe]

Hey Leute, können wir zum Thema zurückkehren? :wave2:

Mir ist es völlig egal, welche Technik dahinter steht.

Auf jeden Fall gefällt mit dieses Glänzen nicht. Bisher habe ich es immer mit Bump Mapping verbunden, aber wenn dem nicht so ist, warum sieht es dann immer so metallisch aus? Als wenn jede Oberfläche einen frischen Lack erhalten hat.
Muss das denn so sein?
Wenn durch Bump Mapping Tiefe erzeugt werden soll, das Ergebnis aber wie Metall aussieht, dann kann ich gerne darauf verzichten. Dann sollen meinetwegen andere hochaufgelöste Texturen benutzt werden.
Leider habe ich keine Geforce6 und kann deshalb den Grad des Glänzens auch nicht einstellen.

Hallo,

ich kann dich gut verstehen. Mir geht das ganze "geglänze" auch aufn Sack. Ich hab heute nach langer Zeit mal wieder Serious Sam gespielt. Was soll man sagen, gestochen scharfe und schöne Texturen.
Warum gibts das heute nicht mehr?

MfG

[Spasstiger]

Nein - siehe Half-Life 2.

Wollte ich auch eben schreiben ;).

Einer meiner Lieblingsscreens von PGR3 ist folgender:
http://img99.echo.cx/img99/851/bilder91120ux.jpg

Das Lightning wirkt äußerst realistisch dank HDR-Rendering.

[Coda]

Ich sehe da keinen Blitz - außerdem ist es doch "Der Blitz" und nicht "Das Blitz"? Jetzt bin ich verwirrt.

[Spasstiger]

Ich sehe da keinen Blitz - außerdem ist es doch "Der Blitz" und nicht "Die Blitz"? Jetzt bin ich verwirrt.
??

Lightning = Beleuchtung (Lightning als quasi-deutsches Wort ;))
Oder auf was beziehst du dich?

[Coda]

Lighting = Beleuchtung, nicht Lightning = Blitz.

[Spasstiger]

Lighting = Beleuchtung, nicht Lightning = Blitz.

Jupp, es gibt aber in der Rollenspielersprache den Lightning-Bolt als Synonym für einen magischen Blitz, um den Gegner zu attackieren.
Egal, ich meinte ja Beleuchtung.

[Coda]

Hä?

Das Lightning wirkt äußerst realistisch dank HDR-Rendering.Ergibt der Satz für dich bei richtiger Übersetzung irgend einen Sinn?

kA warum das Deutsche so oft falsch machen, ich les überall von Blitzen wenn Beleuchtung gemeint ist.

[Spasstiger]

Hä?

Ergibt der Satz für dich bei richtiger Übersetzung irgend einen Sinn?

kA warum das Deutsche so oft falsch machen, ich les überall von Blitzen wenn Beleuchtung gemeint ist.

Es heißt ja auch Transform & Lightning. Lightning sehe ich auf den ersten Blick immer als Synonym für Beleuchtung.

EDIT: Ups, es heißt Transform & Lighting. Wieder was dazugelernt ;).

[Coda]

Ja, hast du. Lightning ist nunmal der Blitz.

Und dafür brauch ich jetzt 4 Posts, ist das so schwer zu verstehen?

[Spasstiger]

Ja, hast du. Lightning ist nunmal der Blitz.

Und dafür brauch ich jetzt 4 Posts, ist das so schwer zu verstehen?

Schlag mich ;D .
Jetzt aber wieder back to Topic.
Wir waren da stehen geblieben, dass Half-Life 2 auch Bump-Mapping verwendet, aber nicht diesem Plastiklook wie Farcry in den Innenlevels und bei den Models aufweist.

[Xmas]

Weiß wer wann der Screen gemacht wurde? Weil das Gitter kann man erst seit dem G70 so darstellen
Das geht schon immer, vor allem aber geht es besser als in dem Bild.

[up¦²]

Kann Bumpmapping nicht ein bissel mit FUR aufgeraut werden?

um eben diesen Hochglanzeffekt zu kompensieren :confused:

[Coda]

Öhm können schon, aber Fellsimulation ist sau teuer.

Einfacher wäre es doch einfach das Specular auf ein realistisches Level zurückzufahren, auch wenn man die ach-so-tollen Bumpmaps dann nicht mehr ganz so stark sieht.

Mir fällt das Bumpmapping in HL² erst auf wenn ich's ausschalte z.B. ;)

[Oblivion]

Das geht schon immer, vor allem aber geht es besser als in dem Bild.

Mit dem G70 oder auch schon vorher?

[AnPapaSeiBua]

Mit Supersampling doch kein Problem. Das geht doch schon lange.

[Coda]

Mit dem G70 oder auch schon vorher?Auch schon vorher. Einfach Alpha Blending statt Alpha Testing. Muss man halt die Szene von hinten nach vorne rendern, deshalb nehmen manche lieber Testing.

[DrumDub]

Auch schon vorher. Einfach Alpha Blending statt Alpha Testing. Muss man halt die Szene von hinten nach vorne rendern, deshalb nehmen manche lieber Testing. alpha blending kostet aber massig cpu-last. zumindest ist das iirc wohl er grund warum es nicht häufig eingesetzt wird. das letzte mir bekannte spiel wo es wohl benutzt wurde, war ja xpand rally.

[Coda]

Muss man halt die Szene von hinten nach vorne rendern, deshalb nehmen manche lieber Testing.Und was habe ich geschrieben?

Immer wenn irgendwas halbtransparent ist ist es Blending und nicht Testing.

[Gast]

alpha blending kostet aber massig cpu-last. zumindest ist das iirc wohl er grund warum es nicht häufig eingesetzt wird. das letzte mir bekannte spiel wo es wohl benutzt wurde, war ja xpand rally.


nicht nur, es hebelt auch die early-z-funktionen aktueller grafikkarten (zumindest partiell) aus un kostet damit massiv an overdraw, nicht zu vergessen die zusätzliche bandbreite beim blenden.

[DrumDub]

nicht nur, es hebelt auch die early-z-funktionen aktueller grafikkarten (zumindest partiell) aus un kostet damit massiv an overdraw, nicht zu vergessen die zusätzliche bandbreite beim blenden. ja, stimmt. das ist natürlich das, was coda meinte.

[Neomi]

alpha blending kostet aber massig cpu-last. zumindest ist das iirc wohl er grund warum es nicht häufig eingesetzt wird. das letzte mir bekannte spiel wo es wohl benutzt wurde, war ja xpand rally.

Alphablending kostet grundsätzlich keine CPU-Zeit. Die nötige Sortierung der zu zeichnenden Objekte (die auch aus anderen Gründen sinnvoll sein kann) zwar schon, aber das ist dann doch zu grob zusammengewürfelt.

Mit fällt jetzt auch kein Spiel der letzten Jahre ein, das kein Alphablending nutzt.

[DrumDub]

Alphablending kostet grundsätzlich keine CPU-Zeit. Die nötige Sortierung der zu zeichnenden Objekte (die auch aus anderen Gründen sinnvoll sein kann) zwar schon, aber das ist dann doch zu grob zusammengewürfelt.

Mit fällt jetzt auch kein Spiel der letzten Jahre ein, das kein Alphablending nutzt. moment. far cry, hl2, nfs:u2 und etliche andere spiele nutzen eben nur alpha testing für bäume, zäune etc., weshalb diese kanten eben nicht vom msaa erfasst werden. alpha bleding, so wie es xpand rally durchgehend nutzt, ermöglicht die anwendung von msaa auf ads ganze bild, bedeutet aber eben die entsprechende nachteile bei der leistung. oder bin ich jetzt völlig auf dem holzweg?

[Ganon]

Weiß wer wann der Screen gemacht wurde? Weil das Gitter kann man erst seit dem G70 so darstellen

Ähm, warum? Würde mich mal Interessieren.

[Neomi]

moment. far cry, hl2, nfs:u2 und etliche andere spiele nutzen eben nur alpha testing für bäume, zäune etc., weshalb diese kanten eben nicht vom msaa erfasst werden. alpha bleding, so wie es xpand rally durchgehend nutzt, ermöglicht die anwendung von msaa auf ads ganze bild, bedeutet aber eben die entsprechende nachteile bei der leistung. oder bin ich jetzt völlig auf dem holzweg?

Dafür wird zwar der gute alte Alphatest bemüht, aber das habe ich ja auch nicht bestritten. Für andere Sachen wird eben Alphablending genutzt, z.B. für Scheiben oder Lensflares. Schonmal einen Alphatest-Lensflare gesehen? Man muß sich doch nicht für Alphablending oder Alphatest entscheiden, eine Engine kann problemlos beides nutzen. Sogar innerhalb eines einzigen Drawcalls kann man beides aktiv haben. Die Aussage, Alphablending würde nicht eingesetzt, weil Alphatests verwendet werden, ist einfach nur falsch.

[Coda]

die auch aus anderen Gründen sinnvoll sein kannAber nicht von hinten nach vorne...

[DrumDub]

Dafür wird zwar der gute alte Alphatest bemüht, aber das habe ich ja auch nicht bestritten. Für andere Sachen wird eben Alphablending genutzt, z.B. für Scheiben oder Lensflares. Schonmal einen Alphatest-Lensflare gesehen? Man muß sich doch nicht für Alphablending oder Alphatest entscheiden, eine Engine kann problemlos beides nutzen. Sogar innerhalb eines einzigen Drawcalls kann man beides aktiv haben. Die Aussage, Alphablending würde nicht eingesetzt, weil Alphatests verwendet werden, ist einfach nur falsch. ah... ok. missverständnis meinerseits. wobei sich für mich immer noch die frage stellt, weshalb sich alphablending für objekte wie bäüme und zäune dann nicht durchgesetzt hat. faulheit der entwickler oder doch "nur" performance gründe.

[Demirug]

ah... ok. missverständnis meinerseits. wobei sich für mich immer noch die frage stellt, weshalb sich alphablending für objekte wie bäüme und zäune dann nicht durchgesetzt hat. faulheit der entwickler oder doch "nur" performance gründe.

Das sortieren kostet einfach sehr viel CPU Leistung und die ist bekanntermassen knapp.

[Xmas]

Aber nicht von hinten nach vorne...
Und wie unterscheidet sich BtF-Sortierung von FtB-Sortierung? ;)

Mit dem G70 oder auch schon vorher?
"Schon immer" ist doch nicht schwer zu verstehen?

Allerdings, wenn die Entwickler schon so clever sind Alpha-Blending für den Zaun zu verwenden, dann sollten sie doch eigentlich auch auf die Idee kommen, bei einer Textur die nur 45°-Winkel enthält, den Texturinhalt zu drehen statt stufige Kanten in Kauf zu nehmen. Oder die Filterung so anzupassen dass gerade Kanten herauskommen.

[Coda]

Und wie unterscheidet sich BtF-Sortierung von FtB-Sortierung?... :crazy:

[DrumDub]

Das sortieren kostet einfach sehr viel CPU Leistung und die ist bekanntermassen knapp. danke. hatte ich es doch richtig in erinnerung...

[Neomi]

Aber nicht von hinten nach vorne...

Richtig. Aber wenn man eh schon eine von vorne nach hinten sortierte Liste hat, ist es doch kein Extraaufwand mehr für die CPU, die Liste von hinten nach vorne nochmal zu durchlaufen.

[Coda]

Ja hab's grad bemerkt. Aber man sortiert ja nur die transparenten Objekte und da bringt das einem nix.

[Neomi]

Ja hab's grad bemerkt. Aber man sortiert ja nur die transparenten Objekte und da bringt das einem nix.

Och, es gibt schon Gründe für eine Sortierung von nicht transparenten Objekten. Begrenzung der maximalen Objekt- oder Dreieckszahl, auch wenn man das lieber anders abfangen sollte.

[Gast]

Och, es gibt schon Gründe für eine Sortierung von nicht transparenten Objekten. Begrenzung der maximalen Objekt- oder Dreieckszahl, auch wenn man das lieber anders abfangen sollte.


bei nicht-transparenten objekten reicht aber eine "grobe" sortierung aus, da diese sonst mehr performance kosten als bringen würde, transparente objekte müssen aber wirklich genau sortiert werden, sonst kommen so komische effekte wie in der GTA-serie zustande ;)

[zeckensack]

Allerdings, wenn die Entwickler schon so clever sind Alpha-Blending für den Zaun zu verwenden, dann sollten sie doch eigentlich auch auf die Idee kommen, bei einer Textur die nur 45°-Winkel enthält, den Texturinhalt zu drehen statt stufige Kanten in Kauf zu nehmen. Oder die Filterung so anzupassen dass gerade Kanten herauskommen.Das hatte ich mir auchgedacht. Gut zu wissen dass ich doch nicht verrückt bin :usweet:

[zeckensack]

Das sortieren kostet einfach sehr viel CPU Leistung und die ist bekanntermassen knapp.Sortieren ist doch garnicht soo teuer.
Aber ... ährm ... DX ist ja für dynamische Geometrie nicht wirklich zu gebrauchen ...

[Neomi]

bei nicht-transparenten objekten reicht aber eine "grobe" sortierung aus, da diese sonst mehr performance kosten als bringen würde, transparente objekte müssen aber wirklich genau sortiert werden, sonst kommen so komische effekte wie in der GTA-serie zustande ;)

Wenn es nur für die Zeichenreihenfolge ist, muß man nichtmal grob sortieren. Wenn es für eine generelle Begrenzung ist, reicht grob nicht aus. Ziemlich unschön, wenn von zwei entfernten Objekten abwechselnd erst das eine und dann das andere über dem Limit liegt und das dann noch synchron zum Framecounter flackert...

[Coda]

Aber ... ährm ... DX ist ja für dynamische Geometrie nicht wirklich zu gebrauchen ...Unfug. Dynamische Vertexbuffer funktionieren einwandfrei.

[zeckensack]

Unfug. Dynamische Vertexbuffer funktionieren einwandfrei.Funktionieren tut wie üblich alles.
Ich spielte auf die Performance und die Skalierbarkeit an.

[Coda]

Und was soll da anders sein als bei OpenGL? Das einzige was bei Direct3D relativ teuer ist sind Drawcalls - ansonsten gibt's kaum Unterschiede zwischen ARB_vertex_buffer_object und einem DirectX Vertexbuffer.

DirectX hat sogar noch ein "No Overwrite" Flag um zu signalisieren dass man bei einem Lock nichts überschreibt was schon zum rendering verwendet wurde. Das fehlt bei OpenGL.

[Oblivion]

"Schon immer" ist doch nicht schwer zu verstehen?


Mein Posting war auf , vor allem aber geht es besser als in dem Bild. bezogen - ob es jetzt besser geht oder früher auch schon besser ging

[zeckensack]

Und was soll da anders sein als bei OpenGL? Das einzige was bei Direct3D relativ teuer ist sind Drawcalls - ansonsten gibt's kaum Unterschiede zwischen ARB_vertex_buffer_object und einem DirectX Vertexbuffer.Wenn du größere Mengen Geometrie mit zB unterschiedlichen Texturen (Gras, Zaun, Baum, evtl noch jeweils mehrere Sorten davon) B2F sortierst und mit Blending renderst, brauchst du mehr Draw Calls als mit reinem Alpha Testing. Bei AT ist die Reihenfolge shice-egal ist, und du kannst primär nach Textur sortieren. Bei Blending ist das nicht gut genug.

Außerdem brauchst du mit reinem AT idR die Index- und Vertex-Buffer garnicht erst anzufassen. Mit Blending musst du zumindest mal dynamische Index Buffer erzeugen, und du weißt vorher nichtmal wieviele das sein werden.
Diese Updates sind auch sehr teuer, weil sie im Zweifelsfall einen impliziten Flush ausführen.

DirectX hat sogar noch ein "No Overwrite" Flag um zu signalisieren dass man bei einem Lock nichts überschreibt was schon zum rendering verwendet wurde. Das fehlt bei OpenGL.Locks sind sowieso vom Teufel, und hätten nie in VBO spezifiziert werden dürfen.

[Coda]

Wenn du größere Mengen Geometrie mit zB unterschiedlichen Texturen (Gras, Zaun, Baum, evtl noch jeweils mehrere Sorten davon) B2F sortierst und mit Blending renderst, brauchst du mehr Draw Calls als mit reinem Alpha Testing. Bei AT ist die Reihenfolge shice-egal ist, und du kannst primär nach Textur sortieren. Bei Blending ist das nicht gut genug.Richtig. Das ist aber eine generelle Schwäche von Direct3D (das die Drawcalls teuer sind) und hat nichts mit dynamischen Daten an sich zu tun.

Außerdem brauchst du mit reinem AT idR die Index- und Vertex-Buffer garnicht erst anzufassen. Mit Blending musst du zumindest mal dynamische Index Buffer erzeugen, und du weißt vorher nichtmal wieviele das sein werden.
Diese Updates sind auch sehr teuer, weil sie im Zweifelsfall einen impliziten Flush ausführen.Ack. Aber das ist bei OpenGL doch genau das gleiche :|

Locks sind sowieso vom Teufel, und hätten nie in VBO spezifiziert werden dürfen.Moment - Wie soll man sonst auf Vertexdaten zugreifen ohne dauernd noch zusätzlich im RAM einen Buffer allozieren zu müssen? Ein "Fill" Call ist auch nicht gerade das gelbe vom Ei. Außerdem machen die Locks in Verbindung mit dem "no overwrite" eigentlich schon Sinn.

[zeckensack]

Richtig. Das ist aber eine generelle Schwäche von Direct3D (das die Drawcalls teuer sind) und hat nichts mit dynamischen Daten an sich zu tun.

Ack. Aber das ist bei OpenGL doch genau das gleiche :|Bei OpenGL ist sowas deutlich günstiger zu haben.
Meine politisch inkorrekte These des Tages lautet im Klartext, dass viele dieser "dirty hacks" überhaupt nur deswegen so verbreitet sind, weil die Performance-Charakteristik von DirectX Graphics vernünftige Lösungen zu teuer macht.

Als weiteres Beispiel möchte ich mal diesen unsäglichen "texture atlas"-Schranz ins Feld führen. Ahoi GTA SA, ahoi HL2 und "centroid sampling". Ahoi "geometry instancing". Das sind alles nur Workarounds für Performanceprobleme mit DXG, jeweils mit eigenen unerwünschten Nebenwirkungen und teils erheblichem Entwicklungsaufwand.

Das ist der Preis dafür, wenn man mit den supi-tollen Zuckerli von D3DX "Zeit sparen" möchte. Mit OpenGL kann man einfach drauflosbauen, und es läuft
trotzdem. Konkret kann ich auf meiner 9600SE und meinem A64 3200+ 10 1,75 Millionen Dreiecke pro Sekunde rendern. Und zwar im immediate mode, jedes Dreieck einzeln, und jedes mit seiner eigenen Textur.

"Oh, Windmühlen!" ;(
Moment - Wie soll man sonst auf Vertexdaten zugreifen ohne dauernd noch zusätzlich im RAM einen Buffer allozieren zu müssen? Ein "Fill" Call ist auch nicht gerade das gelbe vom Ei. Außerdem machen die Locks in Verbindung mit dem "no overwrite" eigentlich schon Sinn.Buffer(Sub)Data.
Warum willst du unbedingt einen "direkten" Schreibzugriff haben? Wahrscheinlich doch weil du denkst es ist schneller, du sparst eine temporäre Kopie, du verschmutzt deine Caches nicht. Oder?
Nur leider funktioniert das in der Praxis nicht so. Baue dir mal einen Schreibbandbreitenbenchmark auf einem AGP4x-System. Dann wirst du schnell merken was der Treiber dir wirklich liefert, wenn du ein VBO "lockst".

[Demirug]

zeckensack, du hast 10 Millionen Texturen in deine Radeon bekommen?

Die Diskussion OpenGL vs. DirectX Graphics ist aber irgendwie sowieso müssig. Vor und Nachteile haben beide. Es muß eben jeder selbst entscheiden was für sein Projekt das beste ist.

MS hat ja nun endlich ein einsehen und die Win9x Kompatibilität beim DDK aufgebene und so den Weg für etwas performanteres frei gemacht.

[Coda]

Warum willst du unbedingt einen "direkten" Schreibzugriff haben? Wahrscheinlich doch weil du denkst es ist schneller, du sparst eine temporäre Kopie, du verschmutzt deine Caches nicht. Oder?Ich spar mir die temponäre Kopie.
Nur leider funktioniert das in der Praxis nicht so. Baue dir mal einen Schreibbandbreitenbenchmark auf einem AGP4x-System. Dann wirst du schnell merken was der Treiber dir wirklich liefert, wenn du ein VBO "lockst".1. Liegen dynamische VB im AGP-Systemram, 2. Wenn man sequentiell schreibt greift da write combining.

Wie langsam das füllen von statischen Vertexbuffern ist, ist mir fast egal.

[zeckensack]

zeckensack, du hast 10 Millionen Texturen in deine Radeon bekommen?Mea culpa.
Die 10M/s waren zwar mit BindTexture vor jedem Draw Call, aber die TEXTURE_2D war nicht enabled.

"Richtig" sind es 1,75 Millionen Dreiecke pro Sekunde.
Die 10 Millionen pro Sekunde ist die Anzahl an reinen Draw Calls, ohne Änderungen am "state" (der ATI-OpenGL-Treiber erkennt offensichtlich, dass der Textur-State egal ist, und optimiert diesen weg; keine schlechte Leistung, hätte ich nicht erwartet).

Sry.

edit: jetzt habe ich erst deine Frage kapiert ... nein, habe ich natürlich nicht. Es sind nur acht Stück, aber es wird vor jedem draw call gewechselt. for (int a=0;a<tris_per_frame;++a)
{
glBindTexture(GL_TEXTURE_2D,texture[a&7]);
glBegin(GL_TRIANGLES);
glVertex2fv(&vert[0].x);
glVertex2fv(&vert[1].x);
glVertex2fv(&vert[2].x);
glEnd();

[Coda]

Moment - Du erzählst uns was von Effizienz verwendest aber OpenGL immediate Funktionen?

Hab ich das jetzt richtig verstanden, oder war das nur ein Beispiel? :crazy:

[zeckensack]

Moment - Du erzählst uns was von Effizienz verwendest aber OpenGL immediate Funktionen?Ja. OpenGL mit 'nem Krückstock.
Bei DXG ist es AFAIK egal, ob man state ändert oder nicht, draw calls haben immer fixe kosten.
Ein berühmter Sänger sang einmal:
"Please Hang Over Your Bed:
25k batches/s @ 100% 1GHz CPU" [sic]
Jo! (pdf) (http://www.ati.com/developer/gdc/D3DTutorial3_Pipeline_Performance.pdf)

Entsprechend etwa 600k draw calls pro Sekunde auf meiner Maschine (K8>P6, wenn es um Kontext-Switches geht). Genau da geht bei DXG-basierten Spielen die CPU-Leistung hin. Immer schön aus der Runtime in den Kernel-Modus wechseln, und wieder zurück.
Hab ich das jetzt richtig verstanden, oder war das nur ein Beispiel? :crazy:Sowohl als auch =)

[Coda]

Ich sagte doch auch, dass Drawcalls einen hohen Overhead haben in DX. Aber das hat immer noch nix mit dynamischer Geometrie zu tun :D

Überhaupt sollte man mit gescheitem Batching auch mit DX da nicht gegen ein Limit laufen.

Ich verwende ja sowohl DirectX als auch OpenGL und sehe da nicht großartig viel Unterschiede, außer dass bei DX die API inzwischen sogar etwas sauberer ist. (Render-To-Texture ohne EXT_framebuffer_objekt in GL :rolleyes:)

Ich abstrahier die API aber eh über eine DLL, d.h. wenn es einmal funktioniert ist mir eigentlich egal wie komplex es war.

P.S.: Das hier muss man sich einrahmen. Ein der wenigen non-flame Diskussionen über das Thema :D

[Demirug]

Ich abstrahier die API aber eh über eine DLL, d.h. wenn es einmal funktioniert ist mir eigentlich egal wie komplex es war.

Warum kommt mir das nur bekannt vor?

Bei in Zukunft mindestens 5 APIs mit denen man sich auseinander setzte muss bleibt einem ja fast nichts mehr anders übrig. Wobei ich vermute das meine Abstraktion bei manchen einen Schreikrampf auslösen würde.

[Coda]

Bei in Zukunft mindestens 5 APIs mit denen man sich auseinander setzte muss bleibt einem ja fast nichts mehr anders übrig. Wieso 5? Ich zähle 3 (OpenGL, DX 9 & WGF 2.0).

DX9 <-> WGF 1.0 sollte ja vernachlässigbar sein, oder nicht?

Was ist denn an deiner Abstraktion so schrecklich? :D

[Demirug]

Wieso 5? Ich zähle 3 (OpenGL, DX 9 & WGF 2.0).

DX9 <-> WGF 1.0 sollte ja vernachlässigbar sein, oder nicht?

OpenGL
DX Graphics (DX9)
D3D Mobil
OpenGL ES Ok das könnte man wohl auch zu OpenGL zählen aber aufgrund der Zielgeräte dürfte es besser sein dafür nochmal ein eigenes Plugin zu haben.
WGF 2.0

Dazu würden dann noch eventuel entsprechenden Anpassungen für die Spielkonsolen kommen.

Was ist denn an deiner Abstraktion so schrecklich? :D

Sie ist dermassen hoch das man das man darin überhaupt keine bekannte 3D API wiederentdeckt. Defakto gibt es nur noch Resourcen welche sich in Daten und Shader aufteilen. Dabei habe ich wirklich für alles Shader. Selbst für Z-Test Stufe in der Pipeline gibt es einen Shader. Die Haupt API selbst hat defakto nur 4 Methoden. CreateResource, TestResource, Draw und Reset. Das ist aber nur der unterste Level der Abstraktion darüber gibt es noch einen.

[Coda]

Sie ist dermassen hoch das man das man darin überhaupt keine bekannte 3D API wiederentdeckt. Defakto gibt es nur noch Resourcen welche sich in Daten und Shader aufteilen. Dabei habe ich wirklich für alles Shader. Selbst für Z-Test Stufe in der Pipeline gibt es einen Shader. Die Haupt API selbst hat defakto nur 4 Methoden. CreateResource, TestResource, Draw und Reset. Das ist aber nur der unterste Level der Abstraktion darüber gibt es noch einen.Ach so meinst du. Ich meinte jetzt auf Backend DLL Level. Da macht es ja keinen Sinn so high-level zu gehen, weil man dann ja viel gleichen Code für jedes Backend hätte.

Die ganze low-level Backend-Soße wird dann im Frontend natürlich nochmal abstrahiert (Vertex-Declaration, VertexShader, PixelShader und Renderstate).

Schön finde ich meine C++-Metasprache für Shader, da ich damit ziemlich einfach Shader dynamisch generiere kann (Die Idee hatte aber auch schon andere, wobei ich im Backend einfach HLSL oder GLSL draus mache, also keine Codegeneration).

[Demirug]

Ach so meinst du. Ich meinte jetzt auf Backend DLL Level. Da macht es ja keinen Sinn so high-level zu gehen, weil man dann ja viel gleichen Code für jedes Backend hätte.

Das ist mein Backend. Und so viel gleichen Code habe ich da gar nicht. Die Funktionen die jedes Backend brauchen könnte (Format konvertierungen usw)sind in einer eigenen DLL die jedes Backend nutzen kann.

Die ganze low-level Backend-Soße wird dann im Frontend natürlich nochmal abstrahiert (Vertex-Declaration, VertexShader, PixelShader und Renderstate).

Und was macht dann dein Backend noch?

Schön finde ich meine C++-Metasprache für Shader, da ich damit ziemlich einfach Shader dynamisch generiere kann (Die Idee hatte aber auch schon andere, wobei ich im Backend einfach HLSL oder GLSL draus mache, also keine Codegeneration).

Ich habe MSIL als Basis dafür genommen. Der Generator erzeugt sogar automatisch Vertex, Pixel, Preshader sowie Multipass Lösungen aus einem einzigen Codeblock.

[Xmas]

Als weiteres Beispiel möchte ich mal diesen unsäglichen "texture atlas"-Schranz ins Feld führen. Ahoi GTA SA, ahoi HL2 und "centroid sampling". Ahoi "geometry instancing". Das sind alles nur Workarounds für Performanceprobleme mit DXG, jeweils mit eigenen unerwünschten Nebenwirkungen und teils erheblichem Entwicklungsaufwand.
Centroid Sampling ist nun wirklich kein Workaround für Performance-Probleme, sondern einfach nur korrekt.


Nur leider funktioniert das in der Praxis nicht so. Baue dir mal einen Schreibbandbreitenbenchmark auf einem AGP4x-System. Dann wirst du schnell merken was der Treiber dir wirklich liefert, wenn du ein VBO "lockst".
Wieso ist ein "Lock"-Mechanismus dann schlecht?

[Coda]

Und was macht dann dein Backend noch?Nix im Prinzip. Es ist wie gesagt nur ein hauchdünner Layer um OpenGL und Direct3D unter den gleichen Hut zu bekommen.

Ich hab da ein paar Dinge von Ogre abgeschaut.

[zeckensack]

Centroid Sampling ist nun wirklich kein Workaround für Performance-Probleme, sondern einfach nur korrekt.Wenn eine Stoßkante zwischen zwei texturierten Polygonen, die zum gleichen Mesh gehören, mitten durch ein Pixel verläuft, von wo wird dann mit "Centroid" die Textur gesampelt? Und was ist daran bitte korrekt?
Wieso ist ein "Lock"-Mechanismus dann schlecht?Weil er Implementationsdetails offenlegt. An diesen Details kann dann entweder nichts mehr optimiert werden, oder man muss das alte Verhalten mit emulierten Locks nachbilden. Bei letzterem wird dann der Sinn von Locks ad absurdum geführt. Mal ganz davon abgesehen dass es zusätzlich Komplexität und Support-Albträume bedeutet.

Denk' bitte nur mal an Texturen, geswizzelte Backbuffer, komprierte Z-Buffer. Dies sind für die Hardware optimierte Anordnungen im Speicher, die ganz anders aussehen als das, was ein Programmierer sich erhofft, wenn er die entsprechende Ressource "lockt", um "so schnell und direkt wie möglich" an die Daten ranzukommen. Da wird konvertiert dass die Schwarte kracht. Und es macht keinen Spaß solchen Code zu schreiben, schon garnicht für (IMO strunzdumme) Applikationen die es dann auch noch für besonders clever halten, eine 256²-Textur komplett zu locken, nur um ein einziges Texel "so schnell und direkt wie möglich" zu modifizieren.

Einige dieser Lock-Typen sind ja gottlob auch aus neueren DXG-Versionen schon herausgeflogen. Auf lange Sicht müssen sie IMO restlos alle weg. Und ebenfalls IMO dürfen auch keine neuen eingeführt werden.

[Coda]

Wenn eine Stoßkante zwischen zwei texturierten Polygonen, die zum gleichen Mesh gehören, mitten durch ein Pixel verläuft, von wo wird dann mit "Centroid" die Textur gesampelt? Und was ist daran bitte korrekt?Das wird ja nur für Lightmaps gebraucht.

Das gleiche Problem ergibt sich bei OpenGL doch auch mit Multisampling, ich verstehe gerade überhaupt nicht warum das mit OpenGL weniger gebraucht werden sollte.

Denk' bitte nur mal an Texturen, geswizzelte Backbuffer, komprierte Z-Buffer. Dies sind für die Hardware optimierte Anordnungen im Speicher, die ganz anders aussehen als das, was ein Programmierer sich erhofft, wenn er die entsprechende Ressource "lockt", um "so schnell und direkt wie möglich" an die Daten ranzukommen. Da wird konvertiert dass die Schwarte kracht.Nicht bei dynamischen Daten.

[Demirug]

Weil er Implementationsdetails offenlegt. An diesen Details kann dann entweder nichts mehr optimiert werden, oder man muss das alte Verhalten mit emulierten Locks nachbilden. Bei letzterem wird dann der Sinn von Locks ad absurdum geführt. Mal ganz davon abgesehen dass es zusätzlich Komplexität und Support-Albträume bedeutet.

Denk' bitte nur mal an Texturen, geswizzelte Backbuffer, komprierte Z-Buffer. Dies sind für die Hardware optimierte Anordnungen im Speicher, die ganz anders aussehen als das, was ein Programmierer sich erhofft, wenn er die entsprechende Ressource "lockt", um "so schnell und direkt wie möglich" an die Daten ranzukommen. Da wird konvertiert dass die Schwarte kracht. Und es macht keinen Spaß solchen Code zu schreiben, schon garnicht für (IMO strunzdumme) Applikationen die es dann auch noch für besonders clever halten, eine 256²-Textur komplett zu locken, nur um ein einziges Texel "so schnell und direkt wie möglich" zu modifizieren.

Einige dieser Lock-Typen sind ja gottlob auch aus neueren DXG-Versionen schon herausgeflogen. Auf lange Sicht müssen sie IMO restlos alle weg. Und ebenfalls IMO dürfen auch keine neuen eingeführt werden.

Und was ist deine Alternative zum Look/Unlock um eine Resource mit Daten zu füllen?

btw: Ich vermute das es bei WGF 2.0 einen neuen Type gibt den man auch Looken kann. Konstanten Buffer.

[zeckensack]

Das wird ja nur für Lightmaps gebraucht.

Das gleiche Problem ergibt sich bei OpenGL doch auch mit Multisampling, ich verstehe gerade überhaupt nicht warum das mit OpenGL weniger gebraucht werden sollte.Centroid ist ein Workaround für ein Problem das man nur hat wenn man "texture atlas"-Techniken einsetzt. Und die braucht man unter DXG mindestens 2,5 mal so dringend wie unter OpenGL.
Nicht bei dynamischen Daten.Auf Kosten der späteren Lookup-Performance. Meine Aussage war nicht umsonst vom Typ "entweder ... oder".

[zeckensack]

Und was ist deine Alternative zum Look/Unlock um eine Resource mit Daten zu füllen?(Get)Buffer(Sub)Data für Index-/Vertex-Buffer.
(Get)Tex(Sub)Image für Texturen.
DrawPixels/ReadPixels für den Framebuffer/Z-Buffer. Statt DrawPixels ist es oft effizienter, mit Geometrie zu arbeiten, dann macht man das eben. Könnte btw ebenfalls daran liegen, dass der Framebuffer in einem Format vorliegt, das auf das Rendern optimiert ist, und nicht auf linearen Zugriff ...

Unter OpenGL kannst du weder Texturen noch den Framebuffer "locken", trotzdem hindert es Applikationen nicht daran, die entsprechenden Ressourcen zu benutzen. Also geht's ja offensichtlich auch ohne Locks.

Mit den VBOs wurde erstmalig in OpenGL eine Lock-Semantik eingeführt. Das hielt und halte ich für falsch und unnötig.
btw: Ich vermute das es bei WGF 2.0 einen neuen Type gibt den man auch Looken kann. Konstanten Buffer.Wenn WGF das so macht, dann muss es ja eine intelligente Entscheidung sein :rolleyes:

[Coda]

Centroid ist ein Workaround für ein Problem das man nur hat wenn man "texture atlas"-Techniken einsetzt. Und die braucht man unter DXG mindestens 2,5 mal so dringend wie unter OpenGL.Die brauchst du auch bei OpenGL. Für jedes Polygon ein State-Change kannst du auch damit knicken.

Auf Kosten der späteren Lookup-Performance. Meine Aussage war nicht umsonst vom Typ "entweder ... oder".Wieso? Dafür bleibst du mir schon seit du das Argument ins Feld führst eine Erklärung schuldig.

Und ich spar mir damit immer noch die temporäre Kopie ohne Performanceverlust.

[zeckensack]

Die brauchst du auch bei OpenGL. Für jedes Polygon ein State-Change kannst du auch damit knicken.Es ist eine weite Spanne zwischen texture atlas und "für jedes Polygon ein State-Change".
Wieso? Dafür bleibst du mir schon seit du das Argument ins Feld führst eine Erklärung schuldig.Darum geht's doch erst seit gerade eben :conf2:
Texturen kann man entweder linear haben, oder irgendwie swizzeln, damit der Cache effizienter arbeiten kann, oder was auch immer. Wenn es keinen Grund gäbe, zu swizzeln, würde man es nicht machen. Aber man macht es nunmal. So weit schienst du ja auch schon meiner Meinung zu sein.

Für Locks sollte es linear sein. Für alles andere nicht.
Entweder du wandelst um (CPU-Zeit), oder du gibst die Vorteile auf, die dich überhaupt dazu gebracht haben deine Texturen zu swizzeln (Verlust an GPU-Effizienz).
Und ich spar mir damit immer noch die temponäre Kopie ohne Performanceverlust.Ja sicher, mal vom Flush davor und dem GPU-Stall während des Locks abgesehen.

[Demirug]

(Get)Buffer(Sub)Data für Index-/Vertex-Buffer.
(Get)Tex(Sub)Image für Texturen.
DrawPixels/ReadPixels für den Framebuffer/Z-Buffer. Statt ReadPixels ist es oft effizienter, mit Geometrie zu arbeiten, dann macht man das eben. Könnte btw ebenfalls daran liegen, dass der Framebuffer in einem Format vorliegt, das auf das Rendern optimiert ist, und nicht auf linearen Zugriff ...

Unter OpenGL kannst du weder Texturen noch den Framebuffer "locken", trotzdem hindert es Applikationen nicht daran, die entsprechenden Ressourcen zu benutzen. Also geht's ja offensichtlich auch ohne Locks.

Mit den VBOs wurde erstmalig in OpenGL eine Lock-Semantik eingeführt. Das hielt und halte ich für falsch und unnötig.

Da hätten wir aber zwingend immer eine Kopiersemantik bei der ein Speicherblock auch noch von aufrufenden Seite kommt.

Für statische Resource macht meine eigene 3D-API das im Prinzip sogar so. Was aber vorallem damit zusammenhängt das ich keinen direkten Transfer von einer Datei in eine Resource vornehme. Es war mir zuwieder eine Textureresource direkt in die Lage zu versetzten alle möglichen Bildformate lesen zu können.

Für dynamische Resource nutze ich dagegen das Prinzip das der "Generator" einen Speicherblock bekommt in den er die entsprechenden Daten einkopieren soll. Bei der DX Schnittstelle ist das der Speicherblock den ich durch den Lock erhalte. Bei OpenGL gibt es ein entsprechendens Scratchpad dafür.

Die Kopiersemantik hat nämlich IMHO einen Nachteil. Sie nimmt dem Treiber jede Möglichkeit ohne das Kopieren auszukommen. OK die Lock/Unlock Semantik kann dafür im Gegenzug einen zusätzlichen Kopiervorgang erfordern.

Die beste Lösung wäre daher IMHO beides in der API vorzusehen. Hat man die Daten bereits in einem eigenen Buffer ruft man dann die entsprechenden Transfer Funktion auf. Erzeugt man die Daten aber erst lässt man sich von der API einen Speicherblock dafür geben und gibt in nach dem füllen wieder zurück. OK ich bin da vielleicht nicht objektiv weil mein Zwischenlayer es genauso abbildet.

Wenn WGF das so macht, dann muss es ja eine intelligente Entscheidung sein :rolleyes:

Das wollte ich damit nicht sagen. Allerding halte ich es bei der großen Anzahl von Konstanten die ein Shader inzwischen bekommen durchaus für Sinnvoll dafür einen Speichertype vorzusehen.

[Coda]

Es ist eine weite Spanne zwischen texture atlas und "für jedes Polygon ein State-Change".Auch bei kleinen Atlanten braucht man schon Centroid Sampling.

Entweder du wandelst um (CPU-Zeit), oder du gibst die Vorteile auf, die dich überhaupt dazu gebracht haben deine Texturen zu swizzeln (Verlust an GPU-Effizienz).Wenn dynamische Texturen bei OpenGL geswizzled im AGP-RAM liegen fress ich nen Besen :)

Ja sicher, mal vom Flush davor und dem GPU-Stall während des Locks abgesehen.Nix Stall. "No Overwrite" lässt grüßen.
http://msdn.microsoft.com/library/en-us/directx9_c/directx/graphics/ProgrammingGuide/ProgrammingTips/performanceoptimizations.asp?FRAME=true#Using_Dynamic_Vertex_and_Index_Buffers

OK ich bin da vielleicht nicht objektiv weil mein Zwischenlayer es genauso abbildet.Das kommt mir irgendwie bekannt vor ;)

[Demirug]

Es ist eine weite Spanne zwischen texture atlas und "für jedes Polygon ein State-Change".

Centroid ist auch sehr praktisch wenn man für komplexe Objekte das UV Mapping und die Texture dazu hat automatisch erzeugen lassen. Ohne Centroid rutscht man da leicht in einen falschen Bereich der Texture.

Darum geht's doch erst seit gerade eben :conf2:
Texturen kann man entweder linear haben, oder irgendwie swizzeln, damit der Cache effizienter arbeiten kann, oder was auch immer. Wenn es keinen Grund gäbe, zu swizzeln, würde man es nicht machen. Aber man macht es nunmal. So weit schienst du ja auch schon meiner Meinung zu sein.

Für Locks sollte es linear sein. Für alles andere nicht.
Entweder du wandelst um (CPU-Zeit), oder du gibst die Vorteile auf, die dich überhaupt dazu gebracht haben deine Texturen zu swizzeln (Verlust an GPU-Effizienz).

Lohnt es sich für Daten die man nur einmal braucht diese von der CPU in eine Form zu bringen die der GPU am besten bekommt oder macht es für diesen Fall mehr Sinn die GPU zu befähigen auch Daten zu nutzen die nicht unbedingt Ideal formatiert sind?

[Demirug]

Nix stall. "No Overwrite" lässt grüßen.

DISCARD würde ich dann aber auch noch anführen sonst bist du wieder gekniffen wenn der Buffer "voll" ist.

[zeckensack]

Auch bei kleinen Atlanten braucht man schon Centroid Sampling.Und ohne Atlanten braucht man weder Centroid noch zwangsläufig "Für jedes Polygon ein State-Change".
Wenn dynamische Texturen bei OpenGL geswizzled im AGP-RAM liegen fress ich nen Besen :)Du weißt es nicht, und du mußt es auch nicht wissen. Trotzdem hat der Treiber die Freiheit es so zu machen wie's am besten passt. Und nicht alle Treiber sind gleich.

Das einzige was bei NVIDIA zB unter OpenGL nicht geswizzelt wird sind RECTs. Egal ob dynamisch oder nicht. Ob dabei geswizzelt wird, wenn die Daten in den FIFO gehen, oder erst später "on the fly" ist mir ehrlich gesagt ziemlich egal. Es funktioniert.
Nix Stall. "No Overwrite" lässt grüßen.
http://msdn.microsoft.com/library/en-us/directx9_c/directx/graphics/ProgrammingGuide/ProgrammingTips/performanceoptimizations.asp?FRAME=true#Using_Dynamic_Vertex_and_Index_BuffersUn d was bitte ist dann der Unterschied dazu, dass du selbst einen Puffer anlegst, und ihn vom Treiber durchkopieren lässt?
Oder bist du ernsthaft davon überzeugt, dass du bei solchen Locks direkt in den Kommando-FIFO schreiben kannst? Schonmal was von "wrap around" bei Ringpuffern gehört?

Entweder machst die Applikation malloc, oder die DX-Runtime. Das ist sowas von Jacke wie Hose. Ich bevorzuge es in der Applikation, weil ich mir solche Puffer dauerhaft festhalte und mehrfach benutze. Die DX-Runtime wird das hoffentlich auch machen, aber es steht halt nirgends.

[Coda]

Und ohne Atlanten braucht man weder Centroid noch zwangsläufig "Für jedes Polygon ein State-Change".Aja. Und wie willst du Lightmapping dann sonst machen? Gerade dafür hat man doch Centroid eingeführt.

Du weißt es nicht, und du mußt es auch nicht wissen. Trotzdem hat der Treiber die Freiheit es so zu machen wie's am besten passt. Und nicht alle Treiber sind gleich.Natürlich hat er die Freiheit. Aber ich fress trotzdem nen Besen wenn er es macht.
Bei statischem Zeugs im VRAM bin ich mir da auch sicher, aber für dynamische Daten im AGP-Speicher glaub ich das nicht.

Warum? Weil es AGP-Speicher ist, d.h. lesen ist arsch-langsam auch für den Treiber.

Ja die OpenGL Methode hätte hier den Vorteil, dass der Treiber es machen könnte. Trotzdem glaube ich nicht dran. Weil an dem Punkt wenn die Grafikkarte eh aus dem AGP-Speicher streamt ist swizzeling auch voll egal.

Und was bitte ist dann der Unterschied dazu, dass du selbst einen Puffer anlegst, und ihn vom Treiber durchkopieren lässt?Das der DX Buffer schon im AGP-Speicher liegt? Und da bin ich sicher, weil lesen daraus mehr als langsam ist.

[Xmas]

Wenn eine Stoßkante zwischen zwei texturierten Polygonen, die zum gleichen Mesh gehören, mitten durch ein Pixel verläuft, von wo wird dann mit "Centroid" die Textur gesampelt? Und was ist daran bitte korrekt?
Korrekt ist, dass die interpolierten Werte niemals außerhalb des Polygons liegen. Es ist eine Option.
Und versuch mal einen Tile-Shader zu implementieren, bei dem du das Tileset nicht in eine einzige Textur packst...

Weil er Implementationsdetails offenlegt. An diesen Details kann dann entweder nichts mehr optimiert werden, oder man muss das alte Verhalten mit emulierten Locks nachbilden. Bei letzterem wird dann der Sinn von Locks ad absurdum geführt. Mal ganz davon abgesehen dass es zusätzlich Komplexität und Support-Albträume bedeutet.

Denk' bitte nur mal an Texturen, geswizzelte Backbuffer, komprierte Z-Buffer. Dies sind für die Hardware optimierte Anordnungen im Speicher, die ganz anders aussehen als das, was ein Programmierer sich erhofft, wenn er die entsprechende Ressource "lockt", um "so schnell und direkt wie möglich" an die Daten ranzukommen. Da wird konvertiert dass die Schwarte kracht. Und es macht keinen Spaß solchen Code zu schreiben, schon garnicht für (IMO strunzdumme) Applikationen die es dann auch noch für besonders clever halten, eine 256²-Textur komplett zu locken, nur um ein einziges Texel "so schnell und direkt wie möglich" zu modifizieren.
Wo werden denn da bitte Implementationsdetails offen gelegt?
Mit TexImage übergibtst du den Speicherbereich und das Format an die API, welche dann konvertiert und kopiert.
Mit Lock gibt dir die API einen Speicherbereich, und das Format ist genau das was du beim Anlegen der Ressource angegeben hast. Falls der Treiber/die GPU eine optimierte Struktur verwenden, muss kopiert und konvertiert werden. Sonst nicht.
Als einzigen Nachteil von Lock sehe ich da die möglicherweise ineffizientere Speicherreservierung. Nix Implementationsdetails, Komplexität und Support-Alpträume...

Einen komprimierten Z-Buffer kannst du übrigens gar nicht locken.

[zeckensack]

Korrekt ist, dass die interpolierten Werte niemals außerhalb des Polygons liegen.Es ist wahr, dass das Centroid-Sampling so gemacht wird. Das reicht mir noch nicht aus, um es korrekt zu finden.
Durch Centroid entstehen (an den Kanten) lokale Sprünge in der Abtastfrequenz, während ohne Centroid das Abtastraster fixe Abstände auf der (homogenen) Koordinatenebene einhält. Das hat seine Vorteile.
Zumindest ist es nicht per se falsch, auch nicht an Kanten.
Und versuch mal einen Tile-Shader zu implementieren, bei dem du das Tileset nicht in eine einzige Textur packst...Jetzt steh' ich auf dem Schlauch. Meinst du mit Tile Shader sowas wie zweite Reihe, erste Spalte im Shadermark "combination"-Effekt (http://www.techreport.com/reviews/2005q2/geforce-7800gtx/index.x?pg=13)?

Wo werden denn da bitte Implementationsdetails offen gelegt?
Mit TexImage übergibtst du den Speicherbereich und das Format an die API, welche dann konvertiert und kopiert.
Mit Lock gibt dir die API einen Speicherbereich, und das Format ist genau das was du beim Anlegen der Ressource angegeben hast. Falls der Treiber/die GPU eine optimierte Struktur verwenden, muss kopiert und konvertiert werden. Sonst nicht.Irgendwie finde ich dass du dir die Antwort schon selbst gegeben hast. Aber gerne nochmal:
TexImage kopiert immer. TexImage kann immer konvertieren. Du siehst es nicht, aber du musst damit rechnen dass es passiert. TexImage will nur wissen, wie die Textur im Applikationsspeicher aussieht, aber gibt keine Hinweise darauf, wie die Hardware die Textur gerne hätte, und welche Formatierung sie letztlich bekommt.
Locks: "Flache" Adressierung ist ein uraltes Implementationsdetail, das das Hardware-Format zB einer Voodoo 3 widerspiegelt. Die Lock-API täuscht vor, als ob es auch auf aktuellen Karten noch so wäre. Sie täuscht vor, als käme man direkt an "die Textur". Sie täuscht die Einsparung mindestens einer Kopie vor.
Textur-Locks können emuliert sein. IMO sind sie es aktuell auch in den allermeisten Fällen.
Und selbst wenn das Format tatsächlich zur Hardware passt, kann eine Pseudo-Emulation trotzdem besser sein, weil es dann leichter ist den Texturupload asynchron zu erledigen.

Als einzigen Nachteil von Lock sehe ich da die möglicherweise ineffizientere Speicherreservierung. Nix Implementationsdetails, Komplexität und Support-Alpträume...Was sind denn die Vorteile von Locks? Welche davon sind real, und welche davon Illusion?

Wir können gerne mal einen kleinen pissing contest machen, in Form von einem kleinen Benchmark mit dynamischen Texturen. Dann sehen wir ja, ob Locks tatsächlich ihre wohlbekannten aber IMO illusorischen Vorteile haben. Wenn du interessiert bist, lege ich eine GLUT-Applikation vor, die garantiert durch den Textur-Upload limitiert wird.
Einen komprimierten Z-Buffer kannst du übrigens gar nicht locken.Ich weiß. Und aus gutem Grund. D16_LOCKABLE geht, alles andere nicht.

Ich habe ja schon geschrieben: "Einige dieser Lock-Typen sind ja gottlob auch aus neueren DXG-Versionen schon herausgeflogen". Das beweist maximal dass ich mit den Implementationsdetails nicht völlig daneben liegen kann (obwohl mir auch klar ist dass Framebuffer+Anhängsel vs Texturen nicht wirklich das gleiche Paar Schuhe sind).

edit: das sollte jetzt heißen dass jeder IHV den Z-Buffer so strukturieren kann wie er mag, und eigentlich jeder hier ziemlich krasse Datenformat-Optimierungen vornimmt. Dadurch macht es halt keinen Sinn mehr dort eine Lock-API zu erlauben, weil a)immer konvertiert werden müsste, damit automatisch auch b)immer kopiert werden müsste. Damit hätte der Lock jeden seiner theoretischen Vorteile verloren, also weg damit.

[Coda]

Wir können gerne mal einen kleinen pissing contest machen, in Form von einem kleinen Benchmark mit dynamischen Texturen. Dann sehen wir ja, ob Locks tatsächlich ihre wohlbekannten aber IMO illusorischen Vorteile haben. Wenn du interessiert bist, lege ich eine GLUT-Applikation vor, die garantiert durch den Textur-Upload limitiert wird.Wieso sollte es da große Unterschiede geben? Man spart sich halt die lokale Kopie...

Wobei ich bei Texturen mit dir übereinstimme, dass ein Fill sinnvoller wäre, weil man da die lokale Kopie allermeistens eh braucht.

[zeckensack]

Wieso sollte es da große Unterschiede geben? Man spart sich halt die lokale Kopie...Der Platz für die Kopie tut ja nicht wirklich weh. Im Grunde ist es ja nicht mal unbedingt eine Kopie (für jede (dynamische) Textur), sondern ein (paar) Zwischenpuffer, den/die man für mehrere Texturen verwenden kann.

Im Grunde geht es doch um die Bandbreite, die beim Kopieren verbraucht wird.
Ohne Kopie sollte es also schneller sein. Je weniger Hauptspeicherbandbreite das System hat, desto größer sollte der Vorteil sein.
Wobei ich bei Texturen mit dir übereinstimme, dass ein Fill sinnvoller wäre, weil man da die lokale Kopie allermeistens eh braucht.Mit Texturen war das Beispiel leichter. VBOs sind IMO momentan überall "flach" organisiert, also wäre da argumentativ wenig zu holen gewesen.
Und der "pissing contest"-Benchmark, falls Xmas ihn möchte, wird mit Texturen auch simpler und übersichtlicher.

[Xmas]

Es ist wahr, dass das Centroid-Sampling so gemacht wird. Das reicht mir noch nicht aus, um es korrekt zu finden.
Durch Centroid entstehen (an den Kanten) lokale Sprünge in der Abtastfrequenz, während ohne Centroid das Abtastraster fixe Abstände auf der (homogenen) Koordinatenebene einhält. Das hat seine Vorteile.
Zumindest ist es nicht per se falsch, auch nicht an Kanten.
Es hat seine Vorteile, richtig. Deswegen ist Centroid auch eine Option. Es hat aber auch seine Nachteile.
NVidia benutzt übrigens Centroid Sampling beim TSAA.

Jetzt steh' ich auf dem Schlauch. Meinst du mit Tile Shader sowas wie zweite Reihe, erste Spalte im Shadermark "combination"-Effekt (http://www.techreport.com/reviews/2005q2/geforce-7800gtx/index.x?pg=13)?
Nein, ich meinte ein Shader der ein Tile-Set zu einer großen "virtuellen Textur" zusammensetzt.

Irgendwie finde ich dass du dir die Antwort schon selbst gegeben hast. Aber gerne nochmal:
TexImage kopiert immer. TexImage kann immer konvertieren. Du siehst es nicht, aber du musst damit rechnen dass es passiert. TexImage will nur wissen, wie die Textur im Applikationsspeicher aussieht, aber gibt keine Hinweise darauf, wie die Hardware die Textur gerne hätte, und welche Formatierung sie letztlich bekommt.
Locks: "Flache" Adressierung ist ein uraltes Implementationsdetail, das das Hardware-Format zB einer Voodoo 3 widerspiegelt. Die Lock-API täuscht vor, als ob es auch auf aktuellen Karten noch so wäre. Sie täuscht vor, als käme man direkt an "die Textur". Sie täuscht die Einsparung mindestens einer Kopie vor.
Textur-Locks können emuliert sein. IMO sind sie es aktuell auch in den allermeisten Fällen.
Und selbst wenn das Format tatsächlich zur Hardware passt, kann eine Pseudo-Emulation trotzdem besser sein, weil es dann leichter ist den Texturupload asynchron zu erledigen.
Mir scheint es, dass du dich eher an der Bezeichnung "Lock" störst als an allem anderen. Dass man nicht weiß was beim Lock konkret passiert bedeutet doch gerade dass man keine Implementationsdetails offenlegt. Du kennst nur die Schnittstelle. Nicht den Ablauf.

Was sind denn die Vorteile von Locks? Welche davon sind real, und welche davon Illusion?
Vorteil ist, dass man in in manchen Fällen eine Kopie spart. Das ist sicherlich kein großer Vorteil. Was sind die Nachteile?

Wir können gerne mal einen kleinen pissing contest machen, in Form von einem kleinen Benchmark mit dynamischen Texturen. Dann sehen wir ja, ob Locks tatsächlich ihre wohlbekannten aber IMO illusorischen Vorteile haben. Wenn du interessiert bist, lege ich eine GLUT-Applikation vor, die garantiert durch den Textur-Upload limitiert wird.
Ich kann meine Zeit sicher sinnvoller verschwenden.

Ich weiß. Und aus gutem Grund. D16_LOCKABLE geht, alles andere nicht.
Dummerweise kommt man überhaupt nicht mehr an die Z-Daten, man muss sie in eine zusätzliche FP32-Textur schreiben. Da stört es, dass DST kein echtes API-Feature ist.

[MountWalker]

Huch, sorry verirrt. :(

[Shatten]

Ich liebe glänzende Texturen! ich finde das das erst eine gewisse Faszination in einer Spielwelt auslöst da diese durch dieses glänzen einen gewissenen "Perfeken" Touch bekommt! Ich will nich das grafiken reellen Sachen aufs detail ähneln! ich finde grad das überglänzte eine sehr schöne und edel (grafische) Art mit den Grafiken Distanz zur Realität beizubehalten! :yes:

[zeckensack]

Mir scheint es, dass du dich eher an der Bezeichnung "Lock" störst als an allem anderen. Dass man nicht weiß was beim Lock konkret passiert bedeutet doch gerade dass man keine Implementationsdetails offenlegt. Du kennst nur die Schnittstelle. Nicht den Ablauf.Historisch gesehen waren Locks von Texturen und zB dem 16 Bit-Z-Buffer einmal echter, direkter Zugriff auf von der Hardware verwalteten Speicher, ergo sehr wohl mittlerweile veraltete Implementationsdetails.

Dass Locks auf aktueller Hardware so nicht mehr funktionieren können weiß ich selbst.

Locks anzubieten macht dann Sinn, wenn die Ressource in dem Format verbleibt, das die Applikation liefert. Also extrem selten. In allen anderen Fällen trifft das zu was du geschrieben hast: Ablauf unbekannt. Für unbekannten Ablauf sollte man aber lieber keine Lock-API anbieten, denn ...
Vorteil ist, dass man in in manchen Fällen eine Kopie spart. Das ist sicherlich kein großer Vorteil. Was sind die Nachteile?Die Applikation kann in Speicher rumfuhrwerken der ihr nicht gehört. Speicher kann man nur auf Page-Basis schützen, dh es ist nicht mal zuverlässig erkennbar, ob eine Applikation benachbarte Daten vermurkst.

Als Sicherheitsmaßnahme sind bis zu 4kiB Speicher freizuhalten. Und das Verhalten für lokale Locks, AGP-Locks und pure SW-Locks kann jeweils nochmal anders auffallen, von den verschiedenen IHVs mal gleich ganz abgesehen. Kurz: Fehlerträchtigkeit und Probleme solche Fehler zu Entdecken, wenn man nicht umfassend testet.

Beispiele gefällig?
1)The Westerner auf Radeon-Karten mit DX9.0c. Freezt relativ zuverlässig nach wenigen Minuten. Keine Probleme mit DX9.0b.
2)Die Geschichte liegt in einem privaten Beta-Forum, und das Passwort kann ich dir nicht einfach so geben. Also so:
//we'll allocate more than we need
//this allows confused clients to read 64k before and after the buffer during a lock
pub_write_buf_alloc=(ubyte*)VirtualAlloc(0,
fstate.constants.xres*fstate.constants.yres*4+(1<<17),
MEM_COMMIT|MEM_TOP_DOWN,
PAGE_READWRITE);
public_write_buffer=pub_write_buf_alloc+(1<<16);
pub_read_buf_alloc=(ubyte*)VirtualAlloc(0,
fstate.constants.xres*fstate.constants.yres*2+(1<<17),
MEM_COMMIT|MEM_TOP_DOWN,
PAGE_READWRITE);
public_read_buffer=pub_read_buf_alloc+(1<<16);
Ohne das crasht's, weil der Kunde in Speicher rumfuhrwerkt der ihm nicht gehört.As you see, conversion from float to int is used, beside scale values can by slightly wrong. Thus, after such conversion result can be outside of buffer bounds. I tried to set condition like index < screen_width*screen_height, but got very strange result, so I left it as it is.Wurzel des Übels: seiner Hardware ist es shice-egal, wenn man 64kiB später noch Zeugs schreibt, weil da nichts wichtiges ist.

IMO ist es einfach eine Design-Frage. Insbesondere für Libs, wo die größte aller Problemquellen sowieso immer Applikationsfehler sind, sollte IMO gelten dass wenn der Kunde Speicher will, er ihn sich gefälligst selbst zu besorgen hat. Dann crasht's wenn überhaupt immer an der gleichen Stelle, egal welche HW man verwendet.

Deswegen halte ich Locks für böse. Und ich sehe da keine Vorteile die groß genug sind, um dieses Böse weiterhin zu nutzen.
Ich kann meine Zeit sicher sinnvoller verschwenden.Dann schenke ich mir das auch. Eigentlich fast schon schade.