Render Component + Material Component

[ddiakopoulos]

The scene graph is reconstructed every frame to task the renderer. We typically clear the payload and assemble a renderable object. A renderable should be refactored to a render_component which might be cached with a dirty flag.

Separately, materials need one last refactor before being fully usable. Material instances are serialized into separate *.json files containing the uniform values and texture sampling info. A material_component simply has the handle to a material instance. To recreate a typical metalness/roughness scene, we would need N different materials, each with a single value changed... this is not ideal. Instead, what we actually need is for the uniform values to be stored as part of a material_component per entity (kind of a prefab). I am imagining that texture samplers are what define the material (and are largely responsible for requiring new shader variants), while uniform properties can be overridden on a per entity/material_component basis.

Any other thoughts @meshula ?

[meshula]

scenegraph vs framegraph -

My personal philosophy is that the scene is submitted once per frame, not retained by the engine; whereas the framegraph is built once per rendering scenario (eg., game level, attract mode, etc), and the scene elements are submitted against the framegraph. (Old notes: http://nickporcino.com/meshula-net-archive/posts/post42.html -- detailed implementation from a concurrency perspective: https://www.uni-kassel.de/eecs/fileadmin/datas/fb16/Fachgebiete/PLM/Dokumente/Master_Bachelor_Diplom/Johannes_Spohr_thesis.pdf )

materials -

This might be a bit of a monkey wrench. FWIW, I just got back from chatting at ILM about MaterialX, (http://www.materialx.org/) which has got roots at ILM and LucasArts from back in my day.

I'm planning to integrate Autodesk's shadergen fork of MaterialX into my own engine in the next week or so for testing. (https://github.com/autodesk-forks/MaterialX/tree/adsk_update_shadergen)

I'm hopeful that after that test, I'll want to advocate integrating MaterialX :)

In terms of the materials in material.hpp, I think that they are roughly equivalent to what's in the gltf2 spec (https://github.com/KhronosGroup/glTF/tree/master/specification/2.0). I say roughly because the gltf2 materials additionally specify an alpha interpretation in addition to values (mask, blend, ...). Being roughly equivalent is a good thing, because of the amount of available tooling for gltf2.

The Model IO material specification, and the USD shader preview material also cover roughly the same footprint. http://graphics.pixar.com/usd/docs/UsdPreviewSurface-Proposal.html

MDLMaterial and USDPreviewSurface add a clearcoat (second specular lobe) which is super useful for rendering manufactured things, like helmets and cars.

Hope these notes are useful.

[meshula]

https://github.com/autodesk-forks/MaterialX/blob/a54d4809c762d8b95ad1202dc01b409a96836ea7/documents/Specification/ShaderX.Draft.pdf

[ddiakopoulos]

render_component was introduced in 1fdd5c6d4ce0e2d9cc36a70e40057e013d28b54f and a larger material refactor will be coming in a new issue.