Resolve "Material (Modul)"

Closes #57 (closed)

added 🍪 ToDo 👍 Feature labels

added 1 commit

• 62e48a01 - [#57 (closed)] Directory added for the module with basic cmake setup

Compare with previous version

added 54 commits

• 62e48a01...84c7c24c - 53 commits from branch develop
• 4d60a22a - Merge branch 'develop' of gitlab.uni-koblenz.de:vulkan2021/vkcv-framework into 57-material-modul

Compare with previous version

added 1 commit

• bb2f8d13 - WIP: pbrMaterial skeleton class.

Compare with previous version

added 1 commit

• 997b2002 - namespace fix.

Compare with previous version

added 1 commit

• fd10de2b - [#57 (closed)] Fixed framework includes

Compare with previous version

Sinnvoll wäre vermutlich eine create()-Funktion für ein Material, welche ein Core-Objekt übergeben bekommt, um automatisch ein DescriptorSetHandle zu erzeugen, an welches die angegebenen Images gebunden werden. Zusätzlich wäre auch vorteilhaft den Fall abzudecken, dass manche Sampler oder Texturen nicht valide übergeben und übernommen werden. Stattdessen könnten andere Defaults erzeugt und verwendet werden bei dem neuen Material.

added 1 commit

• ba11a7ef - [#57 (closed)] WIP: added create function

Compare with previous version

Habe mal die create-Funktion angefangen. Weiß noch nicht genau ob das erstellen und der write-Teil so ausreicht?

Und falls Sampler oder Images nicht vorhanden sind / inkorrekt geladen werden und durch defaults ersetzt werden sollen, dürfen die member nicht "const" sein oder? Alternativ könnte man die Funktion in den Constructor verschieben.

Die Defaults müssen noch gemacht werden.

Ansonsten buildet das Projekt bei mir nicht, und scheinbar auch generell in Windows nicht?

added 1 commit

• 53cf2d62 - [#57 (closed)] WIP: added Validation

Compare with previous version

Andere Sache noch: Wollen wir die Klasse vielleicht nicht "PBRMaterial" oder "PbrMaterial" nennen? Zumindest haben wir uns ja in den Coding-Conventions auf Camelcase geeinigt haben.

Ich denke, wir sollten auch das DescriptorSetHandle in die Material-Klasse packen (also die abstrakte Super-Klasse). Das wäre ja potentiell die Gemeinsamkeit zwischen unterschiedlichen Materialien und die Verwendung von dem DescriptorSet könnte dann auch von erbenden Klassen gleich verwendet werden.

Okay, das macht Sinn. Ich werde es dementsprechend anpassen, also:

• statische create Methode wie oben beschrieben
• Umbenennung in PBRMaterial
• Verschiebe das Descriptor-Set-Handle in Material

added 1 commit

• 50c8675c - [#57 (closed)] renamed from pbrMaterial to PBRMaterial

Compare with previous version

added 1 commit

• dfa6d222 - [#57 (closed)] fixed error from renaming

Compare with previous version

added 1 commit

• 49066023 - [#57 (closed)] changed to static create method

Compare with previous version

added 1 commit

• cdbfa863 - [#57 (closed)] moved descriptorSetHandle to material-class

Compare with previous version

Fehlen jetzt noch default-Texturen und Einbindung des Asset-Loaders

added 155 commits

• cdbfa863...d97962c3 - 154 commits from branch develop
• 459dc325 - Merge branch 'develop' into 57-material-modul

Compare with previous version

Beim compilen ist mir aufgefallen, dass das Material auf eine VKCV-Klasse zugreift und die benötigt die Vulkan.hpp aber findet diese nicht. Für das Erstellen der Defaults bräuchte ich die auch (für z.B. vk::Format::eR8G8B8A8Srgb) Ich glaube die wird in der Cmakelists von dem Modul nicht hinzugefügt. Sollen wir die hinzufügen / war das der Plan? Oder wollten wir das vermeiden?