I can load them, draw them, animate them (although I'm not doing this properly just yet), they can have shadows, they're lit, they're textured. Viewmodel support is there, alpha not yet.
Joint animations are being done on the CPU, vertex animations on the GPU. Joint animations will likely remain on the CPU (at least until I go to D3D11 where multiple constant buffers will enable this to be a candidate for moving).
Vertex animations on the GPU are about twice as fast as on the CPU, and retain full speed even when many models are on-screen at the same time (CPU vertex animations begin to slow down with even 2 models on an i7). Shadows are effectively free (at least I'm not seeing any measurable performance drop from them). The animation code is infinitely cleaner too.
Available constants register space limits an IQM to 80 joints. This will go up to 256 when I move to D3D11. This is a major cause of one source of unhappiness I have with the format - GLSL doesn't expose hardware limits like this but HLSL (and ARB assembly language) most definitely does. Unless you're actually aware that limits such as this do exist, and that they are enforced by the hardware (not the API, the hardware) then you're going to do something like overflow the hardware limit. With HLSL (and ARB assembly) you'll crash, with GLSL you'll just drop back to some kind of software emulation.
Yuck.
Sepaking of "yuck", with DirectQ I'm putting a lot of effort into cleaning out the loading and drawing code, getting rid of the matrix3x4_t stuff and replacing it with D3DXMATRIX. Yes, it's another 4 floats per matrix, but using D3DXMATRIX instead will reduce the lines of code, get rid of some really nasty-looking code, and get me SIMD operations for free.
"Memory wasting"? Hah!
I'm also planning a move to GPU vertex animation for RMQ, which will be very important as the ambitions there are more - errrmmm - ambitious. Of course, that 80 joint limit exists with ARB assembly language (no, moving to GLSL won't help, it still exists with GLSL but GLSL just pretends that it doesn't - hardware limit, remember) so I'll probably have to end up doing some jiggerypokery with the joints to work around it. Oh what a lark!
Tuesday, January 31, 2012
DirectQ IQM Support
Subscribe to:
Post Comments (Atom)
4 comments:
Wow. Capitalized.
Perhaps the most fascinating thing is with you and the Remake Quake guys working together you get tangible real world solutions to real world problems.
Plus the testing and working examples.
Looks like a Sauerbraten ogre (which may not have originated there).
Yep, it's a Sauerbraten Ogre, it was made for it too, though it's open sourced.
Sauer also has a IMQ Octopus-head guy...
you could use that as a Chtulu junior! :P
And now, who offers to recreate all monsters in IQM format?
Or, just for kicks, a player.mdl conversion.
It's just the mrfixit model that comes with the IQM devkit, but that could of course have been sourced from elsewhere - you'll need to check with the IQM guys for that.
Completed move to D3DXMATRIX; it's faster again.
Post a Comment