bruop / bdr11 Goto Github PK

While I (believe) that I already have normal mapping working fine, it'd be good to have an example that just renders the normal map and nothing else!

This might force me to expose an API for creating custom materials (in addition to what I have now).

Right now Views are part of Game (??) but they should probably be owned by the RenderGraph instead.

Right now I've just got a big old function that makes all the DX11 code, but it'd be nice to a little interface for render passes/techniques (not sure yet what name is appropriate) so that it's straightforward to add more passes in the future, and ensure that each pass cleans up after itself, etc.

Right now our Mesh and MaterialInstance are all part of separate objects that are indirectly assigned to the entity using a component.

Instead, I think I will just consolidate our render objects -- then we don't need access to the entity component system to render them outside of visibility checks, AND for CB data (transforms, additional material data?)

Eventually, I think we can just copy the CB data after the visibility checks and then we really wont need ECS access.

Right now they are the biggest part of our API that touches both our Game and Graphics modules.

We might consider calling them "RenderSystems"

• Should include clear statement of goals
• Style guide for my own good

• Add component for storing PBR factors as defined by the GLTF spec
• Add support for samplers
• Potentially: add support for shader permutations

In addition to adding state to animations, it'd be nice to be able to play them using a UI.

Right now all animations will start playing after loading the model, but ideally we'd like to be able to pick and choose with animations to play

The idea is to make our materials closer to the Pipeline State Objects in Vulkan or DX12

This would also enable us to make our render passes more generic

However, the flip side of this is that eventually we will want to sort our entities (at draw time, probably) to minimize state changes. This would also enable us to batch calls to functions like D3D11Buffer*->Map more easily (I think)

A major caveat, however, is that our render passes will render our objects with different materials! So we'll have to take that into consideration.

I was thinking we could follow the approach outlined by OurMachinery, which basically has materials act as an abstraction that collects all the different pipelines used to render the mesh.

I'm still not certain how we'll store handles to the RBOs for each Pipeline associated with a mesh.

Previous ideas:

• Register the entity/renderObject directly with passes which can maintain their own list of RBOs. The problem with this is it becomes that much more complicated to set/update the data in the RBOs.
• Just keep a small Map of the different RBOs for each Pass/Pipeline, and store that as part of our materialInstance/renderObject

I'm not really satisfied with either solution to be honest, but this would make it much easier to define new materials and drive the entire rendering process in a data driven way

Consider only importing d3d11 specific stuff there

Right now I'm creating meshes, buffers, UAVs and SRVs by making direct calls to the DX11 API from within my GLTF model loader. I think it'd be a huge improvement to abstract these resources a bit.

Right now I'm creating buffers for vertex data, constant buffers and joint buffers. Then UAVs and SRVs are created by hand depending on my needs.

Instead, it'd be good to have some flags on how a resource will be used, and determine the subresources that need to be created as a result. For vertex buffers, I'll likely break apart this intermediate structure as I store buffers, to make it easier to interact with the DX11 API

(with skinning)

• Add loading of skinning info and buffers from gltf files back
• Separate the preskinned and transformed vertex buffers
• Implement compute shader to output transformed buffers

• Make enums all uppercase
  - [ ] Make all unscoped enums use an appropriate prefix to prevent namespace collisions
• Consider what to do about DirectX Simple Math
• Remove items from precompiled headers that we're not actually using
• Move all Rendering Resources to their own header, with free functions in a separate file.
• Consider using namespaces for our free functions, to make them easier to find.

VS won't stop yelling at me about this

The idea here is to have some intermediate format that we can bucket/sort before submitting to the GPU.

Why

The idea is that we want to minimize state changes on the GPU side between draw calls.

How

• Related to #21, although we can proceed in either order
• Create a pathologic example case and profile it
• Come up with an intermediate representation of draw calls -- see below
• Implement sorting of draw calls and profile again