Refactor(?) VertexLayout

VertexLayout.hpp enthält ein VertexAttribute struct, dass aus dem asset loading entnommen wurde. Das wird jetzt verwirrenderweise gemixt mit dem vom Framework zu nutzenden VertexInputAttachment und VertexLayout, vor allem bei der shader reflection und bei der Erstellung der graphics pipeline.

Das issue hier soll das etwas vereinheitlichen und/oder aufräumen.

created merge request !61 (merged) to address this issue

mentioned in merge request !61 (merged)

mentioned in commit bf7c6167

Der ganze Spaß wurde aufgeräumt und vereinheitlicht. Allerdings gibts noch ein paar "Unschönheiten" zwischen framework und asset loader module, bzw. dem mesh.

Man weiß irgendwie nicht genau, ob es jetzt ein interleaved buffer ist, also ein großer buffer, der alle vertex Attrtibute nacheinander hält, oder eben mehrere buffer, die jeweils einzelne vertex Attribute halten.

Noch komischer, Blender macht scheinbar einen großen buffer, der dann aber trotzdem nicht interleaved ist?!? Also müssen dann mit demselben buffer multiple vertex buffer bindings erstellt werden, damit der cube ordentlich gezeichnet werden kann?

@thollmann Hast du da eventuell Vorschläge zu?

@awasmut Der Asset loader zieht die zum Teil bereits auseinander. Also wo blender alles in eine binary file packt, trennen wir zumindest index buffer von vertex buffer in zwei Speicherblöcke auf.

Ob etwas interleaved ist oder nicht geht ja aus den Werten wie stride und offset hervor, aber sollte das nicht in jedem Fall egal sein weil es einfach behandelt werden kann? Also wir haben pro Mesh >= 1 VertexGroup die jeweils einen indexBuffer und einen vertexBuffer haben und zu jedem vertexBuffer (byte array) gibt es halt ein VertexAttribute, das nur den Inhalt dieses Buffers beschreibt.

Übersehe ich da gerade irgend ein Problem?

Ich glaube das einzige Problem aktuell ist, dass alles manuell in der main.cpp zusammengebastelt werden muss (Bindings, Locations, Offsets, Strides aus Shadern und Assets). Zusätzlich liegt der Großteil der Pipeline nur in Configs vor und teilweise sind da vermutlich auch Informationen redundant, weil es noch nicht stark abstrahiert ist.

Meine Idee war inzwischen diese Schritte alle im Szenen-Modul zu automatisieren. Da man in der Szene eher Mesh-Objekte manipulieren will als Vertices etc.

Hoffentlich verschwindet dann eine Menge Code aus den Anwendungen. Allerdings warte ich aktuell noch auf das Material-Modul, Asset-Loading und die Cameras, dass sie gemerged werden können. Das wären voraussichtlich dann alles Dependencies für das Szenen-Modul.

Wie gesagt, es sind nur Unschönheiten. Dachte, dass wir da etwas Ordentlicheres zu haben. Wir unterstützten jetzt sowohl ordentlich interleaved buffer als auch buffer mit getrennten bindings. Es ist halt für mich zumindest ein bisschen komisch, dass die Daten alle in einem fetten vertex buffer liegen und dann aber nicht interleaved sind, sondern man denselben buffer durch unterschiedliche bindings beschreiben muss. Das ist irgendwie ein nicht guter Mix von beidem.

Naja, jedenfalls, ich nehme die offset Berechnung aus der reflection raus, die zu berechnen ergibt erst Sinn, wenn man das im Kontext eines bindings sieht, danach kann das hier gemerged werden.

mentioned in commit 92d23240

mentioned in commit 055a35fb

closed with merge request !61 (merged)