• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By evelyn4you
      Hello,
      i try to implement voxel cone tracing in my game engine.
      I have read many publications about this, but some crucial portions are still not clear to me.
      At first step i try to emplement the easiest "poor mans" method
      a.  my test scene "Sponza Atrium" is voxelized completetly in a static voxel grid 128^3 ( structured buffer contains albedo)
      b. i dont care about "conservative rasterization" and dont use any sparse voxel access structure
      c. every voxel does have the same color for every side ( top, bottom, front .. )
      d.  one directional light injects light to the voxels ( another stuctured buffer )
      I will try to say what i think is correct ( please correct me )
      GI lighting a given vertecie  in a ideal method
      A.  we would shoot many ( e.g. 1000 ) rays in the half hemisphere which is oriented according to the normal of that vertecie
      B.  we would take into account every occluder ( which is very much work load) and sample the color from the hit point.
      C. according to the angle between ray and the vertecie normal we would weigth ( cosin ) the color and sum up all samples and devide by the count of rays
      Voxel GI lighting
      In priciple we want to do the same thing with our voxel structure.
      Even if we would know where the correct hit points of the vertecie are we would have the task to calculate the weighted sum of many voxels.
      Saving time for weighted summing up of colors of each voxel
      To save the time for weighted summing up of colors of each voxel we build bricks or clusters.
      Every 8 neigbour voxels make a "cluster voxel" of level 1, ( this is done recursively for many levels ).
      The color of a side of a "cluster voxel" is the average of the colors of the four containing voxels sides with the same orientation.

      After having done this we can sample the far away parts just by sampling the coresponding "cluster voxel with the coresponding level" and get the summed up color.
      Actually this process is done be mip mapping a texture that contains the colors of the voxels which places the color of the neighbouring voxels also near by in the texture.
      Cone tracing, howto ??
      Here my understanding is confus ?? How is the voxel structure efficiently traced.
      I simply cannot understand how the occlusion problem is fastly solved so that we know which single voxel or "cluster voxel" of which level we have to sample.
      Supposed,  i am in a dark room that is filled with many boxes of different kind of sizes an i have a pocket lamp e.g. with a pyramid formed light cone
      - i would see some single voxels near or far
      - i would also see many different kind of boxes "clustered voxels" of different sizes which are partly occluded
      How do i make a weighted sum of this ligting area ??
      e.g. if i want to sample a "clustered voxel level 4" i have to take into account how much per cent of the area of this "clustered voxel" is occluded.
      Please be patient with me, i really try to understand but maybe i need some more explanation than others
      best regards evelyn
       
       
    • By Michael Santer
      Hi!
      We're currently two programmers and a game designer working on a turn-based tactics fantasy board game. For reference you can search for images of "Tactics Arena Online", a fairly dated game that used to have a lot of depth and complexity.
      Our goal is to use the same combat concepts, but giving it a much needed modern touch as well as a whole new set of heroes to choose from with additional abilities. The game is a mix of isometric and 3D and we plan to release the game on Steam and hopefully Android & iOS as well.
      We are looking for someone to work with us pro-bono (just like we're doing) as a 3D character artist. The skills needed are creativity, a hard working attitude and an ability to make minor animations (things like idle, walk, block and very rudimentary attack animations). A perk to have would be the ability to make some VFX. If the game makes it on steam and money starts coming in, you'd obviously be compensated for your hard work, but as it stands this is a hobby project to garnish your portfolio.
      A bit more about the game:
      This game will be an online multiplayer game where each user gets to pick up to 10 characters to place on his half of the board (this would be done before even entering matchmaking. Think runes in League of Legends for example). The user can place his 10 units of choice anywhere he likes on his half board. Some units can be used more than once. So if you want 4 knights and 2 mages or even if you want 10 clerics, you can do as you please. You can then save your setups for future use. The goal of the game is to wipe out the enemy team.
      Each character or Hero (except premium and abyss characters) start with 1 ability and they can ascend (either by playing a certain amount of matches with the character or by forcing the ascension with real money) to gain a new ability or passive. Acquiring a new character can be done by using in-game currency that you earn from playing matches or using real money with the exception of Abyss characters which can only be acquired by winning certain rare matches. The goal is to offer a freemium game with lots of customizable elements while making sure that no user can "buy power" with real money. We want everything that a paying user can get to be available to non-paying users who play the game a lot.
      Ultimately we want this to become a competitive game that people can enjoy and really get invested in. Each character is designed with options for counterplay in mind and synergy with other heroes.
       
      We sincerely believe in what this game can become and we home to find someone just as passionate as we are to get involved in this project!
    • By Marinka Brussel
      Imagine a game where the characters are not defined by body regions, but rather, each body region consists of thousands of components, which would kind of replicate the real world where we consist of molecules, atoms - that would open up many, many new possibilities for creative gameplay. Can this be done on any scale with today's technology, or would the games simply require too powerful of a computer to even be playable? Are there any theoretical limits to this? Thanks
    • By Endemoniada

      Hi guys, when I do picking followed by ray-plane intersection the results are all wrong. I am pretty sure my ray-plane intersection is correct so I'll just show the picking part. Please take a look:
       
      // get projection_matrix DirectX::XMFLOAT4X4 mat; DirectX::XMStoreFloat4x4(&mat, projection_matrix); float2 v; v.x = (((2.0f * (float)mouse_x) / (float)screen_width) - 1.0f) / mat._11; v.y = -(((2.0f * (float)mouse_y) / (float)screen_height) - 1.0f) / mat._22; // get inverse of view_matrix DirectX::XMMATRIX inv_view = DirectX::XMMatrixInverse(nullptr, view_matrix); DirectX::XMStoreFloat4x4(&mat, inv_view); // create ray origin (camera position) float3 ray_origin; ray_origin.x = mat._41; ray_origin.y = mat._42; ray_origin.z = mat._43; // create ray direction float3 ray_dir; ray_dir.x = v.x * mat._11 + v.y * mat._21 + mat._31; ray_dir.y = v.x * mat._12 + v.y * mat._22 + mat._32; ray_dir.z = v.x * mat._13 + v.y * mat._23 + mat._33;  
      That should give me a ray origin and direction in world space but when I do the ray-plane intersection the results are all wrong.
      If I click on the bottom half of the screen ray_dir.z becomes negative (more so as I click lower). I don't understand how that can be, shouldn't it always be pointing down the z-axis ?
      I had this working in the past but I can't find my old code
      Please help. Thank you.
  • Advertisement
  • Advertisement
Sign in to follow this  

DX11 Current Wasteful DirectX Calls - DX11

Recommended Posts

Before you read, apologies for the wall of text!  

I'm looking to leverage efficiencies in DirectX 11 calls, to improve performance and throughput of my game.  I have a number of bad decisions I am going to remedy, but before I do, I am just wanting to get input into I should put effort into doing these.

I've been running for a while with a high frame rate in my game, but as I add assets, its obviously dipping (its a bit of an n squared issue).  I'm fully aware of the current architecture, and I'm looking to take care of some severe vertex buffer thrashing i'm doing at the moment. 

Keep in mind, the game engine has evolved over the past year so some decisions made at that time in hindsight are considered bad, but were logical at the time.

The scenarios:

Current: my game world is broken up by quad tree.  I'm rendering the terrain geometry and water geometry separately and in different vertex buffers.   Currently I am using Raw Draw Calls which means that I am very wasteful on computational power.  

Goal: Use Index buffers to reduce vertices by 80%, compress my index buffers and vertex buffers into one index buffer and vertex buffer.  I can't reduce the number of draw calls as its per leaf.

Current: Static assets such as trees etc are bound to each leaf of my quad tree, as I traverse the tree to see whats in view/out of view, I trim the leaf which in turn trims all the static assets.  This means there is an instance buffer for each node AND for each mesh.  

Goal: Compress the instance Buffers into one instance buffer per mesh (Ie, even if 10 meshes are in 1 vertex buffer, I need 10 instance buffers), for all meshes, compress the meshes into 1 index buffer and 1 vertex buffer.  I can not reduce the number of draw calls.

Current: My unlimited sea function reuses the same tile mesh and just remaps with a constant buffer.  This means, if there are 10 tiles, there are 10 draw calls and 10 constant buffer updates.

Goal: Simple, Use an instance buffer and remove the constant buffer updates (I was lazy and wanted to do this quick :)).  Reduces it to 1 draw call, 1 instance buffer bind and 1 vertex buffer bind.

Current: Each shader, i'm rebinding the same constant buffers, these buffers only change at the start of a new scene (shadow AND rendered).  

Goal: Create a map of buffers to be bound once per context, use consistent registers.   Combine wasteful buffer structures into 1 buffer.  Reduce number of constant changes.  More negligible for deferred contexts but still worth it.

All these changes are not difficult as I have layered my graphics engine in such a way that it doesn't disturb the lower levels.  Ie. Instance management is not bound to mesh directly, mesh management allows for compression easily.    All static buffers are set immutable in my game, so vertex, index and most index buffers are immutable.

So the questions: 

- Are some or all changes worth it?  Or am I going to just suffer from draw calls?  

- I am assuming at the moment that Setting vertex buffers, index buffers, instance buffers are part of the command buffer?  Is this correct, i'm looking to reduce the number of calls pushed through it.

- I assume in a deferred context world, that constant buffers when set are not persistent across contexts when I execute command lists.

- Lastly, should I look into Draw Indexed instanced indirect to accumulate draw calls?  And would I get any benefit from the GPU side doing this?

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

I think, at least for D3D11, the biggest thing you can do is limiting the amount of state changes you make to the pipeline. This is usually accomplished by grouping meshes that have similar pipeline parameters. As for the QuadTree, is there perhaps a priming read you can do of the tree, get the information that you need from each node, and try to dispatch that to the GPU in one go? Obviously this will result in more app side processing of the scene, but you can than profile, and see if the end result is better.

The goal is to keep the GPU busy, sending small piece meal workloads while you continually prepare the next list of commands on the CPU may result in the GPU being under-utilized

The raw draw call in 11 is where a lot of things are resolved. From what I understand most of the deferred context calls are in fact deferred up to this point. So cutting those down will be a huge benefit (and of course other calls to the deferred context).

Edited by markypooch

Share this post


Link to post
Share on other sites

Yeah, I've read the state changes are a killer.  I am using Texture atlases to reduce texture swapping.  

I will probably reduce the number of constant buffer changes to sub 10 over the entire rendering cycle, at the moment its around 30+.

I'm steering clear of deferred contexts at the moment since im using an AMD card, I just test that pipeline for the nvidia users.

The issue I have at the moment is profiling the GPU, the reason.  Im using C# and Sharpdx, and the external GPU tools currently have can't pick up Direct X 11 is running.  I regret in some ways my decision to choose these technologies.  The visual studio tool at the least works, and I need to look more deeply into it.

What I can do, i've broken my game into 2 parts, the game logic component and the rendering component.  What I should do is use the GPU downtime in the logic component to do more prep/rendering, im sure profiling will show this up.  I haven't built a jobs component really, this might be something I need to consider.

Will let you know how the state change reductions go and impact on performance.

 

Edited by ErnieDingo

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement