• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
360GAMZ

DX11
[DX11] Tile-based Deferred Shading in BF3 discussion

23 posts in this topic

DICE released this presentation that talks about how their renderer uses tile-based deferred shading with DX11:

[url="http://publications.dice.se/attachments/GDC11_DX11inBF3_Public.pptx"]http://publications.dice.se/attachments/GDC11_DX11inBF3_Public.pptx[/url]

The tile-based approach starts on slide 10.

On slide 12 they say they use 1 thread per pixel, and 16x16 thread groups per tile. To process the entire screen, I assume they use the ID3D11DeviceContext::Dispatch() parameters to spawn a bunch of those 16x16 thread groups. For example, for a resolution of 1360x768, they'd call Dispatch( 85, 48, 1 ). Does that sound about right?

On slide 13 they have each thread group determine the min/max depth for its 16x16 pixel screen tile. This is done through groupshared data and interlocked instructions.

Slide 15 describes how they perform culling of the light list vs. the screen aligned bounding box established on slide 13. Instead of each thread in the 16x16 thread group processing a pixel, now each thread processes a light from the incoming light list and, if that light intersects the bounding box, that thread adds the light index to the group shared list of lights. At the end of this phase, each thread group has a list of lights that potentially intersects the pixels in that tile.

Slide 15 handles only point lights. What if we wanted to handle both point and spot lights? Two ideas come to mind. One is to expand struct Light to include additional parameters needed for spot lights. Another is to use two independent structures, one for point and the other for spot. In the first case, we continue to use a single for() loop and conditionally select which intersect test to use based on the light type. In the second case, we use two for() loops, first processing the point lights and then another for() loop to process the spot lights. The second approach feels like it should be more efficient than the first due to coherency between the threads in the thread group.

Slide 16 switches back to processing pixels. Each thread iterates through the list of lights potentially intersecting its bounding box and performs the lighting calculation for its pixel. This all makes sense. Is there further culling that should be performed at this stage? For example, would it be beneficial to test each pixel to determine whether it intersects the spot light cone? Or probably better to simply use a clamp instruction?

One thing not mentioned in the presentation is how they make the initial unculled list of lights available to the Compute Shader, other than that they use a StructuredBuffer for the light data and a Constant Buffer for the # lights. According to NVIDIA, if a Buffer is created as Dynamic, it resides in AGP memory all the time. You can lock it, update selective portions, and unlock it and yet nothing will get uploaded to the graphics card. When the shader reads from the buffer, only the needed data is uploaded at PCI speeds, but the entire buffer is never uploaded to video memory. In contrast, non-dynamic buffers reside in video memory. They can be updated with UpdateSubresource, in which case the data updated is copied to a temporary buffer in system memory and eventually uploaded to video memory before the shader needs it. The first method is slower for the graphics hardware (reading memory over PCI is slower than reading it from video memory), and the second method imposes more overhead on the CPU (from all that copying).

Since the unculled list of lights probably changes every frame, it's unclear which method would be faster. But it's easy to switch between the two methods, so once I get to that point, I'll try them both. My gut feel is that with so many threads accessing the light buffer, it's probably best to go with the UpdateSubresource method and have everything reside in video memory.
2

Share this post


Link to post
Share on other sites
Hey,

If you want to see some actual code of a tile-based deferred renderer: [url="http://software.intel.com/en-us/articles/deferred-rendering-for-current-and-future-rendering-pipelines/"]Deferred rendering for current and future rendering pipelines[/url] by Andrew Lauritzen.

He dispatches as you mention. And he calculates, like dice probably does, a mini frustum for each tile (znear and zfar are the min and max values of the depth buffer of the tile) and culls the point lights via: point light sphere vs frustum. He doesn't do any (per pixel) culling after that.

It only uses point lights. And the way you are mentioning about how to include different type of lights is also the only way I can think of but I'm curious of other reactions.But yeah, I also have that same feeling like "wow, there is a lot of dynamic branching going on".
0

Share this post


Link to post
Share on other sites
To get the light data into a GPU memory resource, you can upload the data into a staging buffer and then copy it to a default usage buffer - there shouldn't be any big issue with having to stream the light data into the buffer from AGP memory.

It does mention in their slides that they support the other light shapes, it just doesn't provide the sample code for it. I don't have a copy of the game, but I assume the shader code exists somewhere in the installation - so you might check that out if you have already purchased it.

One other thing that I would find interesting is to find out if there is any benefit to pre-sorting the lights on the CPU and then passing a semi-sorted listing of lights in the structured buffer. This would probably drastically cut down on the number of lights needed to be processed in each thread group, but at the expense of building the sorted light spatial data structure. However, if the structure is maintained from frame to frame, then it could be an overall win...

I think my engine needs a tile based renderer sample :)
0

Share this post


Link to post
Share on other sites
@Litheon - thanks for the link. This will really help out. In his code, he's using the Map/Unmap method and so his light data stays in host memory. Even so, he's able to render 1024 lights in around 6ms on my 450 GTS.

@Jason Z:
Wouldn't using UpdateSubresource() do the same thing as the staging buffer method, only with less implementation work? UpdateSubresource() copies the data to a temp buffer in host memory and then uploads that data to video memory before the shader executes. So either method performs the data copy / upload steps.

I have the 360 version of BF3. Great game BTW. Very pretty graphics.

Regarding pre-sorting the lights, pre-sort with respect to what? Do you mean pre-cull against the frustum? We're using Umbra 3 in our game and so it would be trivial to have Umbra cull out all non visible lights before I upload them to the card.
0

Share this post


Link to post
Share on other sites
What I mean about the pre-sorting is that the mini-frustums for each tile is known before hand (since it is a function of the camera orientation and position). If the lights are already sorted in some spatial hierarchy, then it should be possible to determine fairly efficiently which lights intersect (or could potentially intersect) each tile. That would effectively reduce the amount of tests that each tile needs to do before the threads are even dispatched. The sorted data could be provided in some data structure (i.e. something in a raw byte address buffer) or perhaps in a number of structured buffers...

About the resource updating, it depends on how the destination buffer is being [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ff476486%28v=vs.85%29.aspx"]used[/url]. If you explicitly copy the data between resources yourself then you have a little more control over how the update occurs. If you can ensure that your staging buffer won't have any contention, then your copy should choose the fastest method available.
0

Share this post


Link to post
Share on other sites
I'm forging ahead on my implementation of tile based CS lighting. One thing I ran into is that since the mini-frustum vs. light culling that the threads do is in view space, my light data (position and direction) needs to be in view space, too. In my game, all lights are stored in world space, so I could simply transform them to view space on the CPU as they're being written to the StructuredBuffer. I'm not too excited about doing this since our games tend to be CPU limited.

One idea that came to mind is that I can upload the light data in world space and have the CS transform them into view space. I'm currently using a StructuredBuffer. Could I change that to a RWStructuredBuffer so the CS can make a pass at the data and transform it in place, writing it back into the same buffer? Would there be any conflict with the game code on the CPU updating the buffer at the same time the CS is writing to it? I'd think not because the CPU would get a fresh buffer when it calls Map().

Since the work of transforming the lights can be distributed across the threads in the CS, there's no chance of conflict where two or more threads are trying to transform the same light.

I'm new to CS programming, so if there's a better way to do this, I'd love to hear about it!
0

Share this post


Link to post
Share on other sites
Another thought is that I could have the CS transform the light from world space to view space just during the mini-frustum phase and then discard the transformed data, and do the lighting computations in world space. This would eliminate the need to store the view space data back to a buffer at all because it won't be needed again (I think).
0

Share this post


Link to post
Share on other sites
Currently I store the worldLightPos and viewLightPos matrixes in 1 RWStructuredbuffer, and I transform them from world to view with a ComputeShader to the same RWStructuredBuffer. But I haven't measured the performance.

I don't think you will have conflicts with a Map/Unmap, but maybe the staging buffer is a good way to go. Then you have more control of what is allocated in the memory.


Please keep posting your results, it is an interesting read! 
1

Share this post


Link to post
Share on other sites
[quote name='360GAMZ' timestamp='1324090742' post='4894682']
I'm forging ahead on my implementation of tile based CS lighting. One thing I ran into is that since the mini-frustum vs. light culling that the threads do is in view space, my light data (position and direction) needs to be in view space, too. In my game, all lights are stored in world space, so I could simply transform them to view space on the CPU as they're being written to the StructuredBuffer. I'm not too excited about doing this since our games tend to be CPU limited.
[/quote]
Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?
0

Share this post


Link to post
Share on other sites
I captured a quick video of my progress and put it up on YouTube. It's a cube being lit by 6,000 tiny moving point lights. It runs at 60 FPS on a GeForce 460 GTX. Sorry for the bad quality - I'll upload something better in the future. More info is in the description of the video.

[url="http://www.youtube.com/watch?v=x84Yf2-kw7w&feature=youtu.be"]http://www.youtube.com/watch?v=x84Yf2-kw7w&feature=youtu.be[/url]

Next step is implementing projected spot lights. But I won't be able to start that for another week.
1

Share this post


Link to post
Share on other sites
[quote name='Litheon' timestamp='[url="tel:1324119934"]1324119934[/url]' post='[url="tel:4894742"]4894742[/url]']
Currently I store the worldLightPos and viewLightPos matrixes in 1 RWStructuredbuffer, and I transform them from world to view with a ComputeShader to the same RWStructuredBuffer. But I haven't measured the performance.

I don't think you will have conflicts with a Map/Unmap, but maybe the staging buffer is a good way to go. Then you have more control of what is allocated in the memory.


Please keep posting your results, it is an interesting read!
[/quote]

That's a really interesting idea. So you're saying that your light buffer has space for both the world and view positions, but the view position is placeholder until the shader writes the transformed data to it?
0

Share this post


Link to post
Share on other sites
[quote name='Jason Z' timestamp='[url="tel:1324146611"]1324146611[/url]' post='[url="tel:4894834"]4894834[/url]']
[quote name='360GAMZ' timestamp='[url="tel:1324090742"]1324090742[/url]' post='[url="tel:4894682"]4894682[/url]']
I'm forging ahead on my implementation of tile based CS lighting. One thing I ran into is that since the mini-frustum vs. light culling that the threads do is in view space, my light data (position and direction) needs to be in view space, too. In my game, all lights are stored in world space, so I could simply transform them to view space on the CPU as they're being written to the StructuredBuffer. I'm not too excited about doing this since our games tend to be CPU limited.
[/quote]
Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?
[/quote]

I think that should definitely work. Though, it would require 6 transformations instead of the 2 I'm currently doing: light to view space for culling and pixel position to world space for the lighting calc. Alternatively, I could do the lighting calc in view space, but I would have to transform the light to view space a 2nd time, so it's a wash. Unless I stored the transformed light for reuse in the lighting calc, but I believe 3 dot products is faster than a resource store + load.
0

Share this post


Link to post
Share on other sites
[quote name='360GAMZ' timestamp='1324455053' post='4896082']
[quote name='Jason Z' timestamp='1324146611' post='4894834']
[quote name='360GAMZ' timestamp='1324090742' post='4894682']
I'm forging ahead on my implementation of tile based CS lighting. One thing I ran into is that since the mini-frustum vs. light culling that the threads do is in view space, my light data (position and direction) needs to be in view space, too. In my game, all lights are stored in world space, so I could simply transform them to view space on the CPU as they're being written to the StructuredBuffer. I'm not too excited about doing this since our games tend to be CPU limited.
[/quote]
Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?
[/quote]

I think that should definitely work. Though, it would require 6 transformations instead of the 2 I'm currently doing: light to view space for culling and pixel position to world space for the lighting calc. Alternatively, I could do the lighting calc in view space, but I would have to transform the light to view space a 2nd time, so it's a wash. Unless I stored the transformed light for reuse in the lighting calc, but I believe 3 dot products is faster than a resource store + load.
[/quote]
Maybe I am not really understanding (sorry for beating a dead horse...) but if all of these are on your CPU side:

[list=1][*]Light data is in world space[*]Frustum data is in view space[*]Pixel position (in view space?)[*]Lighting is carried out in view space[/list]


If all of that is true, then you should be able to convert the frustums to world space, reconstruct the world space pixel position instead of view position, and then carry out the lighting in world space. That would reduce the overall work needed on the GPU, while minimizing the work needed on the CPU (frustum data must be done on CPU). Am I seeing this correctly?


0

Share this post


Link to post
Share on other sites
Very interesting topic!

I am working on a deferred pipeline for PC. Since tile based technique has been implemented on X360, can anyone say me the advantages and disvantages of tile based over quad based deferred in DirecX 10??

Thank so much!
0

Share this post


Link to post
Share on other sites
Ardilla, not sure about consoles, but on PC tile based has been superior from what I've experienced. Andrew Lauritzen has a paper and full demo with source code that allows you to play around with various methods including tile based vs. quad based:

[url="http://visual-computing.intel-research.net/art/publications/deferred_rendering/"]http://visual-computing.intel-research.net/art/publications/deferred_rendering/[/url]
1

Share this post


Link to post
Share on other sites
Well you still get the main benefit, which is that you can batch multiple lights while shading each pixel which saves you bandwidth (both from sampling the G-Buffer, and blending the lighting result). What you lose out on by using a pixel shader is shared memory, which prevents you from doing the per-tile culling directly in the shader in the manner used by Frostbite 2 and Andrew Lauritzen's demo. So you either have to find some other way to do the tile->light association on the GPU, or you have to do it on the CPU.
1

Share this post


Link to post
Share on other sites
mmm, interesting, Im going to implement a light volume technique in a first moment (I understand it better), and then I will try to implement the tile-based to see the performance difference [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] .

Thanks for the answers!
0

Share this post


Link to post
Share on other sites
I've run into a problem trying to render translucent objects into the scene after the deferred rendering has finished with the opaque objects.

Since a picture is worth a thousand words, here's my current DX11 rendering pipeline:

[sharedmedia=gallery:images:1545]

Since the translucent objects need to sort against the opaque scene, I want to reuse the depth buffer created during the deferred pass. However, the depth buffer is MSAA while the final render target is non-MSAA and so they can't be used together.

Here's one possible solution:

[sharedmedia=gallery:images:1544]

Here, the Lauritzen resolve shader is replaced with a shader that converts the flat StructuredBuffer into an MSAA render target (compute shaders cannot write to MSAA buffers, which is why Lauritzen uses a flat StructuredBuffer that holds all MSAA samples of the image). Since the lit render target is now MSAA, it can be used in conjunction with the MSAA depth buffer to render translucent objects. Finally, the ID3D11DeviceContext::ResolveSubresource() method is used to resolve the MSAA buffer to a non-MSAA buffer such as the back buffer.

Before I undertake this approach, I thought it would be a good idea to get feedback from the gurus here on this approach vs. any others that may come up. Here are a few questions:

1) Is it possible to wite such a shader to convert the flat buffer to a hardware compliant MSAA render target (meaning something the hardware can resolve to a non-MSAA buffer)? I'm not so sure this is possible since the flat buffer contains only the sample colors and no coverage mask.

2) If this method isn't possible, what are my alternatives? Can a depth buffer be resolved with ID3D11DeviceContext::ResolveSubresource()? If so, then Method 1 becomes much easier. [EDIT]: I've confirmed that a MSAA depth buffer cannot be resolved to non-MSAA.
0

Share this post


Link to post
Share on other sites
The main problem with compositing is that you can't support arbitrary blending modes for your transparents. You can implement alpha blending and additive blending this way, but you couldn't also use other blending modes like multiply or screen. You can't automatically resolve a depth buffer, but you can do it manually with a pixel shader. Just sampling the first subsample and outputting it to SV_Depth should work well enough. Obviously you don't get MSAA with your transparents if you go this route.

To answer your first question, you can definitely write a pixel shader to convert from a structured buffer to an MSAA render target. To do it properly you'll need to run the pixel shader at per-sample frequency, which is done by taking SV_SampleIndex as an input to your shader. You can then use the pixel position + sample index to sample the proper value from the structured buffer, and then you just output it and it will get written to the appropriate subsample of the output texel. As far as D3D11 is concerned render targets only contain color data, not coverage. So you don't need to worry about that. There are exotic MSAA modes that decouple coverage and color (like Nvidia's CSAA), but you don't have direct access to that in D3D11 so you have to do it the standard way. As long as you still have your MSAA depth buffer, the transparent geometry will get rasterized and depth tested correctly.
1

Share this post


Link to post
Share on other sites
Thanks for the incredibly helpful reply, MJP!

[quote]
...but you couldn't also use other blending modes like multiply or screen.
[/quote]

It's not clear to me why rendering translucent geo into a render target with the blend mode set to multiply wouldn't work.

[quote]Just sampling the first subsample and outputting it to SV_Depth should work well enough. Obviously you don't get MSAA with your transparents if you go this route.[/quote]

So I bind the depth buffer as a SRV and run the pixel shader at per-pixel frequency by not specifying SV_SampleIndex as an input to the shader? Then, just simply read the depth texture and write it out to SV_Depth?

It sounds like this method (depth buffer resolve shader) is a better choice for our application. We draw a lot of translucent particles like smoke and so rendering that into a non-MSAA buffer sounds like less bandwidth. And since the particles tend to have smooth texture edges, MSAA probably wouldn't benefit us much.
0

Share this post


Link to post
Share on other sites
[quote name='360GAMZ' timestamp='1325717841' post='4899744']
It's not clear to me why rendering translucent geo into a render target with the blend mode set to multiply wouldn't work.
[/quote]

I'm sorry, I misunderstood your approach. Never mind that part about the blending modes. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

[quote name='360GAMZ' timestamp='1325717841' post='4899744']

So I bind the depth buffer as a SRV and run the pixel shader at per-pixel frequency by not specifying SV_SampleIndex as an input to the shader? Then, just simply read the depth texture and write it out to SV_Depth?

It sounds like this method (depth buffer resolve shader) is a better choice for our application. We draw a lot of translucent particles like smoke and so rendering that into a non-MSAA buffer sounds like less bandwidth. And since the particles tend to have smooth texture edges, MSAA probably wouldn't benefit us much.
[/quote]

Yup. In our engine at work we actually take this concept a step further and downsample the depth buffer to half-sized, so that we can render expensive things (volumetrics, really dense smoke, etc.) to a half-sized render target and save performance.
2

Share this post


Link to post
Share on other sites
Hi,

Just thought I'd point you towards a paper about tiled shading, and associated OpenGL demo, by, *ahem*, myself. The paper is sadly paywalled by JGT, but I've put up a preprint, which is not hugely different from the published paper (it contains some bonus listings that were removed dues to space restrictions), on my web site. You may be able to access the published paper from a uni library or similar.

[url="http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading"]http://www.cse.chalm...d=tiled_shading[/url]

The main takeaway is a much more thorough performance evaluation and analysis, the introduction of tiled forward shading (which enables easy handling of transparent geometry).

In relation to the discussion here. I go a different way to the others and do the tile intersection by first transforming the lights to screen space, and then testing the screen space extents against each tile. On the CPU I do it scan line fashion, which is as efficient as it gets, but somewhat hard to do in parallel. Therefore the GPU version does a brute force tiles-test-all-lights approach, much like others have done, but with a much cheaper aabb/aabb test (2D extents + depth range). This saves constructing/testing identical planes all over the place.

The demo only implements the CPU variety, and without depth range (though I may update that).

Hope you find this useful.

Cheers
.ola
0

Share this post


Link to post
Share on other sites
[quote name='Ardilla' timestamp='1325595042' post='4899225']I am working on a deferred pipeline for PC. Since tile based technique has been implemented on X360, can anyone say me the advantages and disvantages of tile based over quad based deferred in DirecX 10??[/quote]I haven't used it to optimise my deferred shading yet ([i]I'm planning on it and have high hopes[/i]), but applying the same tile-based optimisations to shadow-filtering, DOF, SSAO and FXAA has been a huge win for me on DX9-PC and the 360/PS3.
0

Share this post


Link to post
Share on other sites
[quote name='Ardilla' timestamp='1325668370' post='4899522']
mmm, interesting, Im going to implement a light volume technique in a first moment (I understand it better), and then I will try to implement the tile-based to see the performance difference [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] .

Thanks for the answers!
[/quote]

So, to underline the main difference: Traditional deferred shaing is typically memory bound, whereas tiled deferred shading completely eliminates this bottleneck and is squarely compute bound. Given this, you can get an idea of how much better it will perform on your platform, either by looking at performance numbers, or by simple experimetation (e.g. vary G+Buffer bit depth). Both xbox 360 and PS3 have a very high compute to bandwidth ratio, and this is true for modern GPUs as well, and increasingly so.

As I found in my experiments, going between GTX 280 and GTX 480, shading performance doubles for tiled deferred, whereas my implementation of traditional deferred shading scales by the expected 30%, corresponding to the increase in memory bandwidth.

Anyway, of course, if you have massively complex shaders you may not be memory bandwidth bound (yet) but its a pretty safe bet you will be sooner or later as memory bandwidth fall further and further behind. If rumours about GTX 680 are to be believed we'll see this gap widen significantly again in this new generation.

Cheers
.ola
0

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  
Followers 0

  • Similar Content

    • By bowerbirdcn
      hi, guys, how to understand the math used in CDXUTDirectionWidget ::UpdateLightDir 
      the  following code snippet is taken from MS DXTU source code
       
        D3DXMATRIX mInvView;
          D3DXMatrixInverse( &mInvView, NULL, &m_mView );
          mInvView._41 = mInvView._42 = mInvView._43 = 0;
          D3DXMATRIX mLastRotInv;
          D3DXMatrixInverse( &mLastRotInv, NULL, &m_mRotSnapshot );
          D3DXMATRIX mRot = *m_ArcBall.GetRotationMatrix();
          m_mRotSnapshot = mRot;
          // Accumulate the delta of the arcball's rotation in view space.
          // Note that per-frame delta rotations could be problematic over long periods of time.
          m_mRot *= m_mView * mLastRotInv * mRot * mInvView;
          // Since we're accumulating delta rotations, we need to orthonormalize 
          // the matrix to prevent eventual matrix skew
          D3DXVECTOR3* pXBasis = ( D3DXVECTOR3* )&m_mRot._11;
          D3DXVECTOR3* pYBasis = ( D3DXVECTOR3* )&m_mRot._21;
          D3DXVECTOR3* pZBasis = ( D3DXVECTOR3* )&m_mRot._31;
          D3DXVec3Normalize( pXBasis, pXBasis );
          D3DXVec3Cross( pYBasis, pZBasis, pXBasis );
          D3DXVec3Normalize( pYBasis, pYBasis );
          D3DXVec3Cross( pZBasis, pXBasis, pYBasis );
       
       
      https://github.com/Microsoft/DXUT/blob/master/Optional/DXUTcamera.cpp
    • By YixunLiu
      Hi,
      I have a surface mesh and I want to use a cone to cut a hole on the surface mesh.
      Anybody know a fast method to calculate the intersected boundary of these two geometries?
       
      Thanks.
       
      YL
       
    • By hiya83
      Hi, I tried searching for this but either I failed or couldn't find anything. I know there's D11/D12 interop and there are extensions for GL/D11 (though not very efficient). I was wondering if there's any Vulkan/D11 or Vulkan/D12 interop?
      Thanks!
    • By lonewolff
      Hi Guys,
      I am just wondering if it is possible to acquire the address of the backbuffer if an API (based on DX11) only exposes the 'device' and 'context' pointers?
      Any advice would be greatly appreciated
    • By MarcusAseth
      bool InitDirect3D::Init() { if (!D3DApp::Init()) { return false; } //Additional Initialization //Disable Alt+Enter Fullscreen Toggle shortkey IDXGIFactory* factory; CreateDXGIFactory(__uuidof(IDXGIFactory), reinterpret_cast<void**>(&factory)); factory->MakeWindowAssociation(mhWindow, DXGI_MWA_NO_WINDOW_CHANGES); factory->Release(); return true; }  
      As stated on the title and displayed on the code above, regardless of it Alt+Enter still takes effect...
      I recall something from the book during the swapChain creation, where in order to create it one has to use the same factory used to create the ID3D11Device, therefore I tested and indeed using that same factory indeed it work.
      How is that one particular factory related to my window and how come the MakeWindowAssociation won't take effect with a newly created factory?
      Also what's even the point of being able to create this Factories if they won't work,?(except from that one associated with the ID3D11Device) 
  • Popular Now