TiagoCosta

Hi,

I'm trying to debug a pixel shader in VS2012 but I can't access the pixel history because "This draw call is using system-value semantics and interferes with pixel history computation"

The vertex shader generates a fullscreen triangle using SV_VertexID...

Is it impossible to debug pixel shaders associated with vertex shaders that use SV_VertexID?

Thanks

My renderer was designed following ideas from frosbite rendering architecture, and other topics.

I tried to remove all special cases making it as generic as possible (capable of handling multiple rendering paths/techniques).

Because of its "generic nature" it relies heavily on loops.

Each resource must contain multiple StateGroups (one for each rendering stage it can be drawn), example:

-Mesh structure contains 2 state groups:

1-only binds the vertex buffer containing vertices positions; (used in depth only/shadow passes)

2-bind both the vertex buffer containing vertices positions and and vertex buffer containing normal, tangent, texture coordinates (for gbuffer pass/forward rendering)

drawActor(Actor* pActor, u8 passID)
{
    pActor.getStateGroup(passID);
    pActor.model.mesh.getStateGroup(passID);

    for(Subset s in pActor.model.getSubsets())
    {
         s.material.getStateGroup(passID);
         s.getDrawCall();
    }
}
    

Each getStateGroup(passID) contains a loop to find the StateGroup associated with passID.

--

Each StateGroup contains commands and a bitset used to select which shader permutation to use.

So there's another loop used to find the correct shader permutation that must run before executing each draw call, since I cannot predict which permutation will be used (?).

Possible solution:

"Caching" StateGroups in the Actor class so only a loop is needed - this prevents hot-reload of resources or I need to check dependencies and update the cached stategroups.

I'm having trouble coming up with a "solution" so any "outside-the-box" ideas will be appreciated.

Thanks.

Many game engines use a draw call sorting approach to create render queues (like this, Bitsquid also uses a similar system).

This works well when each stage (gbuffer pass, lighting) is only executed one time since you just have to set some bits in the sort key that identify the pass.

The problem appears when you have passes that might be executed multiple times like shadow mapping (and real time reflection maps) because it needs to be executed for each light on screen that casts shadows. There is a limited number of bits that identity each stage so you (probably) cannot simply assign each light a unique stage number.

I currently don't include stage bits in the sort key instead I have multiple "buckets" each bucket associated with a stage and render items are put in the buckets. Then the stages are executed in the defined order by rendering the render items inside each bucket, this way I can render the shadow map bucket multiple times.

In the end of the article I linked in the beginning of the topic the author wrote that this multiple buckets approach where draw calls are sorted inside the buckets was used in the PS2-era and nowadays draw calls from multiple stages are sorted together.

What am I missing?

(When I say "general" file formats I'm talking about non-engine specific file formats like 3ds, dae, xml, json, obj, etc)

Should game engines only be able to load engine specific file formats? This would reduce loading times because the parsing would be fast or not required at all (deserialization).

The assets would be converted to the engine formats using offline tools.

My guess is that most current engine take this approach since game assets are usually bundled together in large files.

Or should there be a way to load "general" file formats at runtime? Is there special cases where it would be helpful?

For example: Loading JSON files is troublesome in terms of memory management because I've no way of knowing how much memory the parser will need because I only know the file size... With an engine format I can preprocess or simply serialize the file.

Any thoughts/ideas?

Thanks.

In my game engine I currently use a singleton called MemoryManager (don't hate me for using singletons the engine only uses two) that allocates a big chunck of memory during engine initialization and then every sub-system "asks" the MemoryManager for a Allocator of some size.

So the big chunk of memory is split across all sub-systems... this prevents memory leaks since there's only a malloc/free pair.

The problem I'm facing is how to determine the amount of memory each sub-system needs because the sub-system have to provide the amount of memory they'll need when creating an Allocator.

I could stop using the allocators the way I do and have them ask the memory manager for more memory every time an object has to be created but that could lead to poor cache usage...

Any thoughts? Thanks.