-
Notifications
You must be signed in to change notification settings - Fork 1
Material Abstraction #29
Copy link
Copy link
Open
Labels
component: bindingsRelated to Python Bindings generationRelated to Python Bindings generationcomponent: engine objectsRelated to objects from the engine itself (e.g. Cameras, Lights, Meshes, etc.)Related to objects from the engine itself (e.g. Cameras, Lights, Meshes, etc.)component: shadersRelated to creating/updating/refactoring glsl shaders from the engineRelated to creating/updating/refactoring glsl shaders from the enginetype: docstype: feature
Description
Metadata
Metadata
Assignees
Labels
component: bindingsRelated to Python Bindings generationRelated to Python Bindings generationcomponent: engine objectsRelated to objects from the engine itself (e.g. Cameras, Lights, Meshes, etc.)Related to objects from the engine itself (e.g. Cameras, Lights, Meshes, etc.)component: shadersRelated to creating/updating/refactoring glsl shaders from the engineRelated to creating/updating/refactoring glsl shaders from the enginetype: docstype: feature
Projects
StatusShow more project fields
Todo
Description
This keeps track of the implementation of the
material_ttype. We currently don't know whether to have a separate type for each material type or just have a single object that handles types by an enum.One of the key differences with our previous implementation is that a given material type (e.g. LAMBERT) should be linked to a specific shader (or shader chunk). This is similar to how ThreeJS handles materials, and it looks that their master-shader approach is the best option going onward with our material system implementation.
Tasks