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:

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.

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.