MMOSDK

April 12th, 2013 - Editor In Full Swing Exciting times for me....

Fri, 12 Apr 2013 01:37:00 -0700

April 12th, 2013 - Editor In Full Swing

Exciting times for me. I’ve separated all the parts of my project into about 12-13 different libraries and am in the process of going crazy with perfecting the encapsulation so that there’s no bizarre entanglements going on anymore.

Because of all the work I’ve done on this, it now means I can work much faster on the editor since it integrates all the world rendering from the client now. I’m already moving stuff around, but soon I’ll work on painting alphas and extruding terrain.

Preparations for Portability/Release(?) - April 10th, 2013

Wed, 10 Apr 2013 17:58:00 -0700

At some point during the past month, I tried to bring my complete project to work to see how it would fare in a different environment. I had been very sloppy with my encapsulation and dependencies and hard-coding a lot of things. It was a nightmare and took me about 2 hours to do enough local hacks to get even one area (the viewer app) working.

This was a wake-up call: If I was ever going to release the project, I would need to get it into a releasable state. So the past few days I spent a ton of time removing the hard-coded things and making the project build cleanly. My current choice is to put all dependencies in the source tree and have people build them from the solution rather than requiring anything to be installed by a user/designer beforehand. The only requirement at the moment for your environment is to have an environment variable defined for the root of the tree - this is used by the apps themselves and by some helpers.

I am trying to determine how I will end up releasing my ongoing work here. One possibility is to just release ALL source for everything. This is the most flexible for people to do what they want to do, however I have nightmares of random people making forks and starting their ‘own’ version. Another is to release the libraries as libraries/headers, and then the source for the server and client only. This is relatively little code and most would be custom per project anyway.

Whichever way I go, I will want some interested parties to help beta (more like alpha) test the progress. I will not be wanting other contributors to the code-base, but will welcome ideas/suggestions from the community.

If you’re interested in being a sort of alpha-tester, please let me know via http://modcraft.superparanoid.de/ - send me a private message (I’m relaxok on there).

Note - I am likely to rename the project soon. I’d like to give it a snappy name, but may settle for something completely generic, like MMOSDK. We shall see.

In other news - I have done a lot more culling portal-wise and am now 90% done with portal support. More soon!

March 14th, 2013 - Instancing is a go Well, I’ve finally...

Thu, 14 Mar 2013 04:27:00 -0700

March 14th, 2013 - Instancing is a go

Well, I’ve finally implemented instancing. In D3D11 the best way to do it is to create a structured buffer that’s approximately the size of the most instances of a single model you’ll be creating in a scene. Then you use SV_InstanceID in your vertex shader to index into the buffer and grab the world matrix from it. That number is auto-incremented when you call DrawIndexedInstanced with a certain number of instances.

I take the sorted opaque and transparent object lists that I would’ve rendered one by one in their entirety before, and pass them to a new function. That function retains a list of models that have been drawn already this frame, and ignores ones that have already been drawn when iterating through. For each new model that hasn’t been drawn, it uses the first appearance of that model to fill in element 0 in the structured buffer. For the other times that model appears in the list, instead of rendering it, it just continues to fill the structured buffer with locations. Then the original first appearance is drawn, but instead of 1 instance you draw the number of appearances of that object in the list.

You can see how much API usage it saves you in the above screenshot. That’s a lot of stuff to not have to manually draw. This offloads quite a bit of CPU, especially if you have a long draw distance. I had scenes go from 45 to 90 fps just by enabling instancing.

Right now, there are some issues. Models with transparency aren’t great for instancing because of depth ordering issues. Supposedly there are ways to solve all that, but all the conventional wisdom is so far not working. It’s a bit subtle but you can see different meshes drawing in different orders when you’re walking around. That can be fixed by only instancing opaques, but you lose a lot of savings that way. So it’s still a work-in-progress. Instancing also somewhat broke my nice clean fade-ins/fade-outs when objects go in and out of the far clip plane.

February 24, 2013 - Portal Rendering (I’m Back!) Yes, I...

Sun, 24 Feb 2013 23:15:00 -0800

February 24, 2013 - Portal Rendering (I’m Back!)

Yes, I have returned. Real life intervened for quite awhile, but I’m working on the game engine once again.

I’ve accomplished two major things the past few days:

1) I completed the terrain rendering optimization mentioned in the last post. I now use a simple box filter to create my own mipmaps so that I can manually create the data required for a Texture2DArray resource. This let me completely get rid of all the ugly branching my pixel shader was doing in order to address different textures. Speed is very fast now. The next optimization is to have lower rez skin versions for further-away tiles.

2) Portals! Yes I have finally started to implement them. You can see in the above video the portal rectangles in white, and in wireframe mode you can see how internal objects disappear when the angle of view does not allow the camera eye ray to intersect the portal from the proper direction (using dot product of the difference between the eye origin and centerpoint of the portal face, and the portal’s normal.) This vastly improves rendering speeds anywhere there are buildings and such. Towns and cities are much speedier now. The next step is fully implementing the portal chain, which makes dungeons quite speedy as well. I’m only using portal 0 for now since in most buildings that’s the front door.

In some other areas:

- I’ve laid the groundwork for the world builder tool by implementing picking of all world objects (things that will be placed/rotated/etc in an editor). Picking is actually trickier than I anticipated once you want to do something beyond bounding boxes. Ideally I will have to get bsp leaf ray intersection done, otherwise picking objects that are close together gets quite difficult.

- I started supporting String CRCs so that costly things like string comparisons of full resource path names can be very fast. This is in progress.

Major Optimization Fun

Tue, 02 Oct 2012 01:09:00 -0700

October 2nd, 2012 - A few weeks ago I became quite disappointed when comparing my rendering speed to that of the real WoW client which is one of the most high-performing game clients in recent history.

I’ve made a ton of changes, using new profiling tools like Intel’s VTune, and the newest NSight for Visual Studio.

Some of the optimizations in recent weeks are below. A few were silly and obvious, but some were only found when really drilling down.

— Completely re-tool cbuffer usage into frame specific, object specific, and mesh specific structures. This especially helps reduce lighting related Maps/Unmaps into the shader. I reduced Map/Unmap copies by about 75%.

— Stop using string (shader name)->pointer maps for shader-specific d3d11 buffers and such. I converted my whole ShaderSet system to be enum based arrays.

— Don’t use sqrt in pythagorean distance calculations unless you actually need to present the actual value. Comparisions don’t need them. This brought the render lists object sorting (see below) from about 5% of the rendering thread’s CPU time to 0.5%. Surprise kids: sqrt isn’t fast.

— Toy with shader compile options for speed.

— Locally cache a bunch of variables that were accessed by accessor a lot and not optimized out in compilation.

— Separate opaque and transparent render lists, resulting in far fewer blend state changes (also in preparation for instancing of opaques)

— Sort opaque list front to back and transparent list back to front. The former takes advantage of early-z culling in the pipeline which is always recommended and I never did it because of worries about my transparent objects.

— Don’t bother clearing stencil buffer - not using it.

— Calculate world-light lighting values once every second or so instead of every frame. That was definitely overkill.

— Turn some copy-constructor-calling assigns into references to avoid lots of copying (specifically transparency timelines and the hefty bone timelines)

— Get rid of my ‘extra stuff’ Map/Unmap buffer and move the stuff into one of the other buffers. Still not sure why I didn’t do this before.

— Only calculate bounding box corners once for passive (stationary) objects. Massive speedup. Bounding box calculation was 9% of the rendering thread’s CPU time before, now negligible. Just a terrible oversight on my part before.

— Draw terrain early in the frame so it can be worked on while doing all the object-specific culling and such on the CPU side. This is a technique mentioned in several of the more hardcore optimization sites (like Matt Fisher who wrote GPUView while interning(!) at Microsoft).

— Start reducing branching in my terrain’s pixel shader. This will be one of the biggest speedups of all (going from about 60 fps in an average scene to 100+) if my tests so far prove correct. I have quite a ways to go though. Unfortunately, accessing texture arrays by index in pixel shaders can’t be done with variables, only integrals. In order to get by this and do true texture array accessing (sampling via x,y,z rather than just trying to access textures[n]) I will no longer be able to use D3DX11 SRV loading from graphic files and will have to roll my own texture creation and mipmapping. To get started with this I’m beginning to use stb_image, if you’ve heard of that. Nice for lightweight no frills loading of png files (for example) into RGBA raw memory which is nice pointing D3D to.

What’s the result of all this? Well, I don’t have a good test framework and scene set up for exact testing numbers of such things. But all told, I think frame rates are up anywhere from 50-80% compared to before the optimizations.

More updates soon.

September 5th, 2012 - BSP Tree Well, I finally bit the bullet...

Wed, 05 Sep 2012 22:56:00 -0700

September 5th, 2012 - BSP Tree

Well, I finally bit the bullet and incorporated the BSP Tree data from WMO models. So my format now has support for a bsp tree. This is pretty much needed for collision detection that has decent performance. I’m not totally clear on how it works mathematically yet, but above you can see me drawing theramore isle, drawing collision vertices only. Each BSP Leaf mesh is a random color so you can see how granular the bsp structure is. It goes way way beyond the meshes the models normally use.

The next step is to raycast with the planes and leaf polys, from a point on the character bounding boxes to test collision. I have not done this before, but I think it’s going to be quite a math lesson.

September 3rd, 2012 - Baked Shadows v2.0 If you’ll recall...

Mon, 03 Sep 2012 14:45:19 -0700

September 3rd, 2012 - Baked Shadows v2.0

If you’ll recall months ago I had baked shadows in terrain working, however it was quite ugly - blocky and such. There is actually more data there than first thought. The iffy documentation on the ADT format makes it seem like there’s only ‘on and off’ in the shadow data, so I assumed better looking shadows were created by multisampling textures. However, there is more data than that. Here I am basically shading the data range from 0.8 to 1.0 (as a multiplier). There is some hint that a different ‘shadow color’ from a light database may be used but I think it looks fine as is. Note the smoothness compared to the old method.

Someday, I will incorporate real shadows for everything but I’d prefer not to slow rendering down for that right now (the same reason Blizzard didn’t add it to the client way back when)

August 27th, 2012 - Fades Obviously, you can’t draw every...

Mon, 27 Aug 2012 03:05:15 -0700

August 27th, 2012 - Fades

Obviously, you can’t draw every object in every map tile, so typically you implement a draw distance for objects in addition to a scene draw distance. One thing that has been really bothering me with the draw distance is the instant on/off clipping of objects. So today, I also implemented fade-ins and fade-outs for all objects going in and out of view. In the above video, I’m demonstrating the fades, and messing with the draw distance to make it a bit more obvious. This gives you a much smoother experience in the client, similar to the WoW client.

August 27th, 2012 - Spawning and Leak-Hunting Once again, I have...

Mon, 27 Aug 2012 00:55:06 -0700

August 27th, 2012 - Spawning and Leak-Hunting

Once again, I have time to work on this. Expect lots of updates now.

It’s useful to be able to spawn creatures, for all sorts of reasons - so I finally implemented it. Again, note that this is not a local client hack - it actually spawns the mob into the world on the server.

In other news, I’ve found many of the COM memory leaks. Though I am still leaking memory, it’s no longer COM objects and the leaks are quite reduced. This is exciting news.

I just stumbled across this website, and just wanted to say I'm very impressed! I just started learning direct3d11 myself and realize just how much work this is. Great work. (And I know that's not an "Ask me something" but I wasn't sure how else to say this!)

Sun, 22 Jul 2012 21:52:49 -0700

Thanks for writing. It was indeed a lot of work. In fact, it would have been overwhelming to look at the big picture too much. The key was to break it down into a series of small manageable steps. I also highly recommend the book “Practical Rendering and Computation with Direct 3D 11.” The project would have been absolutely impossible for me without it.

July 19th, 2012 - Light Examples Here are some more examples of...

Thu, 19 Jul 2012 13:46:00 -0700

July 19th, 2012 - Light Examples

Here are some more examples of the light database in action. Not all colors are used so far (like clouds/sun/moon since those aren’t implemented yet) but it gives you a good idea of how close to the actual game it gets you. Of course these are all editable for your own game.

Rendering Wall

Fri, 06 Jul 2012 23:49:00 -0700

July 6th, 2012 - The last 2 months or so, I have barely gotten anything done on the project. There are a few issues I’ve run into. One is that since I am now rendering model-sets down to the last bottle on a table - I’m drawing far more objects. This requires way better culling than I am presently doing. A city scene like Stormwind for example has an incredible amount of models in it without proper reduction. I am beginning to implement a portal system, though I am really not too sure how it will work yet.

Essentially, portal rendering techniques which most people think of as being good for closed dungeon environments, let you not draw parts of a world or model that are not visible because you are not viewing them through the correct ‘portal’ - some geometry that separates rooms or areas. Beyond dungeon rendering though, it’s quite good for city scenes, so that you are only drawing the facade of a building and not anything inside of it, unless you can see into the front door for example - or not seeing upstairs when you are not within the structure. These improvements will vastly improve the rendering of scenes with many buildings. Until I complete that, things are pretty slow.

Additionally, I am dealing with your usual memory leaks and also certain hard to trace crashes.

If I don’t make enough progress soon with the portal rendering, I may get rid of that low level of model sets, and concentrate on some more system-oriented things like tackling combat, auras, and spells in a complete way.

For now, I have incorporated portal information into the model format and am converting WMO portals, but I am not using that information yet in the rendering itself. That is the next step.

April 21st, 2012 - Models in Models I have a sort of russian...

Sat, 21 Apr 2012 04:57:00 -0700

April 21st, 2012 - Models in Models

I have a sort of russian doll parent/child pattern for models. That is actually how I attach objects to terrain tiles. However, I didn’t get models inside models other than that terrain pattern working until tonight. Theoretically all these models could have other models attached to them as well. This really fills out the world as the WMOs in WoW have tons of objects tied to them. This was a HUGE pain in the ass that I hope to forget ASAP. The hardest part of this project continues to be the model conversions and not the actual engine.

April 19th, 2012 - Sky Color Bands … are a go. These are now...

Thu, 19 Apr 2012 02:49:37 -0700

April 19th, 2012 - Sky Color Bands

… are a go. These are now calculated from a light database customizable for various times of day and interpolated across these time ‘keyframes’. The sky is made up of 5 colors shaded by vertex colors and therefore interpolated by the shader.

To get the actual sky cone, I analyzed the WoW client in PIX, exported the mesh from the vertex shader, hand-converted it to OBJ and then converted that to my model format via importing with AssImp. The things I do to be anal about this project..

April 18th, 2012 - Lighting (another one) As promised, another...

Wed, 18 Apr 2012 01:54:16 -0700

April 18th, 2012 - Lighting (another one)

As promised, another example. Sky still not matched. Coming soon!

I am having to extract the sky-cone mesh using PIX to analyze the WoW client. I do not have a suitable one that can accurately use the color band data. That’s the reason it’s not done yet. It’ll really be the icing on the cake for the sky color bands to match.

I am now starting to have significant problems with framerate in my rendering. I need to really hit the books and resources to figure out my bottlenecks. I’m fairly sure it’s CPU-bound at the moment, but because of calls to the API, not other stuff.

April 15th, 2012 - Light & Fog, for real I spent the last...

Sun, 15 Apr 2012 17:05:10 -0700

April 15th, 2012 - Light & Fog, for real

I spent the last bunch of days setting up my engine to properly work with world light databases similar to how WoW rendering works. It is now working almost perfectly.. Check out Deathknell with actual midnight lighting parameters. I’ll post some more different types of things from other locations as well.

April 10th, 2012 - Holes Once you’re dealing with complex...

Tue, 10 Apr 2012 12:45:00 -0700

April 10th, 2012 - Holes

Once you’re dealing with complex terrain/object interactions, such as caves and things built into hillsides, you come up against an issue that, at least to me, was not foreseen. The terrain being continuous means that with these types of world objects that essentially hollow out areas of the world, the entrances to such areas will have a small section that the terrain interferes with. For stairs going down from the ground, it’s going to be quite a small area, however it can also be a substantial area, as in the above screenshot. a good bit of the entrance area of this cave would be covered by terrain without supporting holes. WoW’s map tiles supported 4x4 ‘hole’ identifiers for each 145 vertex submesh. That seems good enough to me. There are still certain things that would look weird, and the world designers probably just avoid them.

Holes are not best understood as a ‘rendering issue’ per se. The best method in my opinion is to actually ignore the triangle fans or strips that match the hole mask, when building the index buffer. So in this case since the submesh is 8 x 8 triangle fans, and the holes are 4 x 4 - for each area where the hole bit is 1, you ignore all 4 triangle fans that make up that portion of the submesh when building the index buffer. This method can also be used to ignore parts of water rectangles.

April 10th, 2012 - Shadows This is one area that the WoW client...

Tue, 10 Apr 2012 12:35:00 -0700

April 10th, 2012 - Shadows

This is one area that the WoW client at this point in the game’s history was still quite bad at: shadows. I will probably be supporting higher resolution shadow maps than the WoW tiles of 3.3.x did. Double the dimensions would probably look pretty decent. Ideally of course I’d like to support real projected shadows and not pre-baked ones. Performance of rendering will have to get quite a bit better before I do that though. As of now, however, I’m supporting baked shadows exactly as the WOTLK client did. Not great looking, but that’s what the converted data supported.

April 8th, 2012 - Another visit back into Warsong Gulch now that...

Sun, 08 Apr 2012 04:35:45 -0700

April 8th, 2012 - Another visit back into Warsong Gulch now that things are much more complete - tonight I got world object animations working - hello, birds!

April 7th, 2012 - After many struggles, water is working....

Sat, 07 Apr 2012 17:39:56 -0700

April 7th, 2012 - After many struggles, water is working. It’s kind of a shame that I spend most of my time dealing with the coordinate system hassles of actually converting the models and not as much time on developing features of the engine. I guess I have to bite the bullet if I want to use all this stuff.