• News
  • OldBlog

WebGL Animation Test

Here is the result of an animation test in WebGL with data exported from Mana Web.

The scene was rendered in Firefox and the frames exported to a Node.js server. The render also shows off variance shadow maps running in Three.js.

To Three Or Not To Three

That is the question!

I’ve been spending time evaluating Three.js as a potential export target for Mana Web. As a framework, Three is nicely organized and a great starting point for experimentation. Its renderer, however, is lacking some key features that I’d like to include in an online model viewer.

For one thing, there are no variance shadow maps. It wasn’t as easy as I’d hoped, but I’ve managed to add them to my local copy. The screen shots below show the results of that effort. The code is messy right now, but once I’m finished I will see if I can get it added to Three officially. I’ve never used GitHub before, but I think it is time I learned!

webgl_viewer01 webgl_viewer02
webgl_viewer03 webgl_viewer04

Another thing I’d like to see is animation blending. At present, there is no way to upload multiple animations for the same character and intermix them. An animator can blend morph targets with skeletal animation, but cannot transition from an idle pose to walking to running.

As much as I like Three, it is tempting to start a Mana.js project. The features I need already exist, I’m very familiar with my own code, and I’ve done a partial port before. It would be more of a known quantity.

But Three.js already has quite a following and it is actively updated. Perhaps the best course is to do both. I can port Mana to JavaScript and provide a plugin that uses the Three.js renderer, but activates additional features.

Elevator Pitches

A short, but noteworthy, article on pitching products recently caught my attention (to read it, click here). It presents a “value proposition” statement that I’ve decided I will one day blow up to poster size and put on the wall of my meeting room or office or foyer or heck, maybe it does belong in an elevator!

It goes like this:

For [target customer] who has [customer need], [product name] is a [market category] that [one key benefit]. Unlike [competitor name], the product [unique differentiator].

Honestly, if anyone is pitching a product or service and cannot fill out the above mad lib, how can they expect their audience to care, much less give them their time and/or money?

With that in mind, here’s my value proposition for the lite version of Mana, which I’ve decided to call “Mana Web,” for now:

For anyone with a web page who wants to include interactive 3d content, Mana Web is a model loader and viewer that exports a ready-to-use Html 5 web page (using WebGL). Unlike services like SketchFab and Verold, which are cloud-based, the product allows the customer to upload content to his/her own site or make use of cloud storage alternatives.

Mana is a little harder to pin down because I imagine it having more than one target customer and many potential uses. Here’s one stab at it:

For game and app developers who want to mix 2D and 3D content, Mana is a toolkit for crafting software that tracks and seamlessly blends various forms of media. Unlike Unity3D, Mana will satisfy hobbyists with its ease of use (Lua Script, anyone?) and professionals with its lack of restrictions (no $100k cap).

Future In The Cloud?

My recent web browsing has been focused on sites that offer 3d model galleries. I’ve known about SketchFab and p3d.in for some time, but a couple of others have recently blipped on my radar. One is called “clara.io” and it appears to offer more than the others because in addition to allowing uploads of pre-built models, it has a modeling interface. I gave it a try today and found it extremely buggy, but it is in beta.

Another site called “verold” offers a service that seems similar to p3d.in. I signed up and in a fairly short time had my test model uploaded and looking decent. Here is the result of that, but you must have a WebGL capable browser to view.

The verold options are pretty limited, but I’m sure that will change. Their claim is that a much larger set of tools is on the way and will allow for custom programming of uploaded content. People will be able to make games from within their browsers!

Perhaps I’m old school, but I prefer having direct control over my own content. I declare this as I type into a browser logged into a blogging service provided by Google. The current business trend of selling software as a service is not going anywhere and certainly has its advantages, both for the businesses and their customers.

Anyone can upload models into the verold gallery and the service is free as long as the models are public. They charge only for private projects and the $7/month fee seems reasonable. However, there are many cloud storage options. What if I want to use one of those? Or what if I already have my own website with storage that’s already paid for and I want to use that instead?

These questions bring to light a new possibility for Mana.

At this time, I am still thinking about running a KickStarter for a simple version of Mana called Mana Lite (I’d call it Mini if not for Apple). It would be an easy to use model and scene editor that would export an HTML 5 web page. The resulting HTML and JavaScript files would be nicely formatted for readability and could easily be modified to suit any purpose. If Mana Lite proves popular, many features could be added for editing models, textures, lights, shaders, animation, etc.

Most importantly, the exported content could be uploaded to anywhere the customer pleases!

Not With A Bang

But a trickle?

I’m now convinced that WebGL should be a part of Mana’s future.

WebGL is OpenGL for web browsers and Mana is an OpenGL engine, so a port seems only natural. Three years ago, I actually did a partial conversion as both an exercise and an experiment. The engine ran at a reasonable frame rate in both Chrome and Firefox, but then, it wasn’t doing that much.

My hesitation to move forward with it was threefold.

One, the performance and support were lacking. Microsoft had no intention of including it in Internet Explorer and a lot of features were still missing in the browsers that did.

Two, the openness of the web means that a direct port would be showing the world the guts of Mana. Let me be clear that I want for as many people as possible to use Mana and make cool stuff with it! Eventually, I do expect to make the source available – but not just yet.

Three, scripting Mana is Lua-based. A complete WebGL version would require some kind of Lua to JavaScript interpreter. Either that, or force users to maintain two sets of script if they want both desktop and web deployments of their apps.

Enter Three.js, an MIT-licensed WebGL engine that has proven itself quite popular. Kudos to Mr.doob and the other contributors! It was not far enough along when I looked into it years ago, but that appears to have changed. The documentation is still lacking, but there are lots of great examples that seem pretty straightforward.

If Mana featured an export that would produce a ready-to-use webpage using the Three.js renderer, I think that would be useful to a lot of people. Not to mention fun!

Perhaps a new KickStarter is born.

New Year, New Goals

For some time, I have been somewhat undecided on the direction to take Mana as a product. My reason for creating it in the first place was that I want to use it for my own projects. However, it did occur to me that others might find it useful and that I could turn that assessment into a small business. The fact is I’d really get a kick out of seeing what people would do with it!

Hint: It’s not just for games!

I spend a reasonable amount of time scouring the web and making mental notes on other products and what they offer. When this project began, I wrote a post about Adobe Air and neglected to mention Unity3D, which has clearly taken off and is now one of the go to tools in the game industry. There is no question that I have kept its popularity in mind when considering my business strategy. To a certain extent, I’ve been withholding Mana as a product until it matches its competition.

I believe the time has come for a small change in direction.

Mana is currently a Windows-only product, having been developed entirely on my aging XP computer and tested on my 8.1 laptop. OS X and Linux versions should be fairly easy ports thanks to BlitzMax, but currently I lack the necessary hardware.

Oh, and fear not, the XP machine will soon be replaced. My girlfriend assures me it is garbage, anyway!

The future is mobile and it would be silly to ignore that enormous market. It has always been my intention to see Mana used as a tool for education. To that end, the more devices that Mana can reach, the better.

That’s where WebGL comes in.

Target Misplaced

There’s a pretty funny opening scene in an episode of “Malcolm In The Middle” that involves Hal and the simple task of changing a light bulb. While getting the bulb off of a shelf, he discovers the shelf is loose. When he gets a screwdriver to fix the shelf, the drawer the tool is in squeaks. When he gets the WD-40 to silence the squeak – well, you get the idea!

My plan two months ago was to have an alpha version of Mana available online in very basic form. I figured it wouldn’t be difficult to get a version up that allowed importing content for viewing purposes and over time, I’d trickle out the rest of the features. It turned out that even that simple goal uncovered a number of other things needing to be done.

For one thing, I needed a proper web site. As much as I’d love to hire out that work, I am at present a company of one with a budget of zero. I’m familiar with html and css, but I’ve never set up anything more complicated that requires php. So, I did what many have done before and turned to the internet for a solution. I wanted a blog site that I could grow into the face of my business. After some research, several false starts, and yet more hair-pulling, I have the framework set up for ThinkMartian.com – that’s my brand, please wear it out! The site is not very pretty, but at least I have a place to start uploading Mana documentation.

Another thing I needed was a proper exporter. I use 3d Studio Max and have some scripts that export to the xml format Mana loads. However, the scripts were lacking an interface and I have since written one (maybe 90% complete). Even so, I didn’t want to limit even my initial offering to people with 3dsMax, so I decided to spend some time hooking up the AssImp library. Its purpose is to import some thirty-odd common model formats. In the process of doing that, I realized Mana would need to load more image formats (e.g. DXTC) and that led to hooking up the FreeImage library. Yes, I do sometimes wonder if I’m participating in a (nerdy) sitcom.

But then, don’t we all?

Target Acquired

About two and a half weeks ago, I set a six-week goal for having my first “alpha” product functional. Each week would have its own set of goals coinciding with the premiers of the last six episodes of my current favorite television show, Breaking Bad. As of now, I’m quite behind schedule.

In part, the reason for my lateness (this time) is because I felt the need to finalize my decision about which physics engine to use. I’ve had Newton Game Dynamics hooked up for some time, but it’s not being supported much these days. Its capabilities are limited to rigid objects – no soft bodies, cloth simulation, or built-in rope physics. Bullet, on the other hand, has all of those things and more and is getting updated frequently. I knew I’d eventually want to switch. Yet it was a complete unknown to me as to how to get Bullet, a C++ static library, working with BlitzMax. My plan was to put it off until it was absolutely necessary and probably to hire someone to do it (if possible).

However, I really wanted some basic rope physics in my demo. When I looked into using Newton for that, the official site was down. Leave it to fate to show me a new path! I took it as a sign that I should look into Bullet further, and I can now happily say that I’m glad I did. After a bit of head scratching and hair pulling, Mana now uses Bullet for its physics. The implementation still needs some work, but rigid objects, constraints, soft bodies and rope physics are all functioning!

As much fun as it would be to keep playing with Bullet for the next month and implement ragdoll and vehicles (vroom, vroom) and cloth physics, my original six-week target is calling again.

Lifus Interuptus

I had intended to update more often, but an unfortunate act of clumsiness rendered my right hand more or less useless for the past month. In addition, I went on a short trip to Illinois and made some repairs to the condo I was in the process of selling. All of this non-Mana-related stuff has slowed the momentum I had in March.

Never fear, work on Mana continues! At the moment, I am making decisions regarding the interface. I am finding it to be much more work than I anticipated simply because there are so many possible approaches to design and functionality. Since I expect Mana to be ported to many different platforms eventually, I believe it is best to consider those targets when designing the interface. In other words, when Mana is running on Android or iOS, I would prefer that the interface still function in a predictable and consistent way without sacrificing the features we have all come to expect on the PC (and Linux and MacOS) and without having to make many platform-specific exceptions.

To that end, mouse hovers will be limited mostly to highlighting widgets and perhaps providing tool tags for desktops only. Right-click menus will be functional on desktops, but they will also have visible triggers in order to serve touch screens. Of course, it will be possible to use Mana to create virtually any kind of interface, but I think it is important to keep Mana itself reasonably device independent.

Marching Orders

In my last post, I compared objects in the Mana internal directory structure to the files residing in folders on your computer. Taking that a step further, Mana objects have something else in common with files. They can be put into one of two general categories – data or executable (functional).

Most files on your computer are simply data that is read in by applications. Similarly, most objects in Mana are merely containers. Models, widgets, lights, cameras, and so forth are all basically data associated with names. But applications are driven by functions that carry out instructions on those objects.

In Mana, functions are objects like any other and, in a sense, most objects act like functions.

Confused? I don’t blame you!

Mana operates something like a set of dominoes. One object of your choosing is the start of a chain of events that unfolds the purpose of your application. Every object has a set of things in common and chief among those is an Update method.

That is important! So I shall reiterate!

Every object has an Update method and all objects are linked in a hierarchy. Updating an object cascades down through all of its children and their children and so on. Like dominoes! If you want your application to run in a loop, use a looping function at the top of your chain.

Now, back to functions! Here is a simple, and rather silly, one written in Lua.

function MakeMultipleWindows( n )
 for i = 1, n, 1 do
  mkWindow( “Window” .. i, 0, i * 110, 200, 100 )
 end
end

It expects one integer parameter and makes that many windows. Functions written like this are available only in Lua and there’s nothing wrong with that. Entire applications can be written this way and there’s nothing stopping anyone from sharing scripts!

However, if a function is to be executed as part of a chain, it is best registered as an object. That declaration looks something like this.

MANA.RegisterFunction(
 function MakeMultipleWindows( n )
  for i = 1, n, 1 do
   mkWindow( “Window” .. i, 0, i * 110, 200, 100 )
  end
 end,
 ”MyFunctions/MakeMultipleWindows”,
 {MANA.META.INT},
 {}
)

The MakeMultipleWindows function is registered as a function object that can be cloned and attached to other objects and have children of its own. I’ll leave the breakdown of the syntax for later. One other benefit of registering functions is that they are packaged as part of the module and that makes distribution simpler.

As you may have guessed, linking functions together in combinations can have powerful results!