Flash 3D API Preview (openGL, DirectX)- Codename "Molehil"

[joeydee]

Eher noch WebGL, würde ich sagen.
Generell (also egal mit welcher API du üben willst) musst du dich in das Prinzip Vertex- und Indexbuffer sowie Shader einarbeiten. Vor allem verstehen, was wann und wie oft an die Grafikkarte gesendet werden muss, wie man darauf referenziert (also die hochgeladenen GPU-Daten nutzt), wie die Datenfolge in einem beliebigen Vertexbuffer-Stream dem aktiven Shader "bekannt" gemacht wird damit sie richtig verarbeitet wird, sowie die verschiedenen Variablenarten von Shadern (Constants, Variants, Attributes etc.) - Stichwort: Register.
Die Shadersprache wird wohl ausschließlich AGAL sein, eine Assemblersprache, die daher leider weit von Shader-Hochsprachen wie GLSL entfernt ist.
Aus den Links und Videos oben kann man den AGAL-Befehlssatz sowie die wichtigsten Klassen und Methoden der Molehill-API herauslesen. Wenn man mal was mit OpenGL o.ä. gemacht hat, kann man das alles sehr schnell zuordnen und verstehen.
Natürlich behält sich Adobe Änderungen in der API bis zum Release vor, aber das Prinzip selbst dürfte sich nicht mehr großartig ändern.

[WillyDilly]

Thx für die Info.

Hab mittlerweile so das Gefühl, dass Unity3D immer beliebter wird. Was meint ihr so dazu? Also ich selbst freue mich schon auf Molehil und habe auch vor mich intensiv auf Molehil vorzubereiten. Greetz

[joeydee]

Hab hier mal aus lauter Warte-Langeweile heraus die Molehill-Klassen herausgeschrieben, so weit man sie aus den verschiedenen offiziellen Präsentationen herauslesen kann. Syntaxmäßig dürften sich noch Kleinigkeiten ändern, und vollständig wird das natürlich auch noch nicht sein.

Vielleicht interessiert es ja noch jemanden:

Stage
- stage3Ds: Vector.<Stage3D> (4)

Stage3D
- viewport:Rectangle
- attachContext3D(context3D:Context3D):void

VertexBuffer3D
- uploadFromVector(vertexData:Vector.<Number>, offset:int, count:int ):void

IndexBuffer3D
- uploadFromVector(indices:Vector.<int>, offset:int, count:int):void

Program3D
- upload(avAgalcode:ByteArray, afAgalcode:ByteArray):void

AGALMiniAssembler
- agalcode: ByteArray
- assemble(programType:String, source:String);

Texture3D
- uploadFromBitmapData(bitmapData:BitmapData):void

TextureCube3D
- upload...???

Context3D
- Context3D(renderMode:String)
- clear(r:int, g:int, b:int, 1):void
- createVertexBuffer(length:int, numComponents:int):VertexBuffer3D
- createIndexBuffer(length:int):IndexBuffer3D
- createProgram():Program3D
- createTexture(width:int, height:int, byteFormat:String, false ):Texture3D
- drawTriangles(indexbuffer:IndexBuffer3D, offset:int, length:int):void
- setProgram(program:Program3D):void
- setProgramConstantsFromMatrix(programType:String, registerIndex:int, matrix:Matrix3D, transposed:Boolean):void //VC and FC registers
- setProgramConstantsFromVector(programType:String, registerIndex:int, vector:Vector.<Number>):void //VC and FC registers
- setVertexBufferAt(registerIndex:int, vertexbuffer:VertexBuffer3D, component:int, length:int):void //VA registers
- setTextureAt(registerIndex:int, texture:Texture3D):void //FS registers
- setupBackBuffer(width:int, height:int, 1, true):void
- swap():void


Context3DRenderMode
- AUTO

Context3DProgramType
- VERTEX
- FRAGMENT

Context3DVertexBufferFormat
- FLOAT_2
- FLOAT_3

Context3DTextureFormat
- BGRA

[WillyDilly]

Cool, vielen Dank.

[_geo_]

Es gibt wieder Neuigkeiten:

Flash Gaming Summit in San Francisco (of which we’re proud Gold Sponsors), Adobe has announced the public availability of a beta version of the Flash Player.

Video dazu (Molehill ab Minuate 33:25): FGS - Flash+ A Whole New Dimension for Games

Interessante Punkte:

• PixelBender 3D für Shadercode
• keine Fixed Function Pipeline
• aktuelle Flash 3D Engines mit den sie zusammenarbeiten (wieder keine Spur von papervision)
• ein ganzes Code Beispiel wie man ein Dreieck zeichnet
• Molehill APIs Dokus Beta Player und 3D Engines kommen bald (bzw. sind schon da)
• Pixel Bender 3D am 4ten März (Shader schreiben ;-)

FlashPlayer:Flash Player Incubator preview release

Unity3D + Molehill: Unity Technologies Blog Blog Archive Unity, Flash & 3D on the web

lg

[_geo_]

Flashplayer 11 Language Ref (API Dokumenation Download) (.zip)

Zitat von bytearray.org

Of course, as you can see, 2D content can overlay the 3D content with no problems, but the opposite is not possible. However, we will provide an API which will allow you to draw your 3D content to a BitmapData if required.[...]The Flash Player will still return you a Context3D object but using software fallback internally, so you will still get all the Molehill features and same API but running on the CPU. To achieve, this we rely on a very fast CPU rasterizer from TransGaming Inc. called “SwiftShader”. The great news is that even when running on software, SwiftShader runs about 10 times faster than today’s vector rasterizer available in Flash Player 10.1, so you can expect some serious performance improvements even when running in software mode.

[carsten cs]

Hallo

Ich bin vorhin auf den Pixelbender3d gestoßen
Adobe Pixel Bender 3D | vertex and fragment shaders, molehill - Adobe Labs

und habe mir mal die ersten erklärungen dazu zu gemüte geführt

Adobe Edge: January 2011 -Introducing Molehill: 3D APIs for Adobe Flash Player and Adobe AIR
und wenn ich das richtig verstanden habe, ist PixelBender die Kommunikationsebene von Flash zu openGl usw. ??

so z.B wie ich verstanden habe, kann Pixelbender3D vertexe verschieben, Materialien und Texturen zuordnen und im Falle von Reliefmaterialien nocheinmal die Vertexe verschieben?.

aber was ich noch nicht genau verstanden habe ist , wie die Aufgabenteilung zwischen openGL und Pixelbender3d ist. bzw. was kann openGl eigentlich schon alleine, ist das schon ein Standalonerenderer?

Wenn ich's richtig verstanden habe ist Pixelbender nicht der Renderer, sondern unterstützt das Rendern, indem er die Informationen zu den einzelnen Polygonen smootht, wie pixelBender das eben in 2D macht.

Aber darüber hinaus ..in wie weit ist da eigentlich PixelBender3D in den Render_Rechenprozess mit involviert??

Ich könnte mir z.B. gut vorstellen, dass die Berechnung von Lichtern Spiegelungen Reflexionen, gar nicht direkt von Pixelbender bewerkstelligt wird, sondern von openGl???

oder ist es so, dass wenn opneGl spiegelungen, Reflexionen berechnet (wohin geht der Sichtstrahl, Lichter und Reflektionen) , dass zwischdrinn dann immer Pixelbenderfunktionen aufgerufen werden, die die Eigenschaft des Materials bestimmen (so z.B. wie im Maxwellrenderer)???

Anmerk. : Gut fände ich auch, wenn man in der 3D api zusätzlich zu den openGl_liveKapazitäten eine Möglichkeit einbauen würde, eine Ansicht in flash nocheinmal aufwendiger (photorealistisch) rendern zu können.
z.B. der user dreht sich ein produkt in 3D so hin wie er es will ..dann wenn es positioniert ist, wirds nocheinmal aufwendiger gerendert.

[_geo_]

PixelBender dient in Molehill als Shadersprache wie z.B.: GLSL in OpenGL (würd mich auch nicht wundern wenn Adobe PixelBender einfach in GLSL übersetzt da die Grafikkarten ja sowieso meistens nur DirectX und OpenGL hardewarebeschleunigt unterstützen).

Die [...] Shading Language [...] ist eine Programmiersprache, um mit OpenGL auf dem Grafikprozessor eigene Programme, sogenannte Shader, auszuführen. Diese können die sonst stark limitierten und festen Verarbeitungsvorschriften [Anm.: genannt "fixed function pipeline"] der Grafikkarte (Grafikpipeline) teilweise ersetzen.

Aus technischer Sicht bezeichnet „Shader“ denjenigen Teil eines Renderers, der für die Ermittlung der Farbe eines Objektes zuständig ist [...]

Molehill hat keine "fixed function pipeline" und daher MÜSSEN Shader benutzt werden.

Wiki: Erklärung - Shader?

bekannte Shader-Sprachen sind:

• GLSL
• Cg
• HLSL

Shader "typen":

• Vertex-Shader
  - verändert z.B. die POsition der Vertices eines Objekts
• Geometry-Shader
  - kann neue Geometrie einfügen (z.B. tesselation bei einer displacement map)
• Pixel-Shader bzw. Fragment-Shader
  - interpretiert deine Daten (Geometrie, Textur, Maps etc.) und liefert als Ergebnis eine Pixelfarbe

Was PixelBender 3D also macht ist dass es den Shader für die Grafikkarte zur Verfügung stellt. Durch den Pixel-Shader werden deine Datenfragmente (Vertex, Polygon, Textur, Normalmap, Specularmap etc.) erst in Pixel interpretiert. Der Witz an Shadern ist aber dass das auf der GPU passiert (sofern diese die in der Shadersprache genutzen Befehle kennt [z.B. PixelShader 3.0 "API" auf DirectX]). Geometry- und Vertex Shader braucht man nicht immer sie dienen dazu spezielle Effekte zu erzielen. Der Pixel-Shader ist pflicht, ohne ihn siehst du nichts da keiner da ist der deine Daten in Pixel umwandelt

Da es in den neueren OpenGL Versionen keinen vorgegeben "Standard Shader" gibt der automatisch einen "Shader" erzeugt muss man nun immer selbst einen Shader angeben. Geschrieben wird dieser in Molehill eben mit PixelBender3D damit hast du die Kontrolle wie das Ergebnis dann aussieht.

lg

[joeydee]

PixelBender3D bietet eine High-Level-Sprache zum Shaderschreiben an. "High Level" heißt, ähnlich Actionscript: Funktionen, Variablen, Grundrechenarten, Zuweisungen, Compilezeit-Fehler abfangen,...

Kleiner Überblick, was zur Zeit in Molehill zur Shaderentwicklung angeboten wird:
Die Molehill-API selbst versteht nur Assembler, das sind nur Zahlen (Bytes), die in Wirklichkeit Funktionen und Register bedeuten, die es auf der GPU gibt. (Fiktiv Ein Byte-Array mit den Werten 165,223,198,76 könnte da bedeuten: nimm Daten aus Register 17, multipliziere mit den Daten aus Register 28 und lege das Ergebnis in Register 3 ab. In Wirklichkeit noch viel komplizierter; da gehören immer mehrere Bytes zusammen und es werden einzelne Bits maskiert um verschiedene Optionen zu schalten etc. Kann sich kein Mensch merken, geschweige denn bequem damit programmieren und debuggen.

Adobe bietet daher eine Klasse "AGALMiniAssembler.as" an, mit deren Hilfe man stattdessen "mul vt3,va0,vc2" in einen String schreiben kann (nimm Daten aus va-Register 0, multipliziere mit vc-Register 2 und schreibe das Ergebnis in vt-Register 3). Die Klasse kümmert sich dann um die Übersetzung in den richtigen Bytecode, den man dann wiederum an Molehill schicken kann.

In einer High-Level-Sprache (fiktiv, da ich mich mit PixelBender3D noch nicht befasst habe) kann das dann so aussehen (viele völlig andere Dialekte sind denkbar):
temp ergebnis;
attribute vertexFarbe;
const helligkeit;
ergebnis=vertexFarbe*helligkeit;

[carsten cs]

@joeydee

bei Deinem Beispiel:

Zitat von joeydee

temp ergebnis;
attribute vertexFarbe;
const helligkeit;
ergebnis=vertexFarbe*helligkeit;

const helligkeit sind wahrscheinlich die Helligkeiten, die sich aus der ganzen 3DUmgebung und der Beleuchtung für das entsprechende Polygon ergeben.

Wird diese Konstante eigentlich von openGl oder directX berechnet ???...oder wird es in Molehill auch die Möglichkeiten geben, oder gar die Notwendigkeit, so etwas wie const helligkeit zu berechnen???


stellt eigentlich jede Grafikkarte opneGL, direktX bzw. allgemein 3Drenderings in gleicher Qualität dar, oder hängt die letztendliche 3D Qualität auch von den Grafikkartenab. z.B. wie häufig Licht reflektiert wird, und in welcher Qualität. Die eine Grafikkarte berechnet vielleicht bis zu 4 Lichtreflektionen, die andere weniger. Eine Grafikkarte berechnet vielleicht auch noch diffusabstrahlendes Licht, die andere nicht??



Nachtrag:
openGL benutzt für die Lichtberechnung wahrscheinlich die oben genannten Registries ? für jedes Polygon wird vielleicht eine registrie eingerichtet ? , in der alle Lampen und Reflektionen nach einander eingetragen werden?

[joeydee]

Vergiss mal, in OpenGL- und DirectX-Kategorien zu denken. Genau das macht Molehill im Hintergrund für dich (nicht PixelBender3D), nämlich die verschiedenen APIs wrappen.

Lies bitte genau: mein Beispiel war rein fiktiv um zu zeigen was in einem Shader stehen kann bzw. wie sich die genannten Sprachen unterscheiden können.
In meinem Beispiel wird einfach nur ein Farbwert mit einem Helligkeitswert multipliziert. Was das zu bedeuten hat bzw. was auf dem Bildschirm landet hängt von dem gesamten Kontext ab. Ich kann auch einen Shader schreiben mit brot=3*kuchen, was genauso viel und genauso wenig zu bedeuten hat.

Ich glaube du stellst dir das noch ein wenig zu einfach vor. Die Grafikkarte berechnet keine Reflexionen etc. - DU schreibst ein Shaderprogramm, das die Pixel so berechnet wie du sie sehen willst, und DU bist dafür verantwortlich, dass das Programm auf der GPU landet und die Infos bekommt die es benötigt (Vertexpositionen, Normalen, Farben, Texturkoordinaten, Lichtquellen, Matrizen, Texturen,... je nachdem was dein Shader machen soll).
Alles was die Grafikkarte für dich macht, ist einfach dein Programm extrem schnell auszuführen, ohne dass dein Prozessor davon belastet wird.
Wenn dein Pixelshader extrem einfach ist (z.B. "mov oc fc0") und im Register fc0 die Werte "1,1,1,1" stehen, spuckt es nur einfarbig weiße Flächen aus, ohne Schattierung etc. Und wenn dein Vertexshader sich nicht um 3D-Transformationen und 3D-Projektion kümmert, ist es nichtmal 3D was rauskommt.
Wenn du Spiegelungen etc. sehen willst, muss dein Programm entsprechend komplex werden (und du musst eine Menge von 3D-Mathe verstehen).

Du solltest unbedingt das grundlegende Prinzip von Vertex- und Pixelshadern verstehen lernen.

[carsten cs]

Also danke erstmal für die infos.

habe gerade das pixelBender3D manual angefangen zu lesen, das bei dem PixelBender3D Download mit dabei ist.

ja du hast recht alles scheint doch viel komplizierter zu sein. ... diese Vorgehensweise von Molehill ..also dass der 1. Vertexshader für die Perspektive da ist . der 2. für die Materialien bzw bumb und so und der 3. der dann die polygone (2D Fragment) (automatisch?) in perpektivischer verzerrung berechnet.
..also diese Vorgehensweise, ist die auch nur eine von vielen Möglichkeiten, oder genügt diese, um z.B. Lichter, Schatten, diffuse Lichtreflektionen zu berechnen?


Wie wrd adobe den Wiederspruch lösen, dass die shader gleichzeitig grundlegende 3d Funktionen übernehmen müssen, aber wenn man 3d effektiv als Durschnittsprogrammierer benutzen will , man mit den shadern arbeiten muß??? Wie wird da die schnittstelle aussehen? wenn die überhaupt möglich ist.

Oder wird guter Adobe shader code öffentlich werden, den man dann einfach erweitern oder manipulieren kann?. Gibt es da schon öffentliche shader, z.B. openSource Lösungen von away3D?


Zu diesem Beispiel mit den Wassertropfen auf der away3D Seite:

denkt ihr , dass soetwas schon mit den 3d Engines möglich wäre? Eigentlich funktioniert das doch nur so gut, weil die vertexe mit shadern auf der GPU manipuliert werden. Um so etwas zu realsieren, müßte man die Möglichkeit haben in 3D engines mit den shadern zu arbeiten .. oder ?? Letztendlich wird das aber wohl noch alles in der Entwicklung sein.

[joeydee]

Genau. Molehill ist ausschließlich zu dem Zweck geschaffen, 3D direkt an der Quelle (GPU) zu programmieren. Für "Durchschnittsprogrammierer" wie du sie nennst verweist Adobe auf die Engine-Entwickler wie Away3D.
Aber jeder, der programmieren kann, kann sich grundsätzlich auch in die Shader-Philosophie reindenken.

Das Folgende passiert in ganz groben(!) Zügen, wenn eine Ansammlung von Dreiecken via Shader auf den Bildschirm soll. Alles was fett ist, lässt sich komplett ändern. D.h. wenn man da ganz andere Sachen schreibt und Werte übergibt, wird auch was ganz anderes gemacht. Für Spiegelungen, mehr Lichter etc. muss man auch mehr Werte übergeben und in den Shadern mehr Berechnungen durchführen.


Info an den Vertexshader: jetzt kommt gleich eine 8er-Folge an Daten, je zu 3,3 und 2 gruppiert. Der Datenstrom ist:
x,y,z,normaleX,normaleY,normaleZ,texturX,texturY,x ,y,z,normaleX,normaleY,normaleZ,texturX,texturY,x, y,z,normaleX,normaleY,normaleZ,texturX,texturY,x,y ,z,normaleX,normaleY,normaleZ,texturX,texturY,x,y, z,normaleX,normaleY,normaleZ,texturX,texturY,x,y,z ,normaleX,normaleY,normaleZ,texturX,texturY,...

Daten an den Vertexshader:
in die GPU-Variablen "vc0" bis "vc3" werden insgesamt 16 Number-Werte (=4 Vektoren) geschrieben, die die ModelViewProjection-Matrix darstellen. Diese wird vorher in Actionscript nach einem festen Schema berechnet und beinhaltet Positionen und Transformationen von Objekt, Kamera und Perspektive.

Daten an den Fragmentshader:
Lichtrichtung und -farbe werden jeweils als Vektor (xyz und rgb) in die GPU-Variablen "fc0" und "fc1" geschrieben.
Die Textur wird in die GPU-Variable "fs0" geschrieben.

Info an die GPU:
bitte führe den Vertexshader nacheinander mit den oben angegebenen 8er-Folgen Nr. 0,1,2 aus, danach mit Nr. 0,2,3, dann ...

Vertex Shader:
Für jede ankommende (8er, s.o.)-Folge, mache Folgendes:
- die erste Dreiergruppe im Stream mit den Registern "v0" bis "v3" multiplizieren.
- das Ergebnis ist die Position auf dem Bildschirm dieses Punktes, inkl. Tiefeninformation. Bitte als Bildschirmposition in "op" zwischenspeichern.
- die zweite Dreiergruppe sagt, in welche Richtung die Oberfläche an diesem Punkt schaut (Normale). Bitte Modelldrehung beachten und in "va0" zwischenspeichern.
- die letzte Zweiergruppe sind Texturkoordinaten für diesen Punkt. Bitte in "va1" zwischenspeichern.

Zwischen Vertex- und Fragmentshader passiert für je 3 berechnete Punkte aus dem Vertexshader immer Folgendes (keine Eingriffsmöglichkeit):
- je drei aufeinanderfolgende Bildschirmpositionen ("op") aus dem Vertexshader gehören zu einem Dreieck. Interpoliere alle anderen Werte, die außerdem noch zwischengespeichert wurden (alle "va..."-Variablen).
- für jedes Bildschirmpixel in diesem Dreieck, führe den Fragmentshader mit den interpolierten "va..."-Werten aus.

Fragment Shader:
für das aktuelle Bildschirmpixel, mache Folgendes:
- berechne das Punktprodukt zwischen interpolierter Normale "va0" und Lichtrichtung "fc0".
- beschneide das Ergebnis in einen Bereich zwischen 0 und 1, multipliziere mit der Lichtfarbe "fc1" und speichere in "ft0".
- lies den Farbwert aus der Textur, die in "fs0" liegt, und zwar an der Stelle die in "va1" steht.
- multipliziere den Texturwert mit dem vorher berechneten Lichtwert in "ft0" und speichere das Ergebnis in "oc".

Nach dem Fragmentshader passiert für jedes Bildschirmpixel immer Folgendes (bedingte Eingriffsmöglichkeit):
- färbe das aktuelle Bildschirmpixel mit dem Farbwert aus "oc" ein und merke dir den aktuellen Tiefenwert an dieser Stelle (zeichne das Pixel nur, falls der aktuelle Tiefenwert kleiner ist als der dort gespeicherte Tiefenwert)

[mildesign]

Lee Brimelow
hat ein bisschen was zu Molehill zusammengestellt.

https://spreadsheets.google.com/pub?...0E&output=html

Michael Rennie hat ein Quake 3 Port erstellt. Da kommen Erinnerungen hoch
Quake 3 for Flash Player using Molehill and Alchemy



quelle:
theFlashBlog New Molehill Demo Reel Video

[Flash_Blog]

Vielen Dank fürs Zusammenstellen der vielen Infos! Mal sehen wie das mit Molehill weiter gehen wird!
Auch wir versuchen weiterhin über Flash und 3D auf dem neuesten Stand zu sein...