A guide to setting up C++ Lua bindings with Swig in Xcode4

0

Having written Lua bindings before, I decided it was time to explore more automated options. Binding for Lua isn’t too tough but as projects grow more complex in syntax and dependencies, I decided that letting a tool do it for me is just fine. I spent an evening getting a test for Swig setup in Xcode4 and nothing I found online was exactly spot on for me, so here it is.

Swig is a command line tool for compiling files of a certain form into C or C++ binding files. It binds to several languages, check it out here.

Lua is a fast, established scripting language commonly used for games due to its speed and flexibility. There are many arguments (often in my office) about which scripting language to use as hardware improves. For the scope of my current projects however, Lua is perfect. Choice made.

1. Setup. Install Swig and Lua. I advise using something like Homebrew / Macports / Fink. My current preference is for Homebrew. It is more modern and seems cleaner to use to me. But the end result is the same. You just need header files for lua in a known location (eg. /usr/local/include). Homebrew will set this up for you with symlinks as well as putting the dynamic libraries in /usr/local/lib/. The relevant binaries for command line stuff will also be done. If you want to look into building this stuff then it isn’t to tricky. Lua comes with a makefile and you just type ‘make macosx’ then sudo copy the files where you need them. Honestly though, use homebrew. Then it’s as easy as:  brew install lua && brew install swig

It can be found here

2. Headers. Start a new Xcode project. We’re aiming to bind C++ and we’re just getting things setup so I’ll choose ‘command line tool’. We need to get Xcode recognising our header files and libraries. If you used homebrew then they’ll be under /usr/local/… most likely. Where they are, you’ll need to click the project icon on the top of the file tree for you project. Go to “Build Settings” in the main window and make sure your mode is set to “All” NOT “Basic”.

Scroll down to the “Search Paths” section. You’ll see 3 search paths. Framework, header and library. Frameworks are a combination of dynamic libraries and headers (and other resources). In our case, we havent compiled Lua as a framework. Homebrew gives us the headers, dynamic libraries (dylib) and binary files for command line stuff. So we need to add the right paths to “Header Search Paths”. Remember where you installed them (/usr/local/include for me).

3. Linking. With the “Library Search Paths”, we also need to tell xcode where to look. With this step however, we will also need to tell our program to link against the library. This is because we need to know where to look but also what to link at runtime. This way we will actually be able to find all our fancy lua functions that we want to use. Simple go to your target on the left hand column of the build settings. Choose “Build Phase”. Open the “Link Binary with Libraries” and hit the plus button. Then navigate to your “liblua.dylib”. (Hit Shift+Cmd+G to get terminal-navigation in finder)

Once you have selected the lua library, Xcode will take care of the search paths too. You’re all set!

4. Test. Now you’re ready to test stuff out. As always, test in increments. Does Lua work? 

- Firstly create a file called “test.lua” or similar. With this in it  print("Hello Lua!")

- Then use the following as you main.cpp

- Hit Cmd+R to run you program and you should see “Hello Lua” in the console output.

5. Swig. Now for the meat in the sandwich. I’m going to bind the following class to Lua.

I’m keeping it super simple for now, I just want to get it set up and understand my workflow for Swig/Lua. The implementation is in a cpp file and I’ll leave you to fill that in, but make sure you have actually defined these symbols!

You can then create a ‘swig’ file called “TestModule.i”. When you do this, Xcode will probably set the file to compile. Go to your target build settings and make sure it isn’t in the “Compile Sources” list.

I’ve seen a muddle of reports on how this file should look. But here is the cleanest thing that worked for me.

Make sure you use both the swig and C includes. Without the latter, nothing will be bound whatsoever.

6 Final Test! Here is the check list for swig.

- You have you simple C++ class for binding. This include it’s header and .cpp implementation.

- You have you Swig file ready

- Run ‘swig -c++ -lua TestModule.i’ from the command line. This makes a TestModule_wrap.cxx file.

- Add the above generate file to your project. We need that to be compiled and linked for our bindings to work

- Change main.cpp to look like this:

- Change test.lua to

- Hit Cmd+R and you should see:

BOOOOOOOM! You’re all set.

Maybe you’re thinking ‘bu..b..but Pete! It didn’t work.’ I often read guides and get the same feeling. If this is the case, Google is your friend. If Google fails you however, get in touch and I’ll try to help if I have time.

Good luck. Have fun.

GSD Project 3: Breakin and the pitfalls of rushing code

0

A significant part of ‘Getting Stuff Done’ has been to write code quickly. This is not a prerequisite in general, for doing things, however, for me it has been important. I do not want to find excuses for not finishing projects or procrastination. With this in mind I launched into my latest project, a simple variant of ‘Breakout’ called ‘Breakin’. The idea was simple to build on the code written for my last project and see how quickly I could write the application code on top of the ‘engine’ I’ve started to piece together. It started out good, got bad and ended up ugly.

The Bad

I started out well. I re-factored some component code to be more generic, added a simple template class for a Grid data structure and a new sub system called ‘CollisionEngine’. With each of these improvements, my intentions were pure (of course). When it came to using them together with a new Entity type, things unfortunately fell apart. The reason for this is two fold:

  1. The engine code was written quickly and tested ‘on the fly’ (bad bad bad)
  2. The structure was not designed as much as it was stuck together with tape (see above)

Add to these a couple of ill-advised late night coding (hacking) sessions and I had a problem on my hands. I had progressed from the odd programming faux-pas to a sinful mess of pointers and nightmares. I dug about in the code and see the errors, the causes of memory slicing, shallow copying and other such badness. So I know what needs to be fixed and what I left out in my haste (and what never to leave out again). Having come quite far with the implementation, and wanting to ‘ship it’ I decided to work around it until the next project. Sometimes you just have to find a way to progress.

The Ugly

Workarounds are sloppy. In a production environment they are often, unfortunately necessary. Given that one of the aims of ‘Getting Stuff Done’ is to set deadlines, I had little choice. The result however, is a rushed body of code that just about functions and needs to be left to die a quiet death. But this is okay. When I started the project I had no plans to design a lovely neat system. As I progressed, the developer in me couldn’t ignore the code repetition and inefficiencies of hacking out 2D games. So I cobbled together a small system to help me out. I was happy to hack this and learn how far I could go. I dressed the mutton-engine up as a lamb-engine and made use of it. The key to the next step is to take what’s good about the code and roll it into a new system that is more robust and considered.

The Good

While I gained a tonne of knowledge from the flaws in my old code, this project did yield some important revelations from the implementation itself.

Firstly, I was able to implement a handy little Grid template class. This is a data structure that allows access to objects based on a cell index. This cell index also has mappings to world and object space. My implementation is super simple and will change and grow, but it was written in half an hour and served me well for project 3. Below is a snippet of the class, some of the implementation detail has been left out, but you get the idea.

Secondly, I implemented a CollisionEngine subsystem. Like the Renderer introduced in Project 2, this is a singleton instance that the Engine will update separately to the game logic. The actual implementation is not final at all, it will probably undergo a complete face-lift. The principals explored during its implementation however, have been revealing. Detecting collisions and responding to them correctly and at the right point in the update loop is key. When iterating over all of our collision bodies, we don’t want to respond to this collision and invalidate the iterator. If you do this, you’re going to have a bad time.

What Now?

So where does this leave things? Well, Breakin is a much less complete game than my first two projects and it has left the code base in somewhat of a limbo. So now I plan on doing a ‘Getting Stuff Done Mini-Project’. The aim here is to re-construct the engine code in a more robust fashion. In addition to this I want to reduce dependencies on SFML. Ultimately I just need to design what I have properly, with good, simple interfaces.

So that’s it. A small update but a key one. While work has been busy and the project tricky, it’s key to keep my goals clear and deadlines tight.

When the code is re-written I’ll slap it on github. As always get in touch and let me know your thoughts if you have any.

 

Breakin from Peter Smith on Vimeo.

GSD Project 2: Pong for Pongs sake and Entity-Component Design

8

For my next project I chose Pong and this ‘Getting Stuff Done’ task was a little more code focused…I’ll explain why in a second. For now let’s review the goals from last time: Make a fun game. Write nice, clean, well thought out code. Have a complete application to share. Set deadlines and work to them. Be proud of what I make. Post about the project and get feedback

After completing Project One I decided to review these goals slightly and here’s why. Choosing easy games to start with allows me a certain degree of confidence that I will see the project through, which in itself is great. I have deadlines, and work to them. I am proud of what I make and I get some feedback. The main loose end for me, however, was the code.

Like most of the code that I write during this series, some will be good and some will be… less good. With Project One, this was certainly the case. The main problem, however was that very little of the code was reusable. Having got some general feedback, I wanted to make sure that my design allowed for cleaner higher level systems in the future.

So why Pong? Pong is one of the easiest games to implement. I had the basics working in a couple of hours. This was perfect, and allowed me to spend time on some interesting design problems that will make my life a lot easier going forward. With a more reusable code base, bigger projects in the future will seem smaller. This echoes the main concept of ‘Getting Stuff Done’, start simple and build complexity. 

So my new goals:

  • Make a fun game
  • Make a nice, clean, reusable code base
  • Be mindful of competing demands between point 1 + 2
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

I won’t go into the game implementation for this one, there will be more of that in future posts. I will however, do a brief overview of the key parts of the code.

Entity-component

EC_Monolithic

The above diagram shows a naive implementation of a typical game object. While for Tetris or Pong this may be sufficient, it quickly becomes a trouble to maintain. Object grow vast and update loops become impossible to read, this is something I picked up even when implementing Tetris. While the separate parts of the object may be encapsulated in the whole there are a some drawbacks, not least:

  1. Configuring similar objects requires complete re-coding
  2. Each of the constituent parts must be developed as part of one monolithic class
  3. The code quickly becomes hard to maintain as we lose track of the interactions between elements in the game loop

To simplify this further, we could break things down in the class and adopt a more functional approach.

EC_Functional

Unfortunately, while this may tidy things up a bit, it still doesn’t abstract different logical blocks away from the particular object.

Enter the design pattern, Entity-Component. The diagram below shows the next iteration of our simple game object. (It’s worth noting that in practice we would split the ‘pos’ attribute further as is it common in all game objects)

EC_Finalish

And below in it’s final, encapsulated form.

EC_Final

In this system, the components are separate classes of object that, through a common interface are still able to work together. This allows us to develop each component individually whilst still being able to rely on the fidelity of the objects other components.

The key to all this is messages. The only thing that the Render Component needs to know about the Movement Component is when it moves. So all we have to do is give the object (entity) some mechanism for handing messages between its components.

EC_Broadcast

The diagram above shows this in action. We provide each component with a pointer to its ‘owner’. We are then able to broadcast messages to all the other components via the entity. When our position changes, we can hand a “Point Moved” message from the Move Component to the Render Component. The render component can read this message, process it and will in-turn broadcast a “Shape Moved” message.

This does come with a small overhead of function calls, but if done correctly will result in a lot more good than harm. The biggest challenge here is how to send data with the message. I experimented with inheriting a BaseMessageData class, and using dynamic_cast (avoid!) for particular types of message. In the end though, I simply define a Message like so:

This allows us to determine type without using runtime type information (RTTI). This works nicely. No matter what we do the components will need to have knowledge of the implementation of particular message data. What this class allows is a simple way to get the data as the type you need and to start using it. It probably isn’t the best way, but for now I like it.

I used something similar for defining a SimpleEvent class.

The key difference in these two things is:

  • Messages handle internal component communication of an entity
  • Events are game-wide things that occur and effect the game state (e.g. Point Scored)

With the simple event implementation I am easily able to grab an instance of the event subsystem and dispatch events. All I need to do to catch them is register a class that implements the following SimpleEventListener interface.

I am convinced that there are better ways to do much of these things, but these implementation serve my architectural needs. If you’ve got suggestions, let me know. I always want to learn from the collective wisdom of other experienced code-monkeys!

The last thing worth mentioning is the role of engine subsystems. Whilst an entity is a type of subsystem with knowledge of all of it’s parts, entities cannot live in isolation. The game must know how to control them of course, but other parts of the engine need to know about them too. For example, in my implementation a Render Component has knowledge of how to talk to the Renderer (a singleton object). In the future, as I improve the code, interactions will work through a singleton InteractionEngine (in lieu of a full physics engine). It is clarifying concepts like these that will allow clean, modularised code going forward. This way my Engine class can simply get all the subsystems going and allow them to talk to each other as the game runs.

pong_screen

Check out the code here, as always feedback is most welcome. Getting your thoughts is always great. If you would like me to explain any concepts or terms further don’t hesitate to ask!

Project 3 incoming, good luck!

Game download (Mac OSX 10.8.2)

GSD: Project 1- Tetris Variant

0

For my first mini-project of 2013 I chose Tetris. I will be using C++ and SFML for all upcoming projects. To recap my last post; here were my aims going into it.

Getting Stuff Done, checklist:

  • Make a fun game
  • Write nice, clean, well thought out code
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

A fun game
Tetris is an old school 2D arcade game originally credited to Alexey Pajitnov (see the wiki). I’m going to assume you’ve heard of it. I take no credit for the basic idea. The choice of game was deliberate. My first concern is not design, eventually I will add that to the checklist above, but right now I’m focused on creating some kind of Tetris variant.

Nice Clean Code
Before starting a project, it’s difficult to anticipate how this might go, and as system design isn’t on my list I didn’t do any UML diagrams. Remember the aim here was just to get started, and more importantly finished.

Complete Application
I’ll link this at the end, needless to say it got done!

Set Deadlines
I set myself the deadline of only one week. The project is small enough and I decided that this would push me enough to make sure I was ‘on it’.

Be Proud
The proof is in the pudding, but if I meet my aim of getting it finished and making it fun to play, then I’ll be proud.

Post About It
Uh… here we are…

Getting stuck in

The first thing I did was shop around for game engines. This isn’t a bad thing to do, but I’ve got caught up in this before and lets face it, Tetris doesn’t require much tech. I started out using Cocos2d-x the multi-platform C++ cousin of Cocos2d. This was working out well, and it seems a very good option for developing mobile apps. However, after a little battling with keyboard input and other such things, I stumbled upon SFML. The C++, object oriented little brother of SDL. I chose to port very early on, which set me back a few hours but it was worth it. Keep your engine simple.

With several hundred code pounds shed, I moved on and thrashed out the basic game mechanics. I don’t want to go too deeply into this, there are plenty of Tetris clones about, feel free to check the code out later. The premise is simple, a tetrimino is made of blocks. We add a slowly falling tetrimino to a grid of same sized blocks and let the user try to arrange these shapes in a compact game-winning way.

During the early stages there were frustrating moments. You miss a value, or battle with your API of choice, but you get past this. After a couple of days with a basic, buggy version working; the game takes shape and so does the code. You begin to understand how your update loop should work, what order of operations you need, how to handle player input and why your bloody L-tetrimino wont rotate properly. As long as you have the basic features down, the rest is about iteration. A bug can be fixed or a decoration added. Design-fun can begin if you get a prototype done early.

A very significant thing that I was able to do was hand my early version to an honest play tester. She was able to give me a list of about 8 bugs or improvements that she could think of. This is invaluable! I cannot stress enough, if you have something that you think closely resembles you core game, show it to people! Sure, they’ll tell you about some bugs you knew about, but they’ll tell you a hell of a lot more useful stuff. Get people playing it early.

After addressing some of the core issues I was able to focus on some decoration that, in my opinion really marks the application as finished. I used GIMP and devised a simple icon to use. I used an evening of development to write some music and sound effects for the game. I also made sure to complete the game play experience by adding in high score support with classic 3 character name entry. It is these things that make a moving a bunch of blocks into a game. In whatever way you can, tie a bow round your finished gameplay.

Having come to a point of completion, I began to review, refactor and clean the code up. I am still not 100% happy with it, but that’s how it goes; I had a deadline. I have added some comments in the source suggesting improvements but instead of adding in more modular code for rendering and handling inputs, I decided to draw a line through the potential endless tweaks. In order for ‘getting stuff done’ to work, at some point, you just have to ship it.

So that’s it
As I promised myself I would do, I worked to a deadline and got it done. I’m not going to change the code any more. It is far from perfect, but it’s sitting there on my server, in GIT as a point of reference. My next project will draw on the code and lessons of this project and that’s fine. The point here is not to make the perfect engine or game.

The code can be found here. You’ll also find the audio resources and Xcode project files.

Note: I do not own any rights to Tetris, any code or products are intended only for educational/hobbyist purposes only.

Game Download (Mac OSX 10.8.2)

I would love to hear your thoughts on this post, the code or the final product; or all three. I am constantly striving to improve and produce high quality content, so please feel free to contact me via the links below.

 

Tech Notes and after thoughts

I recently had a chat with a friend about heap versus stack memory allocation. He saw my code and noticed my use of the heap allocation in the initalisation of objects. For a game of this size, running on a high RAM machine, it really doesn’t matter. I did think it worth mentioning here though, that if you’re developing for consoles, or machines with small amounts of RAM, you will need a custom memory allocator. There is a very good chance you’ll never need to look at a memset or memcopy function, but just be aware of it. For my purposes, worrying about fragmentation and other low-level stuff was overkill. For more see this and that.

Having re-read the code and shared it around, it quickly became clear that in a larger game, my design would collapse. The update method of Engine.cpp for example would become impossible to follow. For my next project I will be exploring the ‘entity-component’ design pattern and trying to leverage events to clean up my code and make things much more extensible.

Share this post around and get in touch.

Getting Stuff Done

0

At the beginning of 2013 I picked up an old idea. It’s a game that I have had a design for, in some form or another, for a couple of years. As I began to develop a prototype, I realised that without more resources, time or collaborators, it would be unlikely to get made. This left me frustrated.

It occurred to me that a lot of developers that I know share this frustration. We often struggle to balance our day jobs, ideas and actually finishing personal projects. Considering this, I recently kicked off a series of deliberately simple, achievable projects. The huge game designs can wait. For now, my aim is nothing more than to just get stuff done.

As developers we should try to write good code, design systems that we’re proud of and bring projects to completion. This stubborn ‘just finish it’ approach interests me a lot. Giving myself deadlines, fixed parameters and a set of requirements to work to is extremely effective. We should try to take the norms of professional development and apply them to personal projects. I’ll write more fully about this topic in the future, if only to warn a pubescent version of me how it all works!

For now though, here is a list of what I will keep in mind as I try to get stuff done. These are things personal to me. If you want to get stuff done too, write a list of what you want to get from your projects.

Getting Stuff Done, checklist:

  • Make a fun game
  • Write nice, clean, well thought out code
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

Note that game design doesn’t feature in this list. I am constantly thinking about games I want to make, or design choices made in games I play. What I am trying  with these projects is simply to finish them to a high standard. When you get going you realise that even the smallest games, in a single persons hands, can quickly expand in scope.

If you have more ideas than time, hopefully you can take something from the ramblings that follow. Good luck!

Numerals

0

I recently saw a small algorithmic problem set that set the challenge of converting between Roman (XVI) and Arabic (16) Numerals. The problem itself seemed fairly straight forward and after a little brainstorming I was able to come up with a basic design. Perhaps the most significant part, however, was trying to keep things modular and use a unit testing framework and become more familiar with the standard and practices expected in a professional context.

The design

Below is a diagram outlining the desired workflow. It is essentially an input->comput->output model aimed to work very simply from the command line.

This design highlights the need for 4 Classes: Tokenizer, Translator, Numeral and Validator. In addition to these I was also going to need a class setup for unit testing.

Unit testing

I decided to use python for this task and found Nose the unit testing framework. Check it out here

There was no particular reason for this, only that I was referred to it by a friend. It allows you to setup a class with methods beginning with “test_” then from the command line you can run ‘nosetests’ on the unit tests you’ve written, it was very accessible and seemed robust.

As a side note, unit testing is used heavily in test driven development and has become widely thought of as an important part of modern development cycles. With a known input / output expectation for any given function, class or module we can assert a whole bunch of things about the state of our data at any given point in the codes execution. ‘nosetests’ comes with some neat features for jumping into PDB if it breaks and will also allow code coverage data. For a full explanation on Unit Testing see the ever reliable wikipedia

Implementation

There were a few challenges to consider when tackling this problem. I will go over two of them.

Firstly the problem itself. How do we go from ‘MMDCLXVI’ to ’2666′ and back again?

Roman to Arabic

In the simplest case Roman numerals are simply additive. We can take the value of each character from the left and add them all up to find our number. For example “LXV” represents “65″ in Arabic numerals because L=50, X=10,V=5.

However, consider the following: V=5, VI=6, VII=7, VIII=8, IX=9

Often to save writing loads of symbols, we prefix a numeral with a smaller subtractive symbol. So “IX” is 1 subtracted from “X”(10). It is this feature that led to using a tokenizer. We have to be sure our data is interpreted in this way. The method for tokenising this simply involve checking the symbol to the right of the current symbol and collecting the necessary symbols together into tokens. During this process we can also validate for silly input like “IIIIX” where “VI” should be used.

Once we have these tokens it is simply a process of adding their values together at the translation stage.

Arabic to Roman

There are some nuances to tokenising and translating Arabic numerals. I will leave it to the reader to consider how the algorithm might look. A hint: remember Roman numerals are expressed as a certain set of larger whole numbers.

Validator

The second challenge I will mention here is the validator. There are already modules around for doing validation, they are almost certainly better than what I came up with, but the exercise was a useful and fun one. The main idea behind the validation class is that it should only define the mechanism that can be used to submit validation queries. The user should be able to add their own rules to it and call them later. It should also have some useful defaults.

The way I chose to do this was simply store a dictionary of strings->functions. In python this essentially means that I expect to object in the value field to be ‘callable’ (implement __call__).

The validator also expects these functions to have a certain signature. (data, kwargs). This allows me to guarantee that any call to validate() will allow me to safely pass through the required arguments. I enforce this using the ‘inspect’ python module whenever a new rule is added.

The code

The code will be going up on my gitHub and although parts are still a little messy it should display some of the concepts I have gone over above.

github.com/pjsdev/numeral

 

Ray Origin

0

I recently begun to write my own raytracer. The reason for this was mainly to explore an area of graphics that I haven’t attempted to program in before (there are many). Another interesting thing about raytracing is that it relies on a virtually completely different methodology to other forms of rendering I have played around with (Deferred and Forward).

This post is written mainly for reference and for anyone who is trying to get started with their own ray tracer.

So what is a raytracer?

Put simply, it is a simulation of the interaction between:

  • Light Rays from Light Source
  • Objects in Scene
  • The Camera (eye)

The intention of this method is to simulate the physical reality of how light travels and how the camera interacts with a scene. I will supply some suggested reading below, but here is my explanation about the basics.

Important Points

  • It is expensive in general and therefore not usually a viable option for real-time rendering. New GPGPU techniques have exposed the potential for real-time results however
  • Familiarity with OpenGL or DirectX is no real help as they do not natively support ray tracing
  • This method is widely accepted as the most physically accurate one that supple realistic images

How it works

A ray of light is emitted from a light source. This ray travels straight into the ‘world’ and hits an object. Some light is absorbed, some reflected (depending on the material of the object). For our eyes to perceive this object some of this light has to reflect and hit our eye.

Forward Raytracing

Many rays shot for each light with many reflections off objects

We can calculate the colour of an objects surface in the same way as we do with many other rendering methods. The reader may be familiar with GLSL shaders, where we take the dot product of the inverse light ray with the surface normal as a coefficient for the ‘shade’ of the surface. I won’t go into this calculation here, but for more lookup ‘lambert shading’ or refer to my previous post / papers on deferred rendering here

A large problem with this however, is that for any given light (and we may want many lights in our scene) we have to shoot rays out in all directions and test to see if they hit the eye (camera). This is called ‘forward raytracing’.

This is computationally expensive and thus not usually a viable option. This involves an arbitrary amount of traces (what we call tracking a rays ‘progress’) and is too expensive especially on high resolution images.

Backward Raytracing

As a result, an eye-centric method is used. Essentially we say “okay, what can we see with the camera? Now does any light hit that?”. In the most naive case, we simply shoot a ray out for every pixel of the image and when we find the first object along the ray we shoot a ray to our light(s) from the surface to see if it is visible from the light (or is in shadow).

Backward Raytracing

We shoot a ray out for each pixel and see whats lit or not

Refinement

In an effort to improve this very basic method, we need to add some basic features.

An issue with sampling only once per pixel is that we could easily miss some fine detail like sharp changes in topology or material colour.

Poor Sampling

We miss the colour from the edges of the sphere

This subject is really one for a signal processing expert, (see Nyquist–Shannon sampling theorem) but the general idea is we need to sample enough to capture all the details of our scene. The first step to do this is to split each pixel into a subset; sub-pixels. In the diagram below I have shown each subpixel with a random offset, this ‘jittering’ can improve visual output and is included for reference.

Jittered Sub Sampling

Improved visual results by averaging many samples per pixel

This method is sometimes referred to in relation to Monte-Carlo Integration. This essentially allows us to integrate the change in values over a domain to find an average ‘under the curve’. In simple terms, sum all colours sampled and divide by the number of samples.

Adding Materials

To account for the different types of materials in the world we can calculate surface colour in a number different of ways. To start with, I will cover basic diffuse and specular reflection.

Diffuse

This is the most basic of materials. When we find our eye-ray has hit a diffuse object, we simply trace to see if it is visible to the light. If it is, we perform basic “n-dot-l” lighting. Taking the angle between the normal and light into account, mixed with the surface colour we can find out what the eye can see.

Specular Reflection

This process involves recursive raytracing. The basic premise is the find the direction of specular reflection and send another ray of the be traced for diffuse colour (although if we allow it, more reflective samples can be taken).

Perfect Specular Reflection

Mirror like materials are covered this way

The psuedo-code for finding the reflection ray is:

 

 

Where:

N is the normalized surface normal
I is the incident ray (the incoming ‘hit ray’)

This gives us a direction to trace down. When using this technique without any other contributing colour, we have a perfect mirror reflection.

Earliest Working Raytracer

A basic ray tracer

Implementation Notes

  • The whole system relies on ray-shape intersections. So scrub up on ray-sphere and ray-plane collision detection. When you get to ray tracing meshes you’ll need ray-triangle too
  • Remember, you have to do this all in software (on the CPU) to begin with. All your chosen graphics API will help with is drawing a pixel array to the screen. (you can even just dump out the values to an image file)
  • Get started by representing a sphere and a camera only. Shoot a ray per pixel into the scene and draw black for no hit, white for hit…then keep adding the cool stuff on top :)

To do

The work currently in the progress includes:

  • Depth of Field
  • Refractive Materials
  • OpenCL Computation

Recommended Reading

There are tonnes of resources around so I only list a few key ones

Books:

Websites:

As always if you have any questions or notice i’ve made a mistake somewhere, please contact me!

The code that produced the above image is here and uses cinder for some basic things

Direct3D – Cloth Sim

2

I’ve been working in the film industry for almost a year and have been learning so much. However, I recently decided to carve some time out to support my development even more. As such, I have decided to pursuit some of the kinds of projects that were presented during my Masters; ones that I had no time for.

Finding a framework

I needed a quick way of getting a framework up and running. It had to support modern GPU features to give me the option to explore tessellation / geometry and other shader types. So after a bit of messing about I settled on Direct3D. There are a few reasons for this, not least the completeness of the Direct 3D 11 SDK. I will also be able to learn two tools that are widely used in the game industry (VS10 + DirectX), which seemed like a fun idea.

I found a guide to getting started with Direct11 at rastertek.com. This gave me a good starting point for getting vertex buffers and shaders up and running.

I went to work on adapting the content in these early tutorials to the structure I wanted. I also used this opportunity to switch from my old SVN repo to Git (with Github)

With the basic framework in place I was able to focus on how to get my Cloth simulation integrated. I wanted to make sure as part of porting the sim over, I also improved its structure.

In my old structure I had all the spring / particle solving logic in the cloth object itself. I decided against keeping this, and built a solver class. This defines what a particle and spring is and allows us to accumulate forces on them and perform numerical integration. For now, I have kept Verlet as my integration method.

As a result, the Cloth class is only concerned with how to place each particle (mass) and spring, whilst also knowing how to render itself (populating the vertex buffer etc)

The only requirements for this stage of development was to get the sim to a similar state as it was last year. However, I couldn’t resist adding a Light class that allowed for ambient, directional diffuse and specular lighting.

There were some tricks when moving this OpenGL code over. I had small issues with:

  • Counterclockwise declaration of polygons
  • A good method for getting the indices for drawing the cloth (I was using GL_QUADS before eurgh!)
  • UV coordinates start top left in DirectX not bottom left
  • General semantic differences and things made easier by the SDK

-So far I have enjoyed using DirectX, HLSL and GLSL are similar and DirectX has very verbose structures and description objects that are required in setting up you buffers and shaders.

Simulating Cloth

I wrote a short chapter on simple cloth simulation in my Thesis, which can be found here

For those who like things succinct though here are some key things to consider.

The mass-spring model for representing cloth can be straight forward. The fundamental idea is that cloth is made up of particles that are connected in a particular way and have forces applied to them

Laying aside the simulation of dynamic(moving) cloth, we can look at constructing a rectangular grid of ‘cloth’. Let’s say our cloth is three particles by three particles

We can represent a particle like this:

 

If we tried to put these particles into our solver now, each particle would act independantly, which isn’t very useful for cloth. So, we need to define another structure that links particles together and helps to give things a bit of a kick. The picture gallery shows the layout of the particles and springs we should use.

A spring can be defined like so

 

This allows us to record a ‘restlength’ when we attach a spring to two masses. The aim of the spring when calculating it’s effect (force) on its particles is to move toward the restlength as much as possible.

With this setup, we can throw our particles into our solver, apply forces to them, which move them toward or away from each other. This, in turn changes the spring length, which forces them to act on the particles.

If you are interested in how we integrate these forces for the springs and particles, check out repositery (link at end)

Drawing it

We used to be able to draw using quads. Which meant that Cloth could be easily thought of as a grid of squares. Modern graphics APIs tend not support this directly anymore. This is because your GPU renders triangles and a quad can be easily represented as two triangles. So natively supporting quads doesn’t make sense anymore. Giving triangles to the GPU to rasterize is the best way.

We want to smoothly render the gaps between the points. We want to be efficient and give the GPU some indices to find the vertices in needs. With a width of 3, we have 2 channels of polygons to render per row-channel. So  indexCount = ((width-1)*6) * (height-1);

We then just need to construct the indices for drawing triangle lists. After this you run the simulation in your game loop and can add normal calculation and texture coordinates for added aesthetics.

Demo

In the video I had a gentle wind as well as gravity introduced into the solver. The camera rotates slowly around cloth that is hanging (constrained) across the all the top points.

Future Work

Below is a list of areas related to cloth that I will consider exploring.

  • Object Collisions
  • Generate Cloth from Mesh
  • Compute shaders GPGPU solution
  • User interaction
  • Creasing
  • Tearing

The code for this is on github

MSc Round Up

0

It’s been a while since I last posted. There is a good reason for this, or at least I tell myself this to redress my guilt at not being more pro-active…

In late June I began an Internship at The Moving Picture Company. I was fortunate enough to secure this based on the work I have been doing over the past year. Since that time I have completed my course, got a job and am now looking for a place to live. The internship was in the Software Department and lasted 8 weeks. In that time I also had to complete my Masters Thesis, which ended up being a portfolio of work that I have completed. The details of this can be found here.

During the internship I worked closely with research lead Rob Pieké and more distantly with a small team of developers. More importantly, I learnt a lot in a short amount of time, being exposed to things that I had never really worked on before (Makefiles for one…). As my main thesis subject suggests, most of my time was looking at CPU speed-up techniques, a topic on the minds of many software engineers in the film /game industries. I handed in my thesis at the end of August and finished the internship a week later. I was then fortunate enough to secure full-time work at MPC and have now been working there for 3 weeks.

So: it’s been a big year for me. Bournemouth was great, I made good friends and learnt so much new stuff; this learning process has now been amplified in my work.

Personal development…

The above round-up is intended to explain why there might be a slight lack of development work being posted here. Once I’ve settled into my work I’m sure I will find some time to start up personal development again. This stuff will most probably be related to games.

That’s it from me for now.

rsl lime

Renderman Lime Shader

0

A few weeks ago I wrote a lime shader set in renderman.

I learnt a lot about how to achieve an organic look to an object using RSL.

The lime uses a sphere shape, surface shader and displacement shader.

My primary noise function was FBM, implemented as shown:

 

Here is my result

rsl lime

Rendermans freshest lime

Go to Top