Anfaenger

1) Do you create separate immutable constant buffers (ID3D11Buffer*) for each material instance (StateGroup in your terminology from other thread) during loading?

(if i understand you correctly, material parameters defined by artists don't change at runtime so the CBs can be simply bound to slots without costly updating.)

 

2) How is your StateGroup structure defined in code?

 How do you resolve pointers to graphics resources when loading StateGroups?

 Does your low-level platform-independent graphics layer have functions like UpdateConstantBuffer(), SetConstantBuffers(), SetSamplers(), SetTextures() ?

 

mine goes like this:

 

// shader dependencies
struct rsShaderPass
{

TBuffer< HUniformBuffer > CBsItems; // handles to constant buffers
UINT16 CBsStart;

TBuffer< HSamplerState > SSsItems; // handles to sampler states
UINT16 SSsStart;

TBuffer< HShaderResource > SRsItems; // handles to shader resources
UINT16 SRsStart;  

// metadata for resolving shader dependencies (@todo: get rid of this crap)
rsShaderPassInfo	meta;

};

 

 

1) I need to block only in the editor mode, because the resulting code is simpler in my (small) experience:
I get a pointer and start manipulating the created mesh instance (e.g. move, rotate) or get an error screen.

2) Where can I find out more about efficient implementation of such a system (load request queue with fast access by request ids and minimum allocations) ?
Right now my queues are dynamic arrays and I perform a linear search to find requests by their ids.

3) So, your advice would be to delegate the task of managing temporary memory to the client?
(Then I'll have to think about fighting fragmentation on the client side.)

(In the background thread I'll be doing reading, decompression, pointer patching, setting external references (dependencies) to proxy objects and issuing requests to load them later.)

Thanks a lot, I'll look at that one !

(i hoped to find more data-oriented solution avoiding use of Boost/STL.)

Thanks for the answers, hopefully, my next material system will be much better than a nasty combination of inheritance abuse and multitude of .fx files.

i've decided to bite the bullet and write my own shader language parser/translator.
it will also be used for parsing resource declarations (render targets, sampler,depth-stencil,rasterizer and blend states, state blocks and vertex formats)
and generating most of boilerplate code (especially D3D11-style verbose initialization stuff, description structs should be filled in automatically).

Thanks, Hodgman, this info is super useful!

1. Where do you keep 'shader resources' (such as pointers to material textures) and how do you bind them to the pipeline?

2. Do your shaders carry additional information about allowed render passes, vertex formats, etc. ?
(e.g. shader for filling g-buffer should only be used during SCENE_PASS_FILL_GBUFFER.)

casting to a native C struct is a better solution than hardcoded semantics, imho.
i still can't imagine having no material class (dunno how i would reference materials in assets and set material properties).