Darkwind Media Blog

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

If you missed it, Bombs is a showcase game we’re working on taking advantage of Luster’s power and ease of development. We’re well on our way, with only 2 weeks put into it there’s multiplayer matchmaking and initial gameplay is being teased out. Here’s quick word on Bombs.

Each player starts with a single immobile base and 10 towers. These towers each exert and repelling force of a fixed amount. This repelling force only affects bombs (not other towers or bases). Bombs are “launched” from your base and are then directed toward and enemies base. First person to score 3 hits wins. But be careful, enemies may place their towers in a defensive configuration and could possibly even use your own bombs against you. To win you need to play a combination of offense and defense. The only things you directly control are the towers. Guiding the bomb is done purely with repelling forces.

With development going so quickly we’ll have initial screenshots and gameplay videos very soon.

Updates for the internal version of Luster are coming fast now. If you aren’t up to speed on what Luster is, it is a small, power-packed, rapid development platform for 3D applications. Following a Flash model, users install a common base which then allows them to access any application created with the system. One install, infinite applications. Developers create applications using the Eclipse-based editing environment. As we near a major milestone, Luster has matured into an amazing system, and it will be battle-tested at two major technology conferences this summer.

The first is Siggraph. For me, this is best conference of the year. It is an unapologetic geek-fest, where the greatest minds in graphics research gather together to show off their stuff. Well, one of the pieces being shown is from RIT. It is the Dome project, which is an installation meant to be a very inexpensive version of a Cave. One of the projects showcasing the Dome at Siggraph will be a 3D asteroids game created using Luster. Speaking of installations, a version of the Dome may be installed at the Rochester Museum of Science. We are unsure yet if Luster will be used to power any application used there.

The second major conference is IGARS (International Geoscience and Remote Sensing Symposium). This is a conference put on by IEEE and is an important one in the world of remote sensing. What’s remote sensing? Spying on you with satellites. Luster is being used to power an application which visualizes 3D sensor data in real time.

What else is Luster up to? At the moment we are creating a compact strategy game called Bombs. It supports up to 4 players and is a real-time, fast paced, physics-based competition where you use force towers to push and pull bombs to destroy your enemies’ bases. If that description is a little short then you’ll be happy to know we’ll be putting out videos in the coming weeks that explain it a bit more.

Stay tuned, because we’ll only have more news about Luster and other Darkwind Media projects as the summer continues.