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.

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.

November 21st, 2013 - Huge Terrain Editing Build

Greetings!  Recently I probably spent the most time I’ve ever spent on this project and it’s really starting to pay dividends now that I’ve had time to focus on it.

I’ve done a huge amount of work on the editor.  It’s possible to create maps from scratch now, plus edit them.  The terrain editing is also getting fairly full-featured, though are still some bugs to work out (as you can see with normals and alpha in the video above)

The editor also requires NO WoW data at all anymore.  

Thanks a lot to everyone who has tested alphas and given me feedback and crash dumps, especially akspa420 and Cromon lately.

Build 19 has been posted to github and includes a shitload of changes and improvements.

November 16th, 2013 - Alive and Well

Hello!  After a couple months of quite a lot of IRL work and some vacation, I’m back and working again on the engine!  Actually, there were only a few weeks where I wasn’t working on it at all.  Just not much flashy to report.

I will still continue to make posts here with significant new progress, but all day-to-day changes and build submissions are now going on at github. Again, email me at relaxok at mmosdk dot com if you would like access.

Build 18 has been committed some minutes ago, further removing more WoW files from being required.  This is the first build that can create completely new maps, but alpha painting still is not enabled and terrain editing is very much WIP.

Though the editor is doing quite well now, a few of you have mentioned being unable to run the client and connect it to the server. This has been tracked down to a UI elements issue.  The client UI is one of the last things that needs to be pried away from WoW data, and on top of that it requires some UI that’s from a more recent mpq of interface data than the 3.x MPQs.  I should fix all that in the next couple days.

Things are actually at quite a good point right now.  A huge amount of really important back-end work is done, and it’s just waiting for some of my patented slam-fest late-nighters to finish off some huge features. Also, thanks to some great beta testers, stability has improved 1000% in the graphical apps.  Won’t be too long now before building worlds is full steam ahead.

I suspect within the next 3 months I will convert my github to an organization and open up installer access to the public.

We make Tumblr themes