I’ve been working on a new OpenGL program. Didn’t finish the last one as I decided I wanted to make a portable application (ie, so I can port it to Windows, and possibly even DirectX one day). Only a touch of Objective-C/Cocoa to set up the windowing and use some nice OS specific functions (such as Cocoa automatically being able to decode PNG files), most of it is written in C++

So I’ve been playing around with VBO’s (Vertex Buffer Objects) and FBO’s (Frame Buffer Objects) which I had been doing in the previous program, but it turns out I was doing it slightly wrong. So now that it’s all working correctly I have a bit of an app going.

Currently it pretty much only loads Obj models (a simple ASCII based format), but most 3D applications will export this.

Underneath there is a lot going on. It has:-

• Obj Model loading/rendering code
  • Works in both VBO mode and Immediate mode for debugging purposes
• Quake style console (not shown)
  • Press ~ to bring it down, and you can type commands, register/change variables (currently moving the camera around is done like this, as is model loading)
• Texture manager
  • I can keep track and list all the used textures
• Shader manager
  • Like the texture manager, to keep track of it all
• Font manager
  • Rendering fonts/strings to the screen
  • Using a single font texture “atlas” for all the characters, basically one big texture that slides its position around on a triangle fan (or quad if you prefer to think of it that way) to only show the correct character entirely done in GLSL (GL Shader Language – basically programming directly on the graphics card)
• Particle renderer (not shown)

Next things I’d like to do are is have a model manager to allocate one (or more) large VBO on the card to hold lots of smaller models and index them within the VBO, more shaders – I’d really love to try some SSAO (Screen Space Ambient Occlusion – basically simulating the way that indirect light will still light and shadow things) and deferred lighting/shadowing and write a full GUI for it for things like menus, combo boxes, buttons, etc.

I’m sure I’ll come up with a lot more, possibly turning it into some type of game engine one day.

Here’s a screenshot of what I have so far.

It doesn’t look like much, but there’s a lot of work going on there.

The colours you can see on the model (which I actually made myself) are what’s known as a normal map. It’s the way lighting is calculated on 3D models.

Unfortunately there’s a couple of problems with this model.

1. The first one that stands out is that it’s missing parts. When I exported the model, I accidentally left some of the parts as Sub-D and NURBS surfaces, which can’t be directly rendered by my renderer (or even represented in the Obj file). I’ve actually exported what I think is a proper model, just haven’t copied the file onto my laptop yet.
2. The other one that isn’t so obvious unless you know what you’re looking at. With normal maps, we represent the normal as a colour. Basically Red = X, Green = Y and Blue = Z. Now a triangle (which is what the model is made up of) that is facing the camera should typically have a blueish tinge (like the bottom of the car does), but as you can see, the door is a green/orange colour. What is happening is that many of the triangle are actually facing the wrong way. Oops. Will have to fix that up

One thing that may stick out in that screenshot too (at least if you click it and view it in full size) is that the frame rate is only 20FPS. Basically there are three reasons for this:-

1. The first one is that I’m only rendering a frame once a millisecond (which works out to be around 40FPS) rather than maxing it out at the fastest possible rate
2. Next it’s only a debug build, so the compiler hasn’t optimised the code
3. Finally the model is 300,000 triangles, so in that alone, we’re doing around about 6,000,000 triangles per second (triangles * fps) , which that said isn’t fantastic (I am on a laptop graphics card though), but due to the way I’m calling the code, it will be a direct division of 40… ie, 40, 20, 10, etc.

So next post, I’ll hopefully show a proper render of the model. Maybe even throw in a quick tutorial on VBO’s (which are really quite easy when you get your head around them).

Ok, so I figured I’d jot down my thoughts on Apple’s announcements at WWDC09. Normally I’d just chuck this on Twitter, but I don’t think 140 characters isn’t enough

iPhone 3G S
I like that it’s got a speed upgrade and a dedicated 3D processor (I’m actually a little jealous of this one), but that’s about it really (for me anyway).

I’m a bit meh about the Magnometer (compass). I’m sure I’ll eat my words here when a killer app requires it.

The camera doesn’t really bother me. 3MP with crappy optics isn’t going to do much. I hardly use mine anyway, I’d much prefer to use a dedicated camera. Video could be nice, but once again, if I wanted video, I’d use a dedicated one.

Voice control, while a very nice technology, it’s not really practical. You can’t really use it in public without annoying people, and I don’t know about you, but when I’m by myself, I feel a bit stupid talking to nothingness.

All of the rest of the features are included in the 3.0 software update (which I’m actually quite excited about) that is coming out worldwide on the 17th of June (Australia included, their press release was actually incorrect).

MacBook Pro
This one is easy. I am so glad that I bought mine last year! At the same price point that I paid (bottom level 15″ MacBook Pro), you now get a downgraded machine
Pros:-

• Faster CPU (does CPU speed really make much difference these days?)
• More memory (Pretty cheap to upgrade RAM too)
• Longer Battery life (5 hours is enough for me, but this is a nice bonus)

Cons:-

• Only a GeForce 9400 integrated graphics card. This one is a dealbreaker for me. The 9600, while not the best card on the market, it’s pretty good for a laptop card (especially with Snow Leopard using OpenCL – more below)
• No Express Card slot. It’s been replaced with an SD slot (which you could have had with an SD Express Card reader).
• Non removable battery. Not a dealbreaker (how many people actually replace their batteries rather than buying a new laptop), but I think this is a bad way to go.

Snow Leopard
Out in September. This is going to be a fantastic upgrade. Full 64bit operating system. The current OS is 32bit with 64bit extensions (basically to allow addressing of over 4Gb of system memory – ie. This doesn’t just include installed RAM). Going to full 64bit should speed things up quite a bit.

Installation time has gone from 1 hour down to 15min which is a nice change, it’s not a big change in the scheme of things (you only do this once every now and again – much less on the Mac than Windows).

It’s smaller. This one surprised me. I’m currently hearing that the installed size is about 6gb smaller. I guess this is due to not having to have the PowerPC binaries in their apps anymore (Snow Leopard is Intel only). This is a very nice change that a newer operating system is faster and smaller than the one it’s upgrading.

OpenCL. Most people really don’t care about this one, but this is going to give some major performance increases for anyone with a GeForce 8600 or better. Basically your Dual Core system just got a whole lot more cores added to it (think hundreds of slower cores). Now while this won’t double performance in most cases, you will see some major speed-ups.

One that I don’t know which way it’s going (if anyone knows, let me know). OpenGL. Is Apple going to have OpenGL 3.1 (and GLSL 1.3) on this, or will it still be stuck back at OpenGL 2? I’d love to start playing around with 3.1 (some quite major changes) and I’m sure more apps/games would use this if available.

Safari 4
Meh.

Ok, so this is what I’ve been working on recently. I know there’s a few of these out there, but I’m more doing this to learn shaders for myself (along with VBO’s – Vertex Buffer Objects – and FBO’s – Frame Buffer Objects) along with Objective-C/Mac programming.

So what you’re seeing there is a slight Gaussian blur on the texture itself and a radial blur on the whole scene itself (using an FBO mapped onto a Quad that fills the screen).

As you can see on the right, it has a built in editor. It will eventually have syntax highlighting, but I had to disable that temporarily as it was causing some issues.

An interesting problem I came across at work today (well, came across on Friday, solved today).  Basically I needed to get two fonts of different sizes (only containing numbers) to line up at the top on one side, and the bottom on another.

Problem is that the Java labels were taking into account the Ascenders and Descenders which were different heights due to the fonts being different sizes.

I’ve made a bit of a pic that describes all the info you can get from the Java FontMetrics class.

Basically, because I was only using numbers, they effectively were the ‘a’ in this picture (there were ascent’s above them)

So what I needed to do was calculate the difference between the top of the characters and the top of the area in both the sizes.  Problem is that you can’t easily just get the height of the font.  Ascent is given by FontMetrics.getAscent(), Decents similar, Leading same again.  So what I ended up having to do was get the actual glyph of the character, and subtract that from ascent size (which as you can see in the picture, comes from the baseline – shown in red).

Code follows (m_fntBig and m_fntSmall are the large and small font member variables):-

// Hack to get the font metrics
java.awt.image.BufferedImage image = new java.awt.image.BufferedImage(2,2,java.awt.image.BufferedImage.TYPE_INT_ARGB);
Graphics2D g2 = image.createGraphics();
FontMetrics fmBig = g2.getFontMetrics(m_fntBig);
FontMetrics fmSmall = g2.getFontMetrics(m_fntSmall);
 
// Get the size of a 0 (strangely enough you can't do this with Font Metrics)
GlyphVector gvSmall = m_fntSmall.createGlyphVector(fmSmall.getFontRenderContext(), "0");
int nGlyphSmallHeight = gvSmall.getGlyphPixelBounds(0, null, 0, 0).height;
GlyphVector gvBig = m_fntBig.createGlyphVector(fmSmall.getFontRenderContext(), "0");
int nGlyphBigHeight = gvBig.getGlyphPixelBounds(0, null, 0, 0).height;
 
int nTopOffset = (fmBig.getMaxAscent() - nGlyphBigHeight) - (fmSmall.getMaxAscent() - nGlyphSmallHeight);

So the code above basically gives us the offsets we need to use to line up the top.

Unfortunately, I did a stupid thing, and to line up the bottoms, I was just calculating the difference in the descenders, which as you can see in my picture above, is wrong. We need to include the leading space too (interestingly it’s pronounced Ledding and comes from the amount of Lead used between the lines in printing presses – Wikipedia has some great info on it).

So to calculate the bottom difference we get:-

int nBottomOffset =  (fmBig.getMaxDescent() + fmBig.getLeading()) - (fmSmall.getMaxDescent() + fmSmall.getLeading());

Now we have the offsets for both the top and bottom, and we can now move our labels around as needed (in my case, I had 3 labels within a SpringLayout) and will work with most fonts and sizes (as long as the numbers are all the same height, which is a reasonable assumption in a financial product).

If you actually come to my site rather than reading the RSS feed, you’ll notice that I have a new theme on here.

I actually won this theme from “From The Couch” which also forced me to sign up on Twitter (you should see the details on the right). It’s a limited edition theme in which only 40 (actually I think it ended up being 43) were given away. I’m not using all the features of it (yet) but I like it. I think it looks pretty spiffy!

One thing I do still need to do though is get a proper logo to chuck in the corner at the top. Not 100% sure what I’m going to do with it, but might have a bit of a play around with something at lunchtime.

On another note:- I’ve got another new best time in to work. I’ve got it down below 43 minutes now (42:49 to be exact). I’ve got a feeling that this may stick until I get SPD’s for my bike (coming when Mr Rudd gives me our “economic stimulus package”).