Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Nov 2008
Offline Last Active Today, 06:11 AM

Posts I've Made

In Topic: D3D12 Best Practices

02 October 2015 - 07:52 AM

Thought I shouldn't start a new topic as it is kind of generic DX12 question: if I put my CBV in the root signature, does the driver version the data automatically, i.e. I wouldn't need a per-frame constant buffer resource?




You will still need a per frame constant buffer resource. You just won't need a per frame entry in a descriptor table for that CBV.


The only way to not need a constant buffer resources is to store constants directly inside the root signature, but you have very limited root signature memory, so you won't be able to store everything in the root signature.

In Topic: DirectCompute - set numthreads from application code (or read from shader).

23 September 2015 - 02:46 AM

You can use ID3D11ShaderReflection::GetThreadGroupSize to get the thread group size of a compute shader in C++.


I do it in my engine right after creating the compute shader and store the thread group size together with the compute shader pointer in a struct, so I always have access to the info when I want the use the shader. 

In Topic: Cheap but realistic lighting engine: Is it a good idea?

18 July 2015 - 08:14 AM

You haven't described anything new wink.png but if you came up with that on your own, great!


Many engines and games use lightmaps, just google a bit.


You also, basically, described reflective shadow maps (also here).


So yes, it will work but you will have to deal with the limitations. Eg: How will you handle reflections?

In Topic: Uses for unordered access views?

05 July 2015 - 04:31 AM

There are many possible uses:


1 - Update particle systems on the GPU. Read from previous frame state (ConsumeBuffer), run simulation for the particle and append to the current frame (AppendBuffer). Draw using draw indirect. You can also do this in the geometry shaders (try both and see which is faster)

     This also works for other types of geometry like vegetation, water simulation, finding pixels that need bokeh, cloth simulations etc.


2 - Calculate per tile light lists (forward+ rendering) or tiled deferred lighting (tile culling and lighting runs on compute shaders). The results are stored in UAV that are then read as SRVs.


3 - Some full screen effects might benefit from compute shaders groupshared memory, so you'll use UAVs.


4 - and many more, just google a bit.


Check out this GDC presentation.

In Topic: Dealing with different collision responses in an entity-component system

25 June 2015 - 03:46 PM

This is how I would do it:
The CollisionComponent should only contain data related to the physics system (is this a rigid body, a trigger region?, friction, restitution, etc)
PhysicSystem: does all physics related math and outputs a list of collisions that occurred.

struct Collision
    handle object_a;
    handle object_b;
    //.... other collision info

CollisionHandlerSystem (this is a high level game specific system):
Takes the list of collisions (from above) as input and does the necessary processing depending on the types of objects involved in the collisions.
This is where you would handle the logic you mentioned. This system could generate a list of messages that could be consumed by other systems, like "destroy entity X", "damage entity Y", etc (good for multi threading) or talk directly with other systems (careful with race conditions).
You could also create another component (CollisionCallbackComponent) and system (or the CollisionHandlerSystem could do it) to call entity specific collision callbacks.
This way you could efficiently handle global game logic, and still provide support of custom callbacks.