I’ve continued to work on skinning in Unity3D and I’ve replaced the CPU skinning with GPU skinning. This means I can do my vertex morphing on the GPU too. It took a while to get it working but it’s quite a bit faster now. I also go shadows working properly. I’m going to make a tutorial video of this soon explaining how it works for anyone interested in this technique.
The continuing adventures of Charlie Dog and his blog...
Wow. it’s been a long time since I posted. Hopefully this will be the start of series. To kick things off here is a link to a movie demoing some of the stuff I am working on at the moment in my spare time. All the stuff you see in the video is generated using procedural techniques. This includes meshes, animations and behaviours. I’m hoping to use these creatures in my cave game.
I’ve just being playing with shaders for a few years now but I’ve only just forced myself to get to grips with tessellation and I thought I’d write about my experiences. I’m splitting this over a couple of blogs because there is a lot to write about.
There are a lot of really good tutorials on tessellation so I’m not going to go into detail about the implementation. The above link the Little Grasshopper’s page is excellent and I’d recommend reading all the stuff in the blog if you have time, it’s all pretty damn excellent
In this post I’m going to talk about my experiences and what I got out of my experiments. My objective was to apply tessellation principles to my cave creation algorithm which I’ve talked about in earlier posts. As you may recall I build the mesh for a cave system procedurally and then render it in the normal way. I had a lot of success replacing the most processor intensive operations with OpenCL (20 times improvement in speed!) but an alternative way to reduce mesh build times would be to generate a lower resolution resolution mesh and tessellate in real-time. The basic idea is that we push less geometry into the render pipeline, which speeds up the building of geometry and the time take to get it into the pipe, but spend longer rendering it because the shader code is more complex. We’d expect to get a drop in frame rate by adding tesellation into the pipe, but how much? That’s the sort of question which doesn’t get answered in most reports on the subject, and I think that’s one of the reasons I was suspicious about it.
My initial experience was positive, I worked through the examples given in the link above, and a few other simple examples, and it all worked fine. Tessellating a isohedron to make a sphere is easy, we simply tessellate each triangular patch then push the new vertices out along the normal(which points away from the sphere center of course) . The next step is to tessellate none regular meshes, that’s when things become more complex. The technique I use is Point Normal(PN) Triangles, this just means that each of our patches is a triangle specified as a triple of coordinate, normal pairs. Just like we normally represent a triangle when rendering which is convenient! What we do is use the normals to control the shape of the surface which is created after the tessellation. A choice of two techniques are available, Bezier patch and Phong interpolation. As before I’m not going into details in this post but this excellent blog describes the technique in detail. Jonathon Dupuy blog is another excellent source of information for all things graphics related.
I implemented both phong and bezier and in my tests phong is a bit faster and gave better results. It’s difficult to be precise about this, as it’s difficult to accurately measure how much GPU time is spent doing the the interpolation, but, in my tests phong gave a frame rate of 50FPS compared to Bezier, 51 FPS, which might not sound substantial but it all adds up!).
The main problem though is that you can’t just tessellate every patch to the same level, well you could but that would be very slot. Instead we need to adjust the tessellation level based on some sort of heuristic, distance from camera say. This is where we talk a bit more about implementation. Unlike the other shaders in the GPU pipeline, tessellation is done in two seperate programmable stages, the control shader, the evaluation shader. It’s the control shader which sets up the level of tessellation and it’s here that we need our code to control the level of detail or LOD as it’s more often known. These days we don’t usually bother with LOD for meshes in games, it’s typically not worth it as geometry is pretty cheap to process, but for tessellation we do need LOD as otherwise it would be too expensive. The main problem I had is with “tearing” and fixed it with the help of this guys article . Joachim is another great source of information and makes the excellent shader forge for unity. I refined the algorithm a bit because otherwise it tends to reduce the tessellation level too much in the near field and not enough in the background.
My paper goes into more detail about this.
The following image shows an example of what happens when you don’t address the tearing issue:
So that’s the basic of tessellation. What I found is that tessellation reduces frame rate by about 30% but there is potential for quite a bit better visual quality if we combine the above technique with a displacement map. But I’ll talk about that later. A quick graph below though which shows the relative performance of different hardware. As can be seen NVidia tends to outperform ATI, which one would expect due to NVIDIA spending a lot more on tesselation hardware research than ATI.
The main issue I encountered was finding a good, computationally tractable, way to recalculate the normals after displacement mapping occurs and I’m still looking into this. Hopefully by the time I make my next post I’ll have a better solution than the one I currently have.
I’ve read quite a few text books as part of my Masters and now that it’s finished I’m getting withdrawal symptoms! So I’ve taken to reading text books, “for fun”. Two books are in my reading list at the moment and both are interesting for game developers.
The first book is Behavioral Mathematics for Game AI. I should straight away say that this isn’t a deeply technical book for people looking for insight into leading edge techniques. It’s more of a general introduction to the subject and spends quite a bit of time discussing general AI problems as well. But it is easy to read and presents the most important aspects of this subject in an interesting and accessible way. There are many very technical books on the subject of AI, (such as this one! which is at the same time very informative and frustrating to read), for those who care to look and this book is much easier to read. It probable tells you everything you need to get started modelling behavior in games too. Behavioral modelling is just one aspect of AI and although as I previously stated the author does stray into other areas of AI the focus is on that. Readers new to AI in games will need to compliment this book with other more general AI books (of which there are many to chose from). Behavioral modelling is the crux of the problem for interesting AI behaviors though so I’d recommend this book if you are about to embark on writing slightly more advanced AI for NPC in your game.
The other book I’ve been reading is Computational Geometry Algorithms and Applications . This is a great source book for solving the more complex mathematical problems we encounter in games development but it’s also an interesting read when one starts at the beginning and work through it. The examples given are interesting but the maths rapidly becomes quite complex so it’s not for everyone. I’ve implemented a few of the algorithms in the book and it would be an excellent exercise to go through the whole book implementing everything and working through the examples. One thing I find in computer game development is that many of the people I encounter are scared of maths or have poor maths skills. If you want to stand out from the crowd in games, learning good math skills are a great way to do it. Learning them is harder than learning how to write scripting in Unity but you get what you pay for as they say!
Console development is now as easy as PC, but it’s a double edged sword…
As part of my teaching I get access to some pretty cool resources and this now includes PS4 dev kits! I’ve spent the last few days setting one up for the students to use. It turns out it’s pretty simple to get working. As with most modern devkits one simply plugs it into the network then connected remotely from a PC. That way several people in a team can share the same expensive bit of kit. I started by testing the native code demos and they worked fine then we set Unity3D up to work with it. Ps4 development using Unity is incredibly easy, assuming you have the PS4 plugin that is (it’s impossible without it) and is simply a matter of selecting PS4 as the hardware platform and hitting build and run. Of the student projects I tested so far the ones using the standard Unity controller input worked first time but the ones using XInput failed to run at all.
So that’s great. it means that it’s now really easy to get your indie games running on PS4, assuming you have a devkit that is. Sony, Microsoft and Nintendo, are pretty good in that regards too, giving out SDK licenses to indie developers who make a reasonable case that they need it. Getting the kits is a bit tougher but I know of several indie’s who got them from Sony, on a long term loan, as part of Sony’s indie scheme.
But I think there is a downside to this and I must emphasize that this is my opinion only and doesn’t reflect the views of the AIE or anyone else I am connected with. The problem is that in the old days console development was hard. it meant you needed a lot of expertise and you needed to invest a lot of effort to get something up on a PS1 for example, but that acted as a gate keeper to keep the number of titles down. It also meant that big studios where hesitant to develop for the smaller platforms or sometimes didn’t port to even the big platforms if they didn’t think the sales where going to justify the effort involved. This meant that there where openings for smaller developers to do to the porting or to produce original titles. Unfortunately, with the democratization of game development and platforms such as Unity3d and Unreal, that’s all changed. By following a few simple development rules and clicking an appropriate button you can deploy your same game for XBox One, PS4, PC and WiU from Unity, and with a bit of extra work include IOS, Android and Windows Phone too. A quick perusal of the online stores for all these devices shows how damaging this is for the industry because, low and behold, all the same titles are there on all the formats. Occasionally Sony will sign someone up for an exclusive but usually it’s cross platform within a year. That’s a problem for all of us. it makes it easier to get your products out there, but it is much harder to stand out from the crowd now.
Game Review: Spectromancer
It’s been a while since I posted a game review so I thought I’d talk about Spectromancer today. This is not a new game, it’s been out a few years and is actually a sequel to Alexey Stankevich’s game Astral Tournament, which I absolutely loved but which is no longer available (it had rather “unique” art which I think the author made but that was part of it’s charm). There is a Spectromancer 2 out but I couldn’t seem to find the links in the turgid morass which passes for online games forums these days.
Anyway the reason I’m writing about this game is that I recently downloaded it again and showed it to my son, who loves it. He’s just getting into Magic the Gathering, which I assume we’ve all heard off… Spectromancer is quite similar but I think the mechanics are a bit better and certainly lend themselves better to a computer game. To very quickly sum the game up it’s a turn based card game where you try to destroy your opponent by whittling down his hit points. You attack by putting cards in slots and defend by putting cards in opposing slots. What makes the game a bit different from Magic is the way Mana accumulates and is managed and that makes for really interesting game play. Cards have the usual range of special abilities and there are creatures and spells. In the full game there is a rather nice campaign with some simple deck progression built in.
It’s great to see my Son enjoying this game and I heartily recommend it to anyone who enjoys turn based card games.
GCAP and paper
I presented at GCAP a few weeks back and I thought I’d do a follow up. GCAP was great this year with much bigger attendance than I remember from previous years and a good selection of talks that where generally of a high standard (at least the ones I saw). I thought my presentation went well. I said everything I wanted to say and my demos worked properly, people even laughed at my jokes, which was nice of them :).
The talk I did was on procedural generation of cave meshes and as I mentioned at the talk I’ve produced a fairly detailed report as part of my Uni masters course which is now available online from here
The paper covers quite a bit of stuff. From the algorithm I use to generate the caves through to a fairly indepth survey of GPGPU techniques and tessellation. The most exciting thing I found was that performance gains from using OpenCL is excellent. the following graph compares CPU performance against OpenCL performance for the very parts of the cave creation algorithm.
As can be seen when using the CPU the mesh creation part of the algorithm was by far the biggest processing time hog, but after GPU acceleration it was the least significant. In fact the new most significant is the creation of normals which also would seem to be a prime candidate for GPU acceleration so that’s probably what I’ll tackle next. I also compare various GPU cards to see how performance varied across hardware and the results where very interesting:
As can be seen even old cards offer a big advantage over current generation CPU (I tested against an I7).
The results from Tessellation where less conclusive. it works well but FPS was quite a bit poorer. I’ll probably talk about that later
I am presenting at GCAP 2015
I’m very excited to be one of the speakers at this years GCAP conference in Melbourne.
I’m presenting a talk on the procedural cave creation algorithm I’ve been developing for a few years. The emphasis is on how I am accelerating the creation time using OpenCL and Tessellation shaders. I’m excited to be able to show of my work at last.
I’m almost finished with my Comp Sci Masters! For my last course I picked computer graphics, mostly because I thought it would be straightforward but also because I knew I’d pick up some new knowledge. I’ve found that no matter how much I think I know there is always something more to learn. In the last tutorial we implemented a ray tracer. I’ve never done this before so it was new to me and I thoroughly enjoyed doing it. I wish I had a bit more time to spend on it but here is a screen shot of the result demonstrating basic lighting, shadows and reflection.
Something else that I do in my spare time:
Anthony and Victoria overcome their stage fright to perform a stunning Mambo routine.