Now Playing Tracks

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:

  1. 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.
  2. 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.
  3. 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.

UI - July 7th, 2014

Hi all.  Lest you think I am doing nothing, or even perhaps just slacking off — nothing could be further from the truth.  In fact, I’m probably working more now on the project now than ever before.  I’ve just had the current build tied up in such a way that it doesn’t make sense yet to make a new release.

Anyway, the UI code for my engine was one of the things done a very long time ago.  It was okay in that it ‘worked’, but there was absolutely no way to write UI other than with code and custom sub-classing for any type of frame you wanted to create.  What I really needed to do was support something like the xml/lua framework that WoW has.

I started out thinking that perhaps I’d look into some newer technologies, treating the UI more like a browser - some people recommended just doing it with some sort of embedded chromium overlay or at least using html5/css in some way.  

Since I have no background at all in web stuff, I figured hey, I just want to keep my base class the same and make the rest scriptable.  I have WoW’s UI xml and lua, I’ll just support that general idea - I’ll use one of their frames as an example and build on it over time.  How hard could it be?

Well, extremely hard.  But 2 months, endless headaches, and thousands and thousands and thousands of lines of code later, I have almost the entire XML/LUA framework of WoW working in the client.  Essentially, you will be able to build a UI for MMOSDK exactly as you would for a game like WoW.  There’s frame types that are pre-defined with some special properties like edit boxes, buttons and the like - on top of an API that accesses stuff in the game state.  

Anyway, my goal is that my next release of the engine has this UI system enabled.  I’m really proud of the work that’s been done on it and I hope that it’s an indicator of my dedication to making an actual usable engine when all is said and done.

(the screenshot above is from the working glue UI - yes you can login and select characters and etc from it)

February 11th, 2014 - Optimization

The ability to cleanly profile things and learning more about the intricacies of D3D11 has enabled me to vastly, vastly increase rendering performance.  How much faster?  Well, about 500%.  Now it’s not uncommon to have typical viewport scenes running at 1000-1100+ fps.

Some of the optimizations:

— Switching from raw RGBA textures to BC3_UNORM compressed textures

— Moving away from a single vertex format.  Every model type now has a vertex format only exactly the size that it needs.  Distant terrain for example is now position only.  Vertex buffers have lost a ton of weight because of this.

— Speeding up quadtree culling immensely by marking a leaf calculated so it never gets recalcuated that frame, pre-calculating 4 map-tile sub-quadrants, and also making sure water rendering uses the same quadrant marking that terrain did rather than recalculating it.

— Water was being drawn twice, simple bug

— Portals were not properly marking attached-models in order to avoid rendering them, only the geometry. Portals are still IP and they’re off by default right now, but this is a huge boost.

— Running over shaders with a fine toothed comb and noticing years-old inefficiencies.  For example the terrain/decal/largeterrain shaders were doing world matrix calculations despite the fact that the vertices are already in world space.

— Not multiplying vertex positions through bone matrices with 0 bone weights.

— Being incredibly anal going through the rendering loop to find areas not passing by reference.

— Trying to get rid of all string-related work in the loop

— Changing from the decade-old zthreads to the C++11 thread classes, which alone yielded performance improvements.

The interesting thing is that there is still a lot more optimization to be done, like packing row major matrices for the shaders so I don’t need to transpose matrices in code anymore, improving portals, etc.

The part I enjoy most about working on this project is that there’s always things to do, and new ideas come to me all the time.

January 15th, 2014 - Build 23, tons of editor work

Well, although the terrain editing shown in the previous video was a good start.. the basics of world editing are now almost completely done.  Just need a few bug fixes and to finish up water drawing.  Extrusion (without normal bugs), vertex painting, alpha painting, texture picking/adding/replacement, and hole drawing are all complete.    I also finished object adding/adjustment for the most part.   

Sorry for the bad quality video and a few bugs in the testing, but just wanted to show the features in action and get it in under the video size limit.

Build 23 has been pushed to the github repo - once again, let me know if you’d like access.   The more testers the better.

January 6th, 2014 - Back in action and a new build pushed

Sorry - I was on vacation/etc mostly for about a month but I’ve pushed a new build that allows significant customization of the map system.   Before it was hardcoded to WoW values.  I added this system when I was working on converting Wildstar formats (in-progress), but realized it was going to be required at some point to give people the ability to do crazy things - like use 1024x1024 terrain textures and increase/decrease terrain resolution after already working with a unit scale for awhile,

I mostly fixed normal re-calculation after terrain extrusion.  The major thing to add in build 23 (in progress) is going to be some sort of GUI for terrain picking when alpha painting.  There’s a way to do it now but without seeing the texture you’re going to use, it seemed a bit pointless to describe the method.

We make Tumblr themes