:: The story of a lone developer's quest to build an online world
:: MMO programming, design, and industry commentary
[The Imperial Realm :: Miranda] [Blog] [Gallery] [About]

The One Man MMO Project

By Robert Basler on 2012-12-01 19:32:35
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
If you haven't already, check out Part I.

Things have been quiet on the blog the last couple of weeks but there has been lots of exciting progress behind the scenes. I purchased World Machine and modified my terrain import tool to read the beautiful World Machine height maps as well as its flow, deposition and wear maps.

I've increased the terrain heightmap resolution from 10 metres to 2.5 metres, and the improvement is startling. There is now lots of fine detail on the heightmap which makes it much more realistic and interesting. The rolling hills are officially retired.
By Robert Basler on 2012-11-28 23:22:55
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
I'm working on optimizing my terrain processing program a bit. I figure with the current process it goes through it will take a whopping 9 days full-tilt to process my terrain data. So I got out AMD CodeAnalyst to see what was taking the time. I was shocked that CodeAnalyst reported that my app was spending 91% of its time waiting on spinlocks.

I didn't believe it. But that didn't mean I wasn't going to check.
By Robert Basler on 2012-11-05 21:02:09
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
I was debugging a texture settings bug when I got this cool looking result:

PsychedelicBug.png

Read more... (0 comments)
By Robert Basler on 2012-11-04 01:04:26
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
It's a milestone. I'm working on my final rendering feature! With gamma correct Ambient/Diffuse/Specular throughout the world, hardware particles for effects (got those working a couple weeks ago) and some lovely shadows, I have but one big rendering issue left to address: Terrain 2.0.

My current terrain is a 300x300km USGS heightmap with 10m between samples and wang-tiled splatted textures, and it makes for beautiful rolling hills. But that isn't super-interesting as a play-space.

I took a couple days for hard thinking -- the hard thinking primarily due to the one big requirement I refuse to give up: a 300x300km terrain. It is amazing how many features go from simple to unwieldy when you scale them up.
By Robert Basler on 2012-10-16 12:11:56
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
Despite the hype, there's no doubt that Windows 8 Metro is just a regular Windows Desktop application. I was playing around the Windows 8 Consumer Preview and I tried Aurora Suite 2005, which is an accessibility program for Windows, when this happened:

MetroIsJustADesktopAppOneManMMO_small.jpg


Made me laugh seeing a standard Windows Desktop app running on top of Metro. I can click on the icons, and bring up the Aurora Suite menus, but as soon as I open a dialog, it switches back to the desktop. Aurora Suite uses Windows' HWND_TOPMOST feature.
Read more... (1 comments)
By Robert Basler on 2012-10-14 00:21:07
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
I've known for a while that my graphics renderer wasn't gamma correct. Up until a couple years ago, this wasn't an issue, then somebody noticed that we've all been doing lighting calculations wrong for the last 20 years. You've probably heard of gamma. In effect it is a brightness adjustment. Without gamma correctness everything renders a little too dark.

Textures typically are in a color space called sRGB with a gamma of 2.2, lighting is done in linear space (gamma of 1.0) and the screen most likely has a gamma of 2.2. The idea with gamma correctness is to make sure that the input textures and colors are converted to linear space before they are processed with the lighting in the shader, and that the result is converted back to gamma 2.2 when it is sent to the display.

Thursday evening I discovered this excellent OpenGL tutorial which explains most of what is needed to implement this in OpenGL. There were some details missing, so I'll fill those in here.
By Robert Basler on 2012-09-26 14:34:29
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
The software particle system is running. Here's a screenshot of the oil fire effect I've been using to debug the particle system. It looks quite good when it is moving although there are still a few things I want to add to it. Particles at the bottom go from yellow to red to gray so if you cover the bottom quarter inch so you can't see the particles appearing (which will be done in the game,) it looks like a pretty convincing fire. It was fun finding reference video on the internet. Looked at a lot of oil well fires.

MMO-1 - Particle Oil Fire.png


I can't believe how many adjustments are needed to make a particle effect. I would get one thing looking good, then something else would look bad. First there was popping when particles hit the end of life, so I added a fadeout. Then it didn't look very realistic with just one particle texture, so I added animation. Then there was visual popping as the particle textures transitioned between animation frames so I added fading between animation frames. Then I noticed that particle creation was sort of "clumpy" where there would be a lot of particles created and then a pause, which made the bottom of the fire look like fireworks, so I had to distribute that more evenly. And on and on.

Soft particles are working, I implemented a simple depth check linear fade, not the fancier function from the NVidia paper, but they don't come into play in this screenshot.

Shadows are working, however it looks odd when particles disappear since there's no alpha in shadow mapping so where a particle fades out, it simply pops out in the shadow. I should be able to mitigate that with higher numbers of smaller particles so the popping isn't as obvious.

I haven't done any lighting on the particles yet but I'm going to tackle the hardware accelerated version of this next.
Read more... (0 comments)
By Robert Basler on 2012-09-20 23:23:04
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
Today there was a bug. A bad one. I was trying to use a 4-byte RGBA color value as a vertex attribute to tint the particles in my new particle system. It worked if I set the value manually, I tried a bunch of different colors: red, green, blue, black, white. Those colors worked perfectly. The real color values were supposed to lerp from one keyframe to the next. That totally did not work. If I didn't set the color, the particles were magenta, or sometimes cyan. I checked the lerp calculation, that was good. I checked the conversion from 64-bit color to 32-bit, that had a bug so I fixed that. I looked at the vertex and pixel shaders. They were super-simple so nothing there to be messed up. I checked the color data in the game versus the data in the VBO on the video card with GDebugger and Windows Calculator. The data was identical. I was at a loss.
By Robert Basler on 2012-09-11 18:53:26
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
Really interesting talk on the graphics in Battlefield 3 by Johan Andersson, the Rendering Architect at DICE. Parts 2, 3, 4 have the most "meat". There are sections on lighting, post processing, terrain, particle effects and more. For those not entirely into rendering, he breaks down all the passes that go into a single frame in part 4 (there are a lot.)

Parts: 1 2 3 4 5
Read more... (1 comments)
By Robert Basler on 2012-09-03 00:16:57
Homepage: www.onemanmmo.com email:one at onemanmmo dot com
To get things ready to add the new particle system, I've been adding support for additional fields in my vertices. Previously all my vertices were the same Position/Normal/UV format. I've also been removing the use of deprecated functionality when I have the opportunity.

As part of the vertex upgrade, I wanted to replace my existing calls to the deprecated glVertexPointer/glNormalPointer/glTexCoordPointer functions with the more up-to-date glVertexAttribPointer. While reading about glVertexAttribPointer, I discovered Vertex Array Objects (VAO's.) A VAO combines all the calls you would normally have to do to set up your vertices, VBO's and IBO's into one call. I read about VAO's in the OpenGL SuperBible, but there is some hand-wavey stuff in their code that worried me. Looking into it more, I discovered glGetAttribLocation.

Vertex attributes (position, normal, colors etc) are passed to the shader via an array of integers. You can specify the integers yourself which is what the OpenGL SuperBible does - YUK! Or you can just declare your vertex attributes in the shader code and use glGetAttribLocation to find out where the shader compiler put them for you. Much nicer.

Getting the rendering to actually work however, was a huge pain. I spent a lot of time staring at a black screen in GLDebugger. There is a lot of misinformation on VAO's and I couldn't find a single example of how to use glGetAttribLocation like I wanted. So to save anyone else the pain, here's how it goes.

Recent Comments

Dates are Hard - 2014-11-16 11:58:48 (3 comments)
Also still following this project.
Hope we can jump into action soon.
Dates are Hard - 2014-11-15 02:34:23 (3 comments)
After the Friends and Family Alpha starts I'll be able to talk about dates.
Dates are Hard - 2014-11-14 17:56:02 (3 comments)
That's a shame, but don't forget that your rabid fans are still fanatical, and er, rabid.

Would you like to give an updated release estimate, or are you a little wiser this time :P
Happy Anniversary! - 2014-11-12 11:36:58 (2 comments)
Thanks, we really did have fun. The EMP museum & Darth Vader's lightsaber were the highlights for me although the Seattle underground tour was really interesting as well. It was strange to leave the laptop behind and not work on or even think ...
Happy Anniversary! - 2014-11-11 17:16:10 (2 comments)
Huzzah! I hope you had fun with your family :)
2 3 4 5 6 (7) 8 9 10 11

Admin Log In