Darkwind Media Blog

On Jan. 25th the Rochester newspaper Democrat and Chronicle ran the first story of a new series on business innovation. Darkwind Media was the company showcased in that piece! Please, read the article here.

We were thrilled about the article, and have been absolutely swamped with emails and calls about it since then (hence the late post). We loved working the D&C on it as they were really nice and a fun group of people to work with. It seems we now have some expectations of us to fulfill.

This post is a little unorthodox, but I found this picture on reddit the other day and really enjoyed it. It visualizes our goals here at Darkwind Media.

I do not know who the original author is. It was uploaded here.

After a long build-up the Darkwind Media team is now open for business. We have extensive interactive 3D and multimedia experience and can build a wide range of different interactive applications. We’ve built systems in the fields of education, architecture, medicine, and games. Our 3D system, Luster, enables us to build 3D applications at a blinding pace, with amazing visual and interactive quality. We also have extensive ActionScript 3 knowledge and have built numerous Flash systems.

You can check out our company website at www.darkwindmedia.com or browse through our Luster website at www.luster3d.com. We can help you build state-of-the-art interactive applications or get you started with your own 3D system by licensing Luster to embed into your own applications.

We have finally finished our website and it is live at www.darkwindmedia.com. You should definitely check it out. It is simple, clean, and to-the-point. The big new site that is up now is at www.luster3d.com. That is dedicated to our web-enabled, 3D multimedia platform Luster.

Check out both sites. Luster itself is growing by leaps and bounds. Our mac porting is coming along nicely, with support for almost all of the Luster plugins. Browser support on Mac will follow that. We are now entering a closed beta phase. If you think Luster could help you, or you just want to know more, then contact us.

I made a quick demo that is tutorial, graphics test, and navigation demo. The graphics is a test in volume rendering, so I chose the classic smoke and fire test. This is far below the ultimate graphical quality we could do, and I’ll probably update it later with better lighting. Here’s some shots. The scene has 2x anti-aliasing enabled and the scene is rendering with about 100-200 particles at any time to make up the various volume effects.

A new version of Luster (version 0.12.1) has finally been released. This is an important release accompanied by a new release of the Luster Editor. This is leading up to the next big version of 0.13 (which has many many features).

One of the features in this version is anti-aliasing (a specific anti-aliasing technique called multi-sampling). This increases image quality by a large margin, but it does have some costs. Multi-sampling renders far more pixels than are eventually displayed (this depends on the anti-aliasing quality chosen). So, once again it is a trade-off. Here are some screenshots showing the difference in image quality.

The first image has no AA, the second has 2x, and the third has 4x AA.

After doing the deferred lighting system we hit a content stall. We’re waiting on artwork to put in. So, during this time I toyed with some other lighting systems. One of the goals I’ve liked striving for is more artist control over the look of the application. What this means is that once I’ve finished coding it, an artist can sit down by themselves and manipulate the look as they want. If lighting parameters are bound up in code somewhere this makes it really difficult. After the jump, I’ll show you what I came up with to help with this problem.

Read more

After a lot of experimentation I went back to the deferred renderer for Bombs. I tweaked it, contorted it, and beat it into submission until my framerates slowly started to climb. At some point I got into the acceptable range for my laptop (a range chosen completely arbitrarily and with no testing on other machines). I don’t want to give the impression that everything I said in my previous post is false, it isn’t. I had to make a lot of major sacrifices, but it looks as though this will be the lighting system that will go into Bombs.

The screenshots here actually show some backwards progress on art. We’ve removed the old towers and the sky. While I was working on lighting we were continuing to experiment on the art side. Hopefully some new assets will be ready soon. Note that while the lighting design is fairly complete the screenshots below do not necessarily reflect at all the final look or style of Bombs. The art will greatly affect how the game looks in the end. I hope to have more very very soon.

A few technical details: the scene below has 121 lights in it (which is quite a lot) and is running at around 100 FPS on my laptop with the decidedly unoptimized bloom turned on. Most of the lights in the scene are not really placed well, and are just there to stress the system. Again, art direction will make it look much better.

Since the last update on Bombs I’ve been working on the visuals. While the rest of the team is working on content, I have been creating the rendering engine that would power Bombs. Partly because I hadn’t made one yet, partly because I wanted to see how Luster handled it, and partly because I wanted to see the strengths of it, I chose to implement a deferred renderer.

If you already know what that is, go on and skip ahead. If not, I’ll give you a quick explanation. There are all sorts of techniques you can use when working with the graphics card to render in realtime. One of these techniques is called deferred rendering, which defers (or delays) the calculation of some aspect of the rendering. In my case (and most) the deferred calculations were those that combine the lighting properties and object surface properties to create the final image. Normally, when rendering a scene, the renderer will iterate over each object, then iterate over each light affecting that object, and accumulate the lighting before moving on to the next object. With the deferred system, all objects are processed, their surface properties stored, and then all lights are processed in a completely separate step. When the lights are processed, the stored surface properties of the objects are accessed and lighting equations run.

So, what’s the point? Why do this at all? Well if you’re observant you’ll notice an interesting property of the two renderers and that is the number of times we need to loop the renderer. With the traditional method (known as forward rendering) we must make numberOfObjects*numberOfLights passes over the scene. With the deferred renderer we need to make numberOfObjects+numerOfLights passes. This is a great aspect of the deferred renderer: it scales with the number of lights extremely well.

However, it isn’t all good. There are higher up-front performance costs with the deferred renderer, and usually much higher memory costs as well. These costs can make this style of renderer ill-suited for some applications. Indeed, it made the deferred renderer a poor choice for Bombs. The main culprit I believe was the high memory costs. My laptop video card just doesn’t have the large amount of video RAM necessary to make this technique worthwhile. Bombs was not meant to be a high-end game, but one that is quite accessible. While I can make the graphics scalable, that task would be more difficult with the deferred system. So, I’m going to have to shut down this experiment and build a more traditional forward rendering system for Bombs. I have a lot more experience with this type of renderer, so it won’t take two weeks to make like the deferred renderer did.

As a little gift, here are some shots of the deferred renderer in action. Try to ignore the sky, that was another experiment that’s unrelated to the renderer. I did not put any effort into properly blending the sky with the terrain so that’s why it looks a little “off.”

Bombs has been in fairly frantic development for the last week. Luster has made the development process incredibly quick. We’ve already begun play testing to balance the power of the towers and this testing has caused some minor tweaks to the gameplay.

Read more