Real Life caught up with me a bit today so I didn't get to spend much time writing up the next major D3D11 feature I wanted to talk about, which is lightmaps. The executive summary is that I'm maybe 90% certain that at least the first version is going to retain traditional Quake-style lightmapping, rather than doing GPU lightmaps.
I've been experimenting quite some with different ways of handling lightmaps for this engine, and at the moment it's looking as though GPU lightmaps are going to prove unsuitable for use in a general-purpose Quake engine (RMQ has different requirements where the advantages of using them outweigh the disadvantages).
It's probably worth spending some more time talking about this, and the various reasons and thought processes behind it, but that's for another day. Maybe when I begin work on that part of DirectQ's renderer.
Meantime I've been porting the rest of the particle system to the GPU in my experimental engine. I'm going to have an end result that I can pretty much just lift over to DirectQ when done (that's one of the reasons for this; much of the D3D11 renderer already exists and has been well tested).
Roundabout all that's left to do is pointfiles and the colour-mapped explosion. I actually want to change pointfiles to lines rather than particles, as they're quite a bit clearer and easier to see where the trail is actually leading to. I'll probably end up doing some vertex texture fetch for the colour mapped explosion; not totally certain yet so watch this space.
The performance characteristics of this are interesting. Trails turned out to need quite a lot of Draw calls, but what's neat about D3D11 is that Draw calls are incredibly cheap, requiring only 10% of the overhead that D3D9 imposes. At the same time, it's an excuse to experiment some with instancing in order to address this. (Being on a platform where you know that something like instancing is always going to be available and you don't need to worry about writing fallbacks or general case code for downlevel hardware is incredibly liberating.)
All going well the DirectQ 1.9.0 release should happen over the weekend. It was going to be tomorrow but I have a last-minute feature request which I think is worth doing, so I'm holding off on account of this.
Thursday, February 16, 2012
Awesome Particles of Awesomeness
Subscribe to:
Post Comments (Atom)
2 comments:
"...what's neat about D3D11 is that Draw calls are incredibly cheap, requiring only 10% of the overhead that D3D9 imposes"
Impressive. I knew draw call overhead had been reduced since D3D9, but I had no idea it was that significant.
So what's the major bottleneck scenario for the API these days? Improper/inadequate usage of constant buffers? Or is draw call overhead still king?
I got that figure from a MS paper - 1470 cycles with 9 vs 154 cycles with 10 (which I'm assuming 11 is in the same ballpark as). cbuffers and states seem to be the things to watch, in particular a lot of once-per-frame constants which with 9 you'd set as required need to be moved to a single bulk set at the start of the frame.
Post a Comment