Importing 3d Models in Android – Textures

In my previous post I imported a model which I only vertex painted the model. In that same ColorCube.zip file, there is also UV coordinates exported. Originally I was going to do the first tutorial with a texture but did chose to try and see if I could just get the colors working, so I actually striped out the texture code to keep it simple.

First, I think I need to describe how to get Blender to export UV coordinates. Start with the ColorCube.blend file above. Once it’s loaded hover the mouse just below the top menu until it turns into a vertical arrow with an up and down head, as if you were going to vertically resize the window, and then right click.


Continue reading

Importing 3d Models in Android

This post is out of date and I was not able to get the current version of Blender working with an Ogre Mesh export. Update coming soon using Wavefront export.

Happy New Year! When making a 3d game, one of the processes to get streamlined is the 3d content creation pipeline. You could create 3d content by hard coding vertices and texture coordinates, but that is very time consuming. It’s great for simple things like the particles in the particle system demo or just a simple 1×1 tile, but for more complex 3d objects external tools need to be used.

I choose the tools Blender (www.blender.org) for 3d modeling, and Gimp (www.gimp.org/) for texture/image editting. The primary reason for choosing these tools is that they are free. Something like 3D Studio Max costs well over $3000 and Photoshop is around $900. This articles is NOT a tutorial on using Blender but will have some tips on issues that I had come across.

Which 3D Format?

Continue reading

Android Market Downloads July 2010

July 1st is here, Happy Canada Day, time for more app download stats

Wow, nearly hitting 1000 downloads for the Box2d Demo! Both apps have a combined downloads of 1600 and active installs of 500. Really impressive for just a couple of demo apps. I won’t be updating them for a bit because of vacation and I want to work on the game engine.

Android Portable Hotspot

I’m currently on vacation and have been using the portable hotspot on Android 2.2, and I have to say, I love it. The first I used it was a few days ago, my wife was driving the rental so I pulled out the laptop and the phone and gave it a try. Even surfing the net on my laptop using 2G is great (my Nexus One does not get 3G on the phone network I’m on). The phone browser is great for quickly getting small pieces of information of the net but any prolonged use and you should be using an app or a larger device (with a bigger screen and keyboard). I’m using a Asus Eee PC 1000HE to connect to the hotspot and it works no problem.

One of our destinations has high speed cable internet, but for some reason I just could not get my netbook to get an IP address from the cable modem. No problem, just keep using the phone’s access point.

This blog entry was entirely written on my netbook through my Android access point. Try writing a blog entry on a smart phone, even Swype couldn’t make it this easy.

Wiimote on Android

One of the major issues when building a game for Android is the controls. Because their are many different phones with different layouts of buttons and input devices, it’s very challenging to create a customizable user interface which satisfies everyone on all phone types. Chris Pruett (maker of the open source Android game, Replica Island) discusses this as the most dramatic lesson he learned when building a game for Android. You can read his recent post on the Android Developer Blog, Game Development for Android: A Quick Primer. Or watch his Google I/O 2010 talk, Writing real-time games for Android redux (this video and part one are a great intro to game development for Android).

The game I’m looking to create is a Zelda like game. But on the Nexus One, there is no Dpad or keyboard. The only input methods on the Nexus One are

  • Touch screen
  • Soft keys (back, menu, home and search)
  • Trackball

I didn’t include the volume buttons, seriously, we’re not using those for game input. The soft keys are not an option. When holding the phone sideways they are useless as a primary input mechanism. So that leaves the trackball and touch screen. Not all Android phones have a trackball, so that leaves the touch screen. One game I initially modeled was the Zelda – Phantom Hourglass on the DS. That used a touch screen pretty much exclusively as it’s primary interface. The stylus does reduce the screen obstruction when playing and it worked really well for that game. But what we all wish for is a classic Nintendo controller.

Enter Wiimote Controller

Wiimote Controller by C.C.P. Cre@tions connects a Wiimote to your Android phone via bluetooth and allows you to switch the input method to be the Wiimote. I just tried it out with the NES emulator and after some initial config, it works great. First, you need to pair the Wiimote with the phone, do this by running the app and hitting the init button, and the bluetooth button on the Wiimote (the red button under the battery cover). Then change the input method to the Wiimote. On the NES emulator you’ll need to change the key mappings to match the Wiimote, and also check the Use Input Method checkbox.

I can’t say I’m a big fan of using the touch screen for games. I miss the tactile feel of buttons under my fingers. Of course this could very well be just a change that I need to adapt to, maybe in 10 years the idea of using a controller with physical buttons will be archaic. But if it’s not where we are going and we always have game controllers (unless Microsoft’s Kinect has it’s way with controller-less input), it would be nice to set it up this way with a bluetooth controller. Wiimote controller isn’t completely easy to setup (you have to set it as the input method and then go back to the keyboard input method when finished), so it’s not a long term solution. But if it can be a bit more automatic, it’s a good alternative to the touch screen.

For my game, I think I’m going to use the Wiimote as a start for the user interface. It’s not like I’m going to have a big audience anyways, so I’m going to build something for myself to start. That said, if I’m out and about and I want to show the game off, that’ll mean I have to bring along a Wiimote with me. Ugg, maybe I’ll have to support multiple user input methods anyways, I don’t want to carry a Wiimote around all the time. Chris Pruett is right, this is challenging.

Particle System Tutorial on Android Part 6

Pyro!!!

As an undergrad I did a special graphics project integrating ray tracing and particle rendering. The particle system I wanted to render was the classic concert pyrotechnics. This particle system is different from a fountain, the main difference being that there is an air resistance factor that needs to be taken into consideration. The new particles are emitted from the source at a random velocity vector as shown from the initialization code.

private void initParticle(int i)
{
    // loop through all the particles and create new instances of each one
    mParticles[i].x = 0f;
    mParticles[i].y = 0f;
    mParticles[i].z = 0f;

    float DOUBLESPEED = 20f;
    mParticles[i].dx = (gen.nextFloat()*DOUBLESPEED) - (DOUBLESPEED/2f);
    mParticles[i].dy = (gen.nextFloat()*DOUBLESPEED) - (DOUBLESPEED/2f);
    mParticles[i].dz = (gen.nextFloat()*DOUBLESPEED) - (DOUBLESPEED/2f);

    // completely random color
    mParticles[i].red = (gen.nextFloat()*.5f)+.5f;
    mParticles[i].green = (gen.nextFloat()*.5f)+.5f;
    mParticles[i].blue = (gen.nextFloat()*.5f)+.5f;
	
    // set time to live
    mParticles[i].timeToLive = (gen.nextFloat()*1.5f) + 0f;
}

In this system the initial speed is exponentially decreased. In this case, decreased by nearly 100% of the max particle speed per second (taking into account the framerate of course). Below is the code added to the update method to apply air resistance

// apply air resistance
mParticles[i].dx = mParticles[i].dx - (mParticles[i].dx*AIR_RESISTANCE*timeFrame);
mParticles[i].dy = mParticles[i].dy - (mParticles[i].dy*AIR_RESISTANCE*timeFrame);
mParticles[i].dz = mParticles[i].dz - (mParticles[i].dz*AIR_RESISTANCE*timeFrame);

There are two demos in this release. The first just cycles a pyro. In this one, not only did each particle have a time to live, but it needed a second respawn timer. In the second demo, you touch the screen to set off a particle system. The code for that one is limited to 40 touches, so there is a set array of 40 systems. A better approach is to use a collection, so you can add pyro systems as they are needed. The key here is to remove them when all particles in the system have expired.

Another future improvement is to change the initial velocity direction to be a random point on a sphere. You can notice that the random direction and velocity vector is a point within a cube, so the particle system looks square. What should be done is a random direction is calculated from the surface of a sphere, and then that vector is scaled by a random velocity.

The triangles are starting to lose their looks. Not bad at a distance but close up they stand out. It might be time to start texture mapping the triangles to something more realistic. If we add the right GL blending, we could give the impression that a high concentration of particles would also mean a brighter color if their colors are additive.

The first touch for the pyro appears small. This is because the time between the init and the first frame is large, so the particle velocity gets reduced significantly. What should be done here is there should be more updates done at smaller time frames. So if a large frame rate appears, break it up into smaller time slices and simulate those (so multiple updates per frame).

Maybe for the next release I’ll try and get those features added. As always, the code can be found on Google Code. The demo is also available on the Android Market, search for “Particle System” or scan the QR code below

Android Market Downloads June 2010

It’s a new month, I figure a good time to give an update on where the downloads are at. The figures are surprising to say the least

Nearly 800 downloads between the two apps. I haven’t confirmed but I think a download is also counted every time an existing install updates to the new version. So if you are releasing new versions frequently, your downloads would compound quite quickly. The active installs hasn’t changed much over time, sticking at 35%. And for some reason, my Particle System Tutorial icon is darker than the real one on the app, need to find out how to update that.

Box2d Demo v1.2

Finally got around to updating the Box2d demo to version 1.2, while I wait for my Froyo update from Google (hurry up!). There is so much functionality in Box2d, I’m barely scratching the surface of what can be simulated. So what’s changed in the new version?

  • Uses the menu to change objects to add to the scene
  • Allows the user to edit the scene by toggling the edit mode and drawing static lines that the dynamic objects can hit.
  • Has a link to Bay Nine Studios from the menu.

I think this is going to be the last update for the Box2d demo in a while. It’s a fun api to play around with but I really need to get back to other stuff. With the Froyo (Android 2.2) update coming, I’m going to be spending more time learning the new features of OpenGL ES 2.0. In particular, I’d like to learn more about vertex and fragment shaders. This is going to be an exciting time in Android game development, as the platform is becoming a viable competitor to the iPhone OS.

Particle System Tutorial on Android Part 5

You can notice from the first couple of fountains that all the particles get generated at the start and then spawn after the time to live is up. This results in a massive blast at the start and then things start to get more evenly distributed. In this tutorial, the particles will get slowly released in to the system. This is actually fairly easy to do with only a new variable called activeParticles (set at zero) and few lines of code in the update method in ParticleSystem.java

// add the particles slowly
if (activeParticles < PARTICLECOUNT)
{
    // calculate how many particles per frame.  I have set
    // the particles per second at 100
    int addParticleCount = new Float(100f * timeFrame).intValue();
    // always be adding at least one particle
    if (addParticleCount < 1)
    {
    	addParticleCount = 1;
    }
    activeParticles = activeParticles + addParticleCount;
    if (activeParticles > PARTICLECOUNT)
    {
    	activeParticles = PARTICLECOUNT;
    }
}

The other feature added is a bounce when the particles hit the FLOOR. So instead of just stopping all speeds, we keep the x and y speeds intact and invert the Z speed. As well, cut the Z speed in half to have the particle not bounce as high as the previous height. The time to live can be extended to give that rolling look.

if (mParticles[i].z <= FLOOR)
{
    mParticles[i].z = FLOOR;
    // invert the Z speed and cut it in half so the bounce is not as high
    mParticles[i].dz = mParticles[i].dz * -.5f;
}

Again the code can be found on Google Code. The demo is also available on the Android Market, search for "Particle System" or scan the QR code below

Android Market Downloads So Far

So, it’s been a couple of weeks since I published my first app on the market. I thought it would be good to show how the downloads and retention have been going.

Looking good (at least for a couple of tech demos). It’s very useful that it shows how much your apps get uninstalled. In these cases, I can understand why people do not want them on their phones after trying them once. Unfortunately, Canadians can only buy apps from the market, we cannot sell apps in the market. Hopefully this will change soon, I’d like to try out selling an app and get an idea of what is involved in doing that. Of course the apps have to be more useful than these ones.