Today I just got coronas ported. It was very easy and painless, but I had to step a bit carefully as I wanted to ensure that coronas could share as much code and objects with particles as was possible (with the setup I've got coronas are just a special case of particles).
It's starting to get close to the point where I can remove the D3D9 headers and libs from the project, which is an important milestone. Once I reach that I'll need to take another pass or two over the code, clean out legacy junk, restructure where required, and evaluate the next steps.
There are some important things to consider for moving forward from the simple port.
I don't make much use of D3D11 features. There are geometry shaders for sure, and one or two other things I couldn't have done in D3D9, but there is ample scope for more. I especially want to investigate the possibility of making brush surfaces into fully static data - currently I have a static vertex buffer by a dynamic index buffer. That's the only major chunk of geometry data that remains dynamic in the engine (aside from particles, sprites and other transient objects) and it constitutes such a large part of the draw for each frame that I feel it's worth shooting for.
Another major chunk of dynamic data is lightmaps (will I ever be finished agonizing over these?) What I didn't mention the other day was that an option that's available is to use a compute shader for updating dynamic lightmaps. That is at a very embryonic stage at the moment (I'm aware of the possibility but haven't even begun to work out the details; nor have I even written the "hello world" of compute shaders yet). It's interesting enough though.
More things are beginning to take shape with other parts of the engine too, especially the long-promised sound code work, which I'll talk about later. I also want to talk some about the research I'm doing on interpolation code, and how and why the original QER interpolation tutorials are so badly broken.
Another day.
Thursday, March 1, 2012
Thursday 1st March 2012
Subscribe to:
Post Comments (Atom)
7 comments:
There's definitely some issues with the QER interpolation code. I've based UQE Hexen II's interpolation off that. I've noticed two glaring issues of which I couldn't get a plauseable fix for.
On rotation interpolation I've noticed that at some random time, I get that static items like torches gets odd rotations off their staticly rotated position on the X/YAW axis.
On transform interpolation I've noticed ( quick eyes ) is that as entities gets shown ( positioned ) for the first time, they gets moved to their positions from your position, or at least they pass into your view to their position. I've noticed this again on staticly placed entities, like torches.
I've noticed these on the Hexen II engine, which is why I'm currently tempted not to implement these on UQE Quake.
I'm of the opnion that Quake II's interpolation is the way things should be done. It has both movement and frame interpolation in the same code, and correctly accounts for a lot of the oddities you might observe with QER code (it's obvious that the QER guys didn't really fully understand the situation here).
DarkPlaces 1.05 is a good close second that's easy to port to other engines (it's what I'm currently using). It interpolates movement and rotations on the server and constrains interpolation to the entity types that should be interpolated, meaning that no special-case checking is needed at all.
FitzQuake I'd put in third place as it correctly catches most of the conditions in which something should or should not be interpolated, but it misses static entities going out of the PVS and I can't see how it catches any entity going out of the frustum (I'm assured by the author that such a catch is there and I trust him; I'm just not seeing it).
The real thing with interpolation is that it should only be applied to MOVETYPE_STEP entities, and - this is the really important piece of info - the movement and the frame animation are part of one and the same thing, so they need to be kept in sync.
An entity moves from A to B, it begins a move at the same time as it begins a step animation and should end both at the same time too, using common interpolation points in between. Quake II handles this correctly and as far as I'm aware it's the only one that does.
I'm currently porting that to a test engine but it's early days and I'm not sure how it will work out. I'll let you know.
That makes a lot of sense. I'm looking forward to your results on this!
The Hexen II models are seems to be interpolation friendly, I haven't seen much issues, mostly when I do see something it mostly relates to the first and last frame of animation, which leads me to believe (and I could be wrong) that the first and last frames of a model should not be interpolated, unless the animation loops. This effect that QER also don't cater for is mostly visible when you use the "necromancer" class and use his sickle weapon. Its also very visible when doing weapon switching on this class.
I generally don't interpolate if switching to the first frame of a weapon model, the reason being that you may have been in the middle of a firing animation and if so the interpolation can give weird results.
I'd also not interpolate if switching between animations in any model (i.e. from walk to run to attack and so on) but I haven't found a sane way of identifying this with Quake models. The two ways that do spring to mind are to parse the frame names from the MDL file and figure it out from there, but frames aren't required to have a consistent naming, and to poke into the QC and figure them from that, but that's not multiplayer-friendly (you may not even have a local copy of the QC that is being run by the server).
Another way is to dynamically build it up over time, so if a model cycles through a given set of frames you assume that this set represents an animation sequence and not interpolate if switching to a frame outside of that set. I'm wary of that approach however, something I can't quite put my finger on feels wrong about it.
I agree with you. I also haven't really found a sensible way to manage that which feels right and consistent.
There's a further complication in that entities can be moved by either stepping or by physics. Obviously the MOVETYPE_STEP interpolation should only apply to the portion of the move that is done by stepping, with CL_LerpPoint applying to the physics move. Yuck.
ah, never a dull day with Quake's chaotic codebase. ;)
Post a Comment