The way we go

at the patch side

There are exactly 3 nodes up to now, which have to eal with texture coordinates:

• Pipet
• VertexBuffer Join
• Vertexbuffer Split

these nodes have to deal with different ways how to input texture coordinates.

• textures aren't always 2d.
• we'd like to offer two texture spaces.

first a sketch of the nodes and their pins. afterwards some words on the naming decisions.

Pipet:

Pin "TextureCoords Space" allows to select

• "1D"
• "2D"
• "3D"
• "1D (World Space)"
• "2D (World Space)" default
• "3D (World Space)"

the pin actually receiving texture coordinates will be named:

• "TextureCoords"
• "TextureCoords.XY"
• "TextureCoords.XYZ"

• "TextureCoords.World Space"
• "TextureCoords.XY World Space" default
• "TextureCoords.XYZ World Space"

according to the selected option. the naming changes to reflect the selected option in the patch.

( .XY (.XYZ) means that this is a vectorpin which can be divided later on into different pins. this will be managed in a future version vvvv with vectorpingroups accessible by the gui. resulting pins after splitting:

• "TextureCoords.X"
• "TextureCoords.Y"

(* "TextureCoords.Z")
...

other pins:

• FilterWidth
• FilterHeight
• FilterMode: Box, Triangle

VertexBuffer Join/Split:

Pins "Enable TextureCoords i" allow to select

• "No" default for i>0
• "1D"
• "2D" default for i=0
• "3D"
• "1D (World Space)"
• "2D (World Space)"
• "3D (World Space)"

The Resulting Pins are labeled

• "TextureCoords i"
• "TextureCoords i.XY"
• "TextureCoords i.XYZ"

• "TextureCoords i.World Space"
• "TextureCoords i.XY World Space" default for i=0
• "TextureCoords i.XYZ World Space"

(The general idea of the "." in the naming of the pins is that the graph won't mind the text behind the "." when connecting pins. In that way it should be easier to implement mechanisms to keep the graph together, evene when dimensionalities or mode settings are changed.)

There should be one location in the wiki where the terms "World Space" and "Texture Space" are explained. It is very important to note that it is the World Space option, that means that texture coordinates will be transformed. If the user chooses "World Space", the coordinates entered in the patch will differ from the coordinates which are received by the shader.
That's why the "texture space" option looks more simple. However the default is the world space because of the inherent beauty of symmetry.

at the shader side

we always operate with texture space coodrinates.

putting the semantics "texturematrix" will result in altering the texture transformation, so that it will transform textures symmetrically. this semantics is set in all shaders coming from the open trusted vvvv shader development group.

vertexbuffers, xfiles, meshes

the texture coordinates in vertexbuffers / meshes range from 0..1.

World Space

   (-0.5 / 0.5 / -0.5) 
   

                                   (0.5/ -0.5 / 0.5)

Texture Space

   (0 / 0 / 0)

                                        (1 / 1 / 1)

Problem

Wir wollen

• x-Files und
• Effekte importieren,

und zwar eleganterweise ohne

• den Effekt umschreiben,
• Pins clever einstellen bzw.
• Spezialknoten einfügen

zu müssen.

Gleichzeitig soll klar transportiert werden in welchem Koordinatenraum sich Texturkoordinaten bewegen.
links,oben .. rechts,unten =? 0,0 .. 1,1 oder -0.5,0.5 .. 0.5,-0.5

• patchseitig und
• shaderseitig.

Optimal wäre natürlich, wenn man es patch- und shaderseitg mit den gleichen Texturkoordinaten zu tun hätte.

Man möchte (patchseitig)

• den (falsch implementierten) Pipetknoten benützen und
• Geometrien einfach erzeugen können.
• ..

und hat es direkt mit Texturkoordinaten zu tun.

Oder man möchte mit

• Grisplit
• ..

Texturtransformationen erzeugen.

Aber vor allem möchte man mehr funktionierende Standardfälle, bei denen man sich nicht um solche Spezialthemen kümmern muß, wie etwa, daß das importierte x-File

• keine Texturkoordinaten,
• solche mit falscher Anzahl an Dimensionen oder
• solche im falschen Koordinatenraum

enthält.

Lösung

Ansatz 1

Im Patch hat man es immer mit 0.5er Koordinaten zu tun.
Im Shader kommen diese auch so an. Lediglich die Transformationsmatrize ist durch Angabe der Semantic abgeändert. Wenn man dann im Shader mit dieser Matrize multipliziert, wird nicht nur die angeschlossene Texturtransformation ausgeführt sondern magischerweise auch in den directx-0..1er Raum umgerechnet. Dies muß äußerst klar kommuniziert werden. Für Leute die ein bischen mehr in die Details einsteigen müssen, (z.B. wegen Texturprojektionen, bei denen irgendwie 3dRaum und Texturraum zur Deckung gebracht werden müssen (Schattenthema)), möchten sehr genau wissen welche Transformationen nun wirklich dazugeschenkt werden.
(Übrigens ist bei so advanceten Topics auch relevant, daß einem noch eine Matrix einem dazugeschenkt wird, die bei den bisherigen Diskussionen noch nicht auftauchte, mir aber bei meinen Schattenprojektionen unangenehm reingrätschte: DirectX projectionspace: -1,-1,0 1,1,1. dagegen unserer -1,-1,-1 1,1,1. muss man nochmal genau verifizieren.)

Nun kann man sagen, daß sich die Dramatik etwas entschärft, da im Patch und im Shader die gleichen .5er Koordinaten benutzt werden (lediglich muss der Shader entweder manuell oder per Benutzung der Semantic dafür sorgen, dass die Koordinaten von .5er in 1er Koordinaten umgerechnet werden. Das heißt aber auch, daß Effekte die von Dritten kommen angepasst werden müssen, solange die semantic nicht eine allegemein übliche ist. Muss man verifizieren. Könnte ja sein dass viele Shader sowieso schon mit einer "TexturTransform" Semantic ausgestattet sind.

Also nochmal: die Lösung basiert grundsätzlich auf dem 0.5er Raum, der patch und shadersetig benutzt wird. Dafür muss man wenn man es genau nimmt auch beim importieren/exportieren von Xfiles umrechnen.

• + keine Spezialknoten
• + didaktisch sehr einfach zu erklären Texturkoordinaten = Objektkoordinaten
• + symmetrische skalierung/drehung ist standard

• - Effekte müssen angepasst werden (modifikation der semantik)
• - XFile import/export braucht eine option (0/1 texturen, vs. -1/+1 texturekoordinaten)
• - shaderscheiber müssen erklärt bekommen, daß directx-sampler ein anderes koordinatensystem benutzt. die müssen aber eh wissen, was eine matrix ist.

besser so:
variante:
im patch symmetrische koordinaten
im shader mit dx-kompatibler semantik werden die texturkoordinaten vorher über cpu auf 0..1 umgerechnet.
so kann jeder standardshader sofort funktionieren. minimaler performanceverlust, aber funktioniert. ischanged-berechnungen müssen sowieso irgendwann optimiert werden.

wer das nicht will benutzt die vvvv-eigene spezialsemantik, benutzt im shader symmetrische koordinaten und baut die eine zeile texturtransformation ein, dann hat man volle leistungsfähigkeit. den schritt muss man shaderschreibern erklären.

Ansatz 2

patch und shaderseitig 0..1er Raum.
Der Standard ist der 0..1er Raum. Zumindest bei den Render-Engines. Wie weit man mit den Texturräumen in 3dModellern zutun hat weiss ich nicht genau. Auf jeden Fall denke ich dass auch in allen gängigen Fileformaten 0..1 Standard ist.
Aus diesem Grund ist der User daran mehr oder weniger gewöhnt und das ist auch irgendwie wichtig.
Besonders reizvoll an dem Ansatz (also auch diesen 0..1er Raum zu benutzen) wäre, dass man nirgens hin oder her rechnen müsste. Der Nachteil ist klar, dass man oldschool-symmetrische Texturtransformationen nur mit einem Spezialknoten lösen kann. Jedoch ist dann die Stelle wo diese Extramatritze eingerechnet wird klar isoliert. Ausserdem kann man auch gerne mal einen Vertexshader schreiben, der keine Texturtransformation benötigt, aber schon mit Texturen umgeht. Der Nachteil bei der obigen Version ist ja auch, dass diese Endstufe (.5->.1) auf jeden Fall in den Vertexshader reinmuss, da ja alle Geometrien .5er Koordinaten haben. Wenn man dann mal einen aufwendigen Shader schreibt mit 16 Texturen/Samplern, dann gehen einem da möglicherweise wertvolle Instruktionen verloren... (HACK für diesen Fall: doch ausnahmsweise die Geometrie mit 0..1er Koordinaten versorgen, dann ist keine triviale Texturtransformation nötig)
Vorteile sind also: keine Spezialfälle im Xfile-Reader / -Writer, keine im Shader, keine Magie in der Semantic. Und dafür eine klare Schnittstelle ohne sich jemals wieder über diese Thema Gedanken machen zu müssen.
Das mit der Didaktik oben kann man auch nochmal ein bischen relativieren. Texturkoordinaten sind ja vielleicht doch nur im Fall des Quads und der orthogonalen XY-Projektion das gleiche wie die Vertexkoordinaten. (Den Fall der Schattenprojektion muss man sich eigentlich auch nochmal genau skizzieren. Jedenfalls habe ich in Erinnerung, dass man genau so eine implizite Umrechnungsmatrizze im obigen Modell auf einmal explizit reinpatchen musste. In diesem Modell hier: muss man noch evaluieren.)

Die Frage ist für mich auch wie unbedingt notwendig die symmetrische Transformation denn eigentlich ist. Sie ist zwar gewohnt aber nicht unbedingt essentiell.

Nachtrag:
Man kann auch hier eine Semantic einführen, also gleicher Nachteil / Spezialfall wie oben, jedoch ist das optional. Man braucht nicht unbedingt diese Semantic (dann wird nach links oben skaliert) bzw. man braucht überhaupt keine Texturtransformation (dann liegt die Textur auch vernünftig drauf), aber wenn man diese Semantic einsetzt wird halt symmetrisch skaliert. Das ginge dann so, dass beide Konvertierungsschritte (1 - > 0.5 und wieder zurück) im gleichen Atemzug passieren und man niemals mit dem 0.5er in Kontakt kommt. Wenn also die Semantic verwendet wird, rechnet der Effektknoten:

Texturmatrix = KonvertierungsMatrix_1_05 * TextureTransform * KonvertierungsMatrix_05_1

Damit spart man sich also auch den Spezialknoten.

• + Effekte müssen nicht angepasst werden (oder nur wenn man die oldschool variante unbedingt braucht)
• + XFile import/export geht schneller (wieviel?)
• + keine Spezialknoten
• - Texturraum geht von 0..1. dadurch inkonsistenz beim einsatz von defaultwerten bei spreads etc.

• - vorteile erschliessen sich nur experten (shaderschreibern) nicht patchern

gregsn: man sagt einfach: wenn du symmetrisch skalieren willst musst du die semantic in deinen shader reinhacken. (wie in ansatz 1)

die beiden punkte wiedersprechen sich :)

• + keine Spezialknoten
• - wer symmetrisch skalieren will, muss einen symtex knoten erklärt bekommen, für den man sehr weit ausholen muss, wenn man ihm einen anfänger erklären will

also ich (gregsn) denke man braucht keinen spezialknoten. sondern eine semantic wie in ansatz 1. wenn diese fehlt ist nicht so schlimm (die textur sitzt nicht völlig fies drauf). das ist schon ein vorteil.

ich würde sagen, dass vvvv shader auch standardmässig mit der semantic ausgestattet sind, damit textur transformationen wie bisher funktionieren. man merkt quasi keinen unterschied.

kommentar von joreg

a) um sebastians (gregor) these zu untermauern, dass 0..1 standard is ein link nach wikipedia. interessanteweise beschreibe die hier die koordinaten zwar genau andersrum, als die directXer (vermutlich so eine left-handed vs. right-handed sache zwischen opengl und directx. bei 3d-exportern gibts dazu immer die option: texturkoordinaten spiegeln) aber zumindest eben auch zw. 0 und 1

b) ich bin gegen die einführung eigener semantiken. semantics und annotations sind ein vorgegebenr standard und können nicht einfach von jedem verändert werden. das is wider die natur eines standards.
leider is der standard völlig unzureichend dokumentiert und mit DXSAS gibts da wohl bald nochmal eine neue unverständliche sache. ich kann jedenfalls nirgends eine liste aller gültigen semantiken finden.

wenn wir eigene semantiken einführen bedeutet das, dass sie in anderen programmen ignoriert werden und effekte, die in vvvv geschrieben wurden anderswo nicht funktionieren.

ergo

3. joregs ansatz

• texturkoordinaten im shader und im patch von 0-1.

_geringer erklärungsbedarf: jemand der von texturkoordinaten zum ersten mal hört wirds einfach so hinnehmen. jemand der sie schon kennt wird sie so erwarten. im einfachen pipet-demo-fall mit dem linearspread kann man endlich dann weiterhin ganz selbstverständlich die vorzüge von maprange im vergleich zu map demonstrieren.

• wer symmetrisch skalieren will verwendet das (diesmal etwas prominenter zu platzierenden) SymTex modul (das man in diesem zuge vlleicht sogar als knoten realisieren sollte). der user entscheidet also einfach im patch, ob er seine texturen wie in einem anderen effect-hosting-programm skaliert sieht, oder auf die coole vvvv art. ohne, dass er seinen effekt verändert, wodurch er ihn superlocker parallel in anderen programmen verwenden kann!

_geringer erklärungsbedarf: benutz es, wenn dus brauchst. wers verstehen will bekommts im SymTex helppatch erklärt.

• unsere effekte weisen lediglich eine besonderheit auf: texturkoordinaten werden als float3 spezifiziert, was sie kompatibel mit SymTex macht, aber nicht weiter schmerzt.

(gregsn: anders herum ist das natürlich auch ein problem von effekten anderer. die texturkoordinaten sind da standardmässig 2d was sie inkompatibel macht. kann aber eigentlich nicht sein sowas. nochmal evaluieren)

voila

• effekte können ohne anpassung aus anderen programmen übernommen werden und verhalten sich wie dort gewohnt
• erklärungsbedarf beschränkt sich auf optionalen einsatz des SymTex knotens

(gregsn: ja aber man verliert erstmal schon das gewohnte verhalten, was auch wieder zu abwärtskompatibilitätsproblemen führt. mit dem semantic-ansatz hätte man das gleiche verhalten)

ihre Einsätze bitte

für Ansatz 1 stimmen

• sbn

also wenn ich hier schon in der minderheit bin nochmal auf der meta-ebene:

das ziel von vvv war leuten ohne programmiererfahrung das programmieren von komplexen multimediaanwendungen extrem einfach und übersichtlich zu machen.
d.h. klarer, schneller, eleganter und einfacher als in anderen programmen.

die lücke, die vvvv zu schliessen versucht, ist leute, die sich mit programmierung nicht auskennen, dazu zu bekommen, anspruchsvolle - neue - sachen selbst zu schreiben zu können.

ich sage, das funktioniert sehr gut. den weg sollten wir nicht verlassen. eher noch aggresiver begehen.

wir haben immer versucht, sachen eleganter und klarer machen als in anderen programmen. wenn andere programme sachen unlogisch machen, sollten wir uns nicht daran halten. unsere nutzer scheinen diese haltung ja auch zu verstehen und zu mögen.

jedes detail, was nicht selbsterklärend ist, ist ein schritt in die falsche richtung.

shaderkompatibilität: den mitgelieferten shadern muss letztlich genausoviel aufmerksamkeit gewidmet werden, wie den mitgelieferten knoten. shaderschreiben wird immer ein expertenthema bleiben. irgendwo gefundene shader werden immer probleme haben - da lieber auf den nächsten standard warten, und sich dann streiten.

und: bevor man da kompatibilitätsoptimierungen macht, wäre ich dafür, erstmal eine liste zu machen, wo das shaderimportieren viel fundamentaler hakt (multipass etc.).
die fehlende transformation kann man shaderexperten (die also eh über transformationsmatrizen bescheid wissen müssen) leicht erklären (wenn man sie nicht über eine semantik lösen wollte) auf dem level erklärt sich das in wenigen sätzen.

die vereinheitlichung von textur- und 2d-räumen ist ein ganz wesentliche vereinfachung für leute, die geometrien selbst erzeugen wollen, oder texturen als wesentlichen gestalterischen grundbaustein von 3d-chips verstehen. klar, wer wirklich weiss, wie 3d-datenformate funktionieren wird sich an irgendeiner stelle fragen, wie das funktioniert. aber dem typischen 3d-user ist es aber letztlich egal wie seine texturkoordinaten intern repräsentiert werden.

aber dieses detail schon vvvv anfängern aufdrücken zu müssen ist schlechtes design.

pitch on pole ist ein sehr gutes beispiel, was man mit vvvv machen kann - wie weit das gehen kann (und der patch wird endlich noch verständlicher, wenn man nichtmehr mit grid arbeiten muss) .

um diese art resultate muss es gehen.

sachen so zu machen, wie sie in anderen programmen üblicherweise gemacht werden, ist m.e. der falsche ansatz

dafür kennen auch viel zuwenige leute diese programme.

für Ansatz 2 stimmen

• gregsn

für ansatz 3 stimmen

• joreg

mehr zum thema

official microsoft documentation about annotations and effects
scheint veraltet zu sein. und ab jetzt dann DXSAS
und dann gibts noch eine scripting sache irgendwie...
scheint aber alles noch nicht ausgereift zu sein. wir sollten uns daher auf die semantics beschränken.