Home

Regeln für Wettbewerbe mit vorgegebenem Terrain

Freitag, 18. Januar 2008 | Autor:

In der vergangenen Runde des Terragen-Contests sollte ein Bild mit einem fest vorgegebenen Terrain gerendert werden, doch nach einer längeren Diskussion kam es anders.

Das vorgegebene, eher gewöhnungsbedürftige und vergleichsweise niedrig aufgelöste Terrain lies schnell die Frage aufkommen, ob man denn wenigstens ein bisschen Struktur einbringen könnte. Die Regeln aber verboten jede Manipulation des Terrains. Überraschenderweise führt dieses Verbot sofort dazu, dass TG2 sofort nahezu alle seine Vorteile hinsichtlich Surface-Gestaltung verliert. Hätte der Contest so stattgefunden, wäre man mit TG0.9 besser gefahren, denn dort gibt es immerhin mit Bumpiness noch prozedurales Bumpmapping, sowie ein rudimentäres Intersect Underlying in Form von Mimic Terrain.

Aber wie sollte eine Regel formuliert sein, die das Hinzufügen von Struktur erlaubt, gleichzeitig aber keine Hintertür lässt, mit der dennoch das Terrain umgekrempelt werden kann?
(Teilnehmer, die die Regeln ad absurdum führen, um formal legitime, aber der Intention der Regeln widersprechende, Modifikationen durchzuführen, nenne ich mal “Hacker”.)

Intuitiver Ansatz – Displacement mit fester, maximaler Stärke

Man verbietet einfach die Benutzung von Displacement, welches eine bestimmte Stärke überschreitet, was im oben genannten Thread auch vorgeschlagen wurde. Man sieht sofort, dass das ein sinnvoller Ansatz ist, aber wirklich umsetzbar ist er nicht.

Probleme:
  1. Wenn jemand 100m Displacement möchte, die maximale Amplitude lässt aber nur 1m zu, dann erzeugt derjenige sich eben 100 Nodes, die alle in die selbe Richtung wirken. Damit wird die Regel umgangen und man kann das Terrain beliebig entstellen. Diese Technik ist auch realistisch – hundert Nodes können in der tgd-Datei durch ein kleines Skript oder per Hand recht zügig eingefügt werden.
  2. Die genaue, lückenlose Definition der Regel wird schwer durchschaubar, da in verschiedenen Nodes an verschiedenen Stellen jeweils Werte in Abhängigkeit von anderen Parametern eingeschränkt werden müssen. Das nimmt der Regel die Transparenz, die bei einem öffentlichen Wettbewerb, der auch Einsteiger motivieren soll, unverzichtbar ist.
  3. Bereits kleine Ausnahmen von können unter Umständen ausgenutzt werden, um die beabsichtigte Einschränkung zu umgehen. Ein Beispiel: Wird Displacement auf Wasser erlaubt – eine harmlos klingende Idee – kann man die Wasseroberfläche als Terrain gestalten und nach den Water Shader einen Surface Layer schalten, der den Water Shader überschreibt. So benutzt man das “Wasser” als Terrain und hebelt die Regel, alleine unter Ausnutzung dieser einen Ausnahme, völlig aus.

Eine mögliche Verbesserung: Man beschränkt die Summe aller Displacements auf einen bestimmten Wert. Dadurch wird zwar Problem 1 gelöst, 3 bleibt jedoch bestehen und 2 verschärft sich noch massiv.

Verbesserung – Nicht-formale Regeln

Um komplizierte Feinheiten und Lücken in der Formulierung von Regeln zu umgehen, könnte man die Vorgaben auch einfach allgemein halten:

Das Terrain darf nicht maßgeblich verändert werden. Genauer: Das Terrain darf sich nirgends um mehr als 0.5m vom vorgegebenen Terrain unterscheiden.

Im Zweifelsfall entscheidet die Jury, ob eine Veränderung “maßgeblich” war.

Diese Regel ist aus 3 Teilen aufgebaut. Zunächst wird die Intention klar gemacht, danach wird ein präziser Rahmen vorgegeben. Wegen ihrer Einfachheit schließt die Regel möglicherweise nicht alle Tricks aus, die sie ad absurdum führen könnten.
Dem wird mit der explizit angegebenen Intention entgegengewirkt. Die ist kein Logischer Satz, sondern ein subjektives Kriterium. Das führt dazu, dass sie nicht in einer Argumentationskette ausgenutzt werden kann – also kann ein Hacker keine Argumentation finden, aus der objektiv zwingend folgt, dass das Bild den Regeln entspricht.
Zuletzt muss noch eine Instanz festgelegt werden, die diese objektive Entscheidung trifft.

Der Hintergedanke ist folgender: Man macht die Entscheidung auf Zulassung nicht von festen Regeln abhängig, sondern behält selbst die Entscheidungsgewalt.

Probleme:
  • Auch einfache Regeln sind nicht einfach zuverlässig einzuhalten, wenn man das Programm noch nicht beherrscht. Beispielsweise, wenn man nicht weiß, dass TG2 Einheiten immer in Metern angibt.
  • Hartnäckige Hacker könnten argumentieren, das System ermöglicht Willkür – was stimmt.

Letzteres Problem ist allerdings nicht weiter wichtig, da der Admin des Contests ohnehin immer Willkür walten lassen kann, so er denn möchte. Der Contest wird also selbst im schlimmsten Fall nicht unfairer.

Für ersteres Problem gibt es ebenfalls eine Lösung:

Verifikation

Dei Verbesserung leidet immer noch unter schlecht nachvollziehbaren Regeln. Um dem Teilnehmer dennoch Gewissheit zu verschaffen, noch im gültigen Rahmen zu sein, kann man eine Datei automatisch verifizieren lassen. Einen Mechanismus zu bauen, der tatsächlich prüft, ob irgendwo auf dem Planeten das Terrain zu sehr abweicht ist jedoch mit TG2 momentan nicht machbar (meiner Meinung nach).

Als Alternative kann sich darauf beschränken, die Stellen, an denen die Veränderung zu stark ist, für den Teilnehmer zu markieren. Das geht sehr einfach! Die Aufgabe, die Markierung dann tatsächlich zu sehen, wird dem Teilnehmer überlassen.

Die Schaltung

Folgende Schaltung, insbesondere die Gruppe “Verifikation”, tut’s:

verifikation1.png

Zum Einbau des Tests leitet man den Datenstrom des ursprünglich letzten Shaders vor “Planet 01″ um, sodass die Daten durch die Verifikationsschaltung laufen. Diese errechnet mittels eines Merge-Shaders die Differenz von durch Surface verändertem und ursprünglich vorgegebenem Terrain.
Der Constant-Shader grundiert das Differenz-Terrain schwarz, der Distribution-Shader färbt die außerhalb der Toleranz liegenden Teile weiß. Bei diesem muss dazu unter Minimum Altitude die gewünschte Grenze eingestellt werden.
Der Merge-Shader bekommt noch Compute-Terrain als Input, das Resultat der Verifikation hängt man einfach an den Planeten.

Will man nun testen, schaut man sich die Preview an. Ein Mal mit dem Merge Shader im Modus “Subtract (Input – A)” und ein Mal in “Subtract (A – Input)“. Beide Male dürfen keine weißen Markierungen zu sehen sein, dann ist der Test bestanden.

Während des normalen Arbeitens deaktiviert man die Verifikation einfach mit einem Klick auf die Gruppe und [D].

Ein Beispiel mit einem Fraktal

Das Bild links zeigt die Vorschau bei deaktivierter Gruppe/Verifikation; das in der Mitte das Resultat einer positiv verifizierten Welt; die Abbildung rechts das Resultat einer fehlgeschlagenen Verifikation, d.h. das Terrain weicht zu stark von der Vorgabe ab.

ver-veri-off.pngver-veri-passed.pngver-veri-failed.png

Dabei wurde von einer Überschreitung des Toleranzbereiches durch ein Fraktal um das Doppelte ausgegangen. Die Einschätzung ist per Augenmaß recht einfach – sobald weiße Flecken zu sehen sind, weicht das Terrain zu stark ab.

Umgekehrt gilt das allerdings nicht, denn es könnte sein, dass TG2 die Preview gerade so rendert, dass man die weißen Flecken zufällig nicht sieht. Man kann sich dann aber auf den Standpunkt stellen: Wenn die Flecken nicht zu sehen sind, fand kein sichtbares Displacement statt. Demnach ist das Bild regelkonform. Die Drohung “Im Zweifelsfall entscheidet die Jury” verhindert dabei, dass Hacker ein willkürliches Maß für Sichtbarkeit wählen.

Damit sind die Probleme gelöst – eine sinnvolle Regel ist gefunden! :)
Hier das Clip-File für die Verifikation: verifikation.tgc Es ist auf 5m Toleranz eingestellt und enthält noch einige Details, die hier nicht näher beschrieben wurden.

Tags »

Trackback: Trackback-URL | Feed zum Beitrag: RSS 2.0
Thema: Communitys, Ideen

Diesen Beitrag kommentieren.

7 Kommentare

  1. 1
    Nikita 

    Dieser Artikel hat eine verdammt kleine Zielgruppe, aber als mir das aufgefallen ist, war’s schon halb fertig…

  2. 2
    Kranky 

    Wow, ich gehöre zu dieser Zielgruppe ;)
    Der Artikel ist sehr interessant geschrieben – vielen Dank! AAAAber bei deiner Verifikation gibt es noch eine Sicherheitslücke: Zwischen Heightfield load und Compute Terrain kann das Terrain schon vorher manipuliert werden und dann wird es die Prüfung auch bestehen.
    Bin ich jetzt auch ein Hacker? :D

  3. 3
    Nikita 

    Hm… Man kann die Schaltung auch direkt an den Heightfield-Shader hängen, denke ich.
    Der primäre Zweck der Verifikation ist wirklich, eine Orientierung zu geben für Leute, die sich dran halten *wollen*. In der Praxis müsste man dann natürlich noch kurz erklären, wie die Verifikation eingebaut werden muss, um solche Dinge zu vermeiden.

  4. 4
    Xero 

    Oh ja das mit der Zielgruppe hab ich mir gerade auch gedacht während ich den Text gelesen habe. Aber sollte der Contest mit der Final sich großer Beliebtheit erfreuen und das Tema “Vorgegebenes Terrain” lauten, dann können wir vollmundig sagen “hey der nikita – der weiß wies geht!”

  5. 5
    Torsten 

    Danke auch von mir für diesen aufschlußreichen Artikel. Aufschlußreich nicht zuletzt deshalb, weil er beweist, dass das Thema tatsächlich nicht so trivial ist, wie es auf den ersten (und zweiten) Blick scheint.
    Das Contest-Thema “Vorgegebenes Terrain” wird aber unsere große Herausforderung bleiben.

  6. 6
    Nikita 

    Ja, da muss man erstmal nen Moment drüber nachdenken, zumal sich die Shader auch nicht so vorhersagbar verhalten, wie man es vermuten könnte.
    Man hätte ja sagen können: “Ok, Amplitude nicht höher als 5m, dann weicht das Terrain nur 5m von der Vorgabe ab.” Allerdings bedeutet eine Amplitude von 5m: “von -5m bis +5m. Daran dürften noch einige der Teilnehmer denken, aber: Ein Fraktal kann auch über die Amplitude hinausragen!

    Im Grunde läuft man immer Gefahr, dass Leute sich verschätzen, besonders, wenn sie aus den Vorgaben das Maximum rausholen wollen. Deswegen übrigens macht so eine Test-Schaltung auch Sinn, wenn man keine “Hacker” unter den Teilnehmern hat. :)

  1. […] die TG2 bietet, nur begrenzt verändert werden kann, widmet Nikita im TGBlog einen sehr interessanten und aufschlußreichen Artikel. « […]

Kommentar abgeben