October 9th, 2014 - Character Rendering
Just a quick update. I took about 2 months off due to IRL work overload, but I'm back on this project hardcore.
Since I've been working on UI so much (see last post), I realized that in order to do character selection and character info frame etc, I was going to need to finally tackle character rendering.
It may seem weird that I haven't done it yet, but if you'll notice going back through the screenshots the only thing I had done was mob rendering which is quite a bit easier. Mobs just render using skin textures and do not actually equip items.
I now have all characters rendering with all equipment included. This work involved a bunch of new systems:
Compositing textures - This lets you render several chunks of other textures into a single one. For this, I used a deferred device context in D3D11 so that I can queue up commands for the device on a different thread (in this case the loading thread) then execute the command list in the main rendering thread. This is used for non-attachment equipment such as chestpieces, wrists, gloves, etc. by compositing texture sections onto the character model. They are not additional models.
Geoset control - This also pretty much only comes into play in character rendering which is why I never did it before. Certain meshes are enabled or disabled depending on the items equipped.
Attachments - These are items like weapons, helms, shoulders that have actual separate models and rather than being world objects in themselves, are sub-models of the character and attached to a particular bone in the model.
One issue is starting to arise here: over-reliance on particular database structures in order to support all of this. I am implementing sql tables that are mirrors of the record structure of certain Blizzard tables. There's no reason they have to be that way, but it lets me work a bit faster rather than designing new table structures and then converting the old one (e.g. ignoring columns I don't use, etc.) I would like to eventually have a better way to handle with this as my end goal is not to use their structures.
Anyway, on to more UI work including inheriting UI element templates in a much faster way than re-parsing the xml, and also rendering with the correct draw order based on frameStrata, frame level, texture sublevel, etc. So far, I've completely ignored that and it's causing problems.
Another 'too much blizzard' issue is starting to come up in the UI work. A lot of API work needed to be done on the client side, and for ease of use I'm using the same names and order of return values for things like e.g. 'GetCharacterInfo'. Not sure how I want to deal with this in the future.
