DarkWind Media Blog

It has been a while since the last update. That is because we have been very busy, with updating Luster and working on new projects. Virtual Theater has started and is going well. Luster has worked well so far for that project. I hope to have some good updates about that soon. With new versions of the runtime, previous applications and demos have been updated. Some of them have been upgraded with more advanced features.

The physics demo has been updated to include far more cubes than before.

The towers are now so tall that they have become quite wobbly.

The black balls in the simulation suck in objects around them, causing a cluster to form around themselves. Then they explode, shooting the objects out in all directions. This is an explosion as it is happening.

Because of the advanced nature of the black balls, they previously were very performance heavy. You really could only shoot one at a time. Here is a screenshot of multiple black balls being shot at once. They interact with each other and the rest of the world.

I am grabbing one of the blocks from the top of the stack. You can pull blocks out from anywhere, causing the whole structure to tumble.

Over the summer, new content was produced for HVP. This shows the extreme detail put into the modeling of the nerves and bones. As always this runs at realtime framerates, despite the extremely high polygon count.

This is another view of the lit skeleton and nerves. The entire body’s peripheral nervous system was painstakingly recreated.

This is a closeup of the detail in the legs behind the knees. There are quite a few nerves here, as almost anywhere, and the detail is amazing.

Flying through the cavities in the body gives you great new views on the modeling detail.

Mesh viewer is much as it was before. This model is fairly high-poly, and the shader gives it a rim-lit glowing look.

By switching to wireframe view you can see some great detail on this Star Trek inspired model.

Luster continues to pick up stream. New features are in development even as new projects start up.

The Virtual Theater project has begun. This is an ambitious one. It aims to recreate a full theatrical experience in a virtual world. This means that audience, actor, stage manager, director, etc. can all be in remote locations, watching and interacting through a virtual stage. Luster is forming the core backbone of how this experience is being created. Since this project has just started I’ll have more details soon.

Another project is related to medical imaging, which is also just now starting. I have practically no details to share right now, other than to demonstrate the huge breadth of Luster’s power.

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.”

Yes, that’s correct, Stormtrooper.

Over the last couple weeks, I have been working with Brian on the Human Visualization Project. While brainstorming with the doctors searching for the idea we want to focus our energy on, we have thrown around a lot of ideas ranging from games to training modules.

During one of our recent meetings with the medical illustrators, the idea came up that we do something with the central nervous system. With seemingly endless branches and paths a signal could take to reach the brain, we wanted to try and help make that easier for students to learn. We fired up Luster and decided to see what we could do.

Our goal: the user should be able to interact with the different branches of the nervous system by clicking them and following which path a nerve signal would travel if it was stimulated on the skin.

Since we were lacking some assets at the time, we decided to make things a little interesting. Enter Stormtrooper! The following video illustrates someone using what we created in Luster.

Hope you all enjoyed that, we’ll be posting some more pictures & videos of the real thing in the next couple weeks so check back to see how it’s going!

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