Now Playing Tracks

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.

September 17th, 2013 - Distance Render Test

Well, we’ve come a long way haven’t we…? This is above valgarde with 1200 draw distance, 1200 object draw distance, 2 map tile radius, 4 low rez tile radius. I’m pretty happy that I’ve been able to optimize the culling and rendering to deal with throwing this much stuff at it.  Portals are still only partially implemented, which will increase the power quite a bit.

Obviously there’s still some weirdness with some texture anims and transparent meshes, you can see some not-so-pretty bits here, but we’re getting closer.

September 16th, 2013 - Texture Animations 2

.. and a second one..

September 16th, 2013 - Texture Animations 1

They’re finally pretty Solid.. Here’s one video..

September 9th, 2013 - GitHub is a go

I’ve made my first commit/release of the MMOSDK installer today - build 10.

I deliberated about this quite a bit.  In no way is this ‘release-ready’.  Think of it as pre-pre-pre-alpha.  However I felt it was important for my own momentum to not put off the deployment work that I will need to do anyway.

I am beginning work on the wiki pages and howtos, and hope to be moving pretty fast with that.

Again, if you interested in working with it, and are a hardcore tinkerer who doesn’t mind the big mess that comes with dealing with software at this stage, send me an Ask here or a pm on Modcraft with your github user name and I’ll add you to the project.

Here’s to one of many many many builds to come.

August 14th, 2013 - Editor Frenzy

Well, after a lot of time spent finding crashes and memory leaks (ongoing), I decided to put some serious work into the editor.

I’ve now split the World window into its own window rather than trying to fit it in the editor’s main window layout.  There are now 3 floating windows: Main,World, Toolbar (which will be dynamic).  Thanks for suggestion, Garthog.

I also spent some time getting the beginnings of multiple edit modes to work.  Above is the beginnings of terrain editing working in the editor.  Extrusion, etc.   As any modeler knows, this needs a lot of fine tuning, multiple radius, smoothness etc. before it’s very useful for someone to build with but those are just some easy mathematical adjustments which will be coming soon.

For those doing D3D11 out there, my method is basically to make all the buffers IMMUTABLE in the client, but DYNAMIC in the editor.  This lets you Map/Unmap in real-time and edit terrain - but at a performance disadvantage compared to IMMUTABLE buffers.  However, I use texture arrays almost exclusively in my engine and unfortunately, you can’t have a texture array with DYNAMIC usage.  Sadly that means I will have to re-write the terrain texturing code to have an editor-only path that doesn’t use arrays, or else it won’t be possible to paint alphas at all.  There will also need to be editor-only shaders.  Just what I was hoping to avoid.

If anyone knows why this limitation exists I’d like to hear about it.

July 9th, 2013 - Background Tasks

Hello again!  The time has come for me to get a new machine.  My core 2 duo from 2006 is really causing me a lot of difficulty working on this project!

However, I have still done plenty of work.. if you only want to see some pretty pictures and aren’t interested in any technical details, avert your eyes now!

OK.. since the last post I have:

— Converted the project to Visual Studio 2012, from 2008.  This required buying 2012. This was actually a lot of work.  I converted for three main reasons:

  1) I had been considering buying Glowcode or VTune (both very expensive) for profiling, but just couldn’t justify the money.  VS2012 has profiling built-in, and it has been absolutely awesome to use.  Glad I waited.

  2) VS2012 has graphics debugging (aka its own PIX style debugger) integrated.  Can’t tell you how happy I am that I will not be using PIX much ever again.

  3) VS2012 integrates HLSL compilation (with all associated flags/options) into the build process so you don’t need to build them with external batchfiles anymore, and can change the compile options per project configuration more easily.  This was especially nice as it seemed like VS had bugs related to custom build tools not running for every single file that was changed, it seemed to only do one at a time for each time you hit build.

— Done plenty of work on the editor..

    o Made a ModelWriter class for saving any changes to models (map tiles primarily right now)

    o Added surface-movement placement of models (e.g. based on terrain mesh collision) rather than just X/Y/Z free movement.

    o Made a Decal shader for things like brushes (using spellshadow now as a test for object placement)

    o Allow adding of any model object in the data tree, to a map tile

    o PropertyGrid data for every model object and asset (in addition to the database items that were already there) - not all editable yet.

— Created a texture format, called .TXR. (I guess you could say my simpler answer to .BLP).  This format supports the mipmap chain, and defines the size and number of mips in the header. Currently its RGBA uints but I will support various image formats ideally.

— Used said texture format in creating  texture converter tool that can convert all the stuff that was converted from BLPs (or really anything stb_image.c can load) into .TXR.  My engine currently loads .TXR for terrain textures.  A lot faster than box filtering custom mips every time you load a texture.  Soon I will load .TXR for all textures.

— Converted my PacketHandler (used by client/server) to use function pointers to access the handlers faster.  Also started prep to convert the socket code to be binary rather than text-based - harder to debug but will be much tighter/more compact and faster (and thus scalable beyond local tests)

— Worked on creating a default SQL file to install into a local database for starting to use an editor on your own install of the tools.

— Added minidumps to all apps so that crash reports will be useful (or even existent…thanks Garthog for prodding me there)

— Removed 99% of the extraneous ‘fixing’ i was having to do in my ModelLoader/object initialization due to weird WoW asset issues - usually having to do with positioning.  I moved all these fixes to the converter as it should have been to begin with.  

— Fixed a huge copy bug that made water rendering quite slow and made it the slowest part of the rendering frame.

— Re-tooled the ModelLoader into separate functions for ease of profiling and cleanliness.  There is a function per chunk type basically (sometimes more than one).  ModelWriter will get the same treatment soon.

— Converted all ‘flag-like’ variables the shader used into a single uint for boolean operations.  This reduced per-mesh buffer copies by quite a few bytes.  Significant improvement.. stupidity that I didn’t do it earlier.

— Converted tons of common shader stuff to common shader #includes, making changes much faster now.  I couldn’t really get this to work before.  Originally it was because I did run-time shader compilation which is very tricky to get working with include handlers.  Now that i’m compiling HLSL natively in VS I’m VERY glad to do it - though it didn’t work at first.  It couldn’t find the file I was including for some reason.  Then it magically started working. Hrm.

— Added a lot of things to my debug toggles for comparing framerates/performance, e.g. instancing opaques vs instancing transparents (or both at once).

So you see, even though some start to call the project ‘dormant’, quite a lot is actually going on behind the scenes.  Typically I don’t like to post a blog entry unless I can show something new in a video or picture, but there’s LOTS going on, believe me!

Special thank you to Garthog for being my first alpha-tester and helping me figure out many local-specific configuration problems that would be a disaster in the future.  

On the topic of alpha-testing, thank you to those who volunteered - I’ve added most/all of you on github.  I hope to put some deploy builds up there as soon as I can make a HOWTO that is complete and makes sense.

More soon!

We make Tumblr themes