ZFX + Developia

So es gibt Fortschritte mit der shared RenderTexture. Dieser nervige Bug mit den leeren Texturbereichen hat mich noch ein paar Tage gekostet, dabei war der Bug eigentlich ganz simpel.
Ich hatte zunächst weiterhin die SharedTextureManager Klasse im Verdacht, bzw. das irgendwas mit der Indizierung der freien Slots nicht stimmt.

Am Ende wars ein vergessener RenderTexture.Release() (löscht die RenderTextur) Aufruf den ich in dem Split-Vorgang einer Plane aufgerufen hatte. An sich korrekt die RenderTexture wegzuschmeißen wenn ein Quadtree Node gesplittet wird, dumme Idee wenns eine shared RenderTexture ist. Logischerweise ist der einzige der jetzt noch Releasen darf ist der SharedTextureManager während des Housekeepings, nämlich immer dann wenn eine komplette shared Textur überhaupt nicht mehr verwendet wird. Ansonsten werden die einzelnen Slots ja nun wiederverwendet, ein Release ist nicht mehr notwendig.

Naja, jetzt funktioniert das ganze grundsätzlich ganz gut, ich bin mit der Implementierung erstmal zufrieden. Flexibel sind die Anzahl der Slots in beide Richtungen auf der Textur festlegbar, und das Housekeeping tut was es soll, neue shared RenderTextures werden sauber und transparent im Hintergrund angelegt oder wieder entfernt.

Einziges Problem was ich nun noch in den Griff kriegen muss bevor ich mich mit dem gleichen Prinzip an die ComputeBuffer mache ist das jetzt aufgetretene Bleeding aufgrund des Atlas in den Griff zu kriegen.
Da ich mich damit noch nicht eingehender beschäftigt habe muss ich jetzt mal schauen ob ich das durch Padding auf der RenderTexture in den Griff kriegen muss (sehr ungerne eigentlich) oder ob ich das eher durch Anpassung der UVOffsets und Scale im SurfaceShader angehe.

Was meint ihr was zielführender wäre?





EDIT: Einfache half pixel correction war der Trick bei der Berechnung des UVOffset und des Tile-Scale. Jawoll, geil! Jetzt kann ich mit dem shared ComputeBuffer beginnen.

Klasse, sieht vielversprechend aus!

Sieht schon sehr nützlich aus!

sushbone hat geschrieben:Da ich mich damit noch nicht eingehender beschäftigt habe muss ich jetzt mal schauen ob ich das durch Padding auf der RenderTexture in den Griff kriegen muss (sehr ungerne eigentlich) oder ob ich das eher durch Anpassung der UVOffsets und Scale im SurfaceShader angehe.

Welches Bleeding meinst du denn? Die Naht von einem halben Texel, die man auch auf den Bildern sieht (wäre ein Fall für UV-Offsets), oder was Größeres?

Krishty hat geschrieben:Sieht schon sehr nützlich aus!

sushbone hat geschrieben:Da ich mich damit noch nicht eingehender beschäftigt habe muss ich jetzt mal schauen ob ich das durch Padding auf der RenderTexture in den Griff kriegen muss (sehr ungerne eigentlich) oder ob ich das eher durch Anpassung der UVOffsets und Scale im SurfaceShader angehe.

Welches Bleeding meinst du denn? Die Naht von einem halben Texel, die man auch auf den Bildern sieht (wäre ein Fall für UV-Offsets), oder was Größeres?

Genau, die Naht auf dem ersten Bild. Hab ich aber in der Tat durch eine Anpassung der UV-Offsets (Verschiebung und Verkleinerung um einen halben Pixel) hinbekommen, Ergebnis ist das letzte Bild.
Passt, ich mach erstmal einen Haken an die Atlastextur und versuche mich jetzt an einem "AtlasBuffer" ;-)

Ich denke ich bin nah dran, aber jetzt hänge ich doch noch an der letzten Stelle fest bei den ComputeBuffern. Frage an die Vertex Shader Profis. ;)
Ich versuche rauszufinden wie ich den Offset in den Vertex Shader integriere beim lesen des Buffers.

In C# erhöhe ich den Count des Buffers mit Multiplikation der Slots: Der ComputeShader schreibt in die unterschiedlichen Slots per zusätzlicher Multiplikation mit dem Slot offset (constants.sharedPatchGeneratedFinalDataBufferOffset = 1,2,3,..n): Die Frage ist, wie passe ich den Vertex Shader an um nun vom richtigen Offset zu lesen (aktuell "float4 position = patchGeneratedFinalDataBuffer[v.id].position;")? Aktuell sieht der noch so aus: