Högni and Amy's game project

Thought in deed

Posts Tagged ‘Programming

Behave your trees

leave a comment »

I had already started using the good ol’ switch/case statement method to start implementing the AI for spacewars, when I bumped into Behave for Unity3D. This library implements Behavior tree logic in Unity with a nice visual editor. After a few minor niggles, finding workarounds for a couple of bugs and a lot of wrapping my head around how B-Trees really work, I love it.

The concept is so simple and intuitive, once you get past the initial (low) barrier you can be pushing out complex algorithms in no time. When you have your logic mapped out, all you have to do is implement the individual action and decorator code snippets. This fits so well into the Unity style scripting – where there are lots of short scripts – the workflow does just that.

Behaviour trees also integrate fairly well with FSMs, so you don’t have to instantly throw them out. You can have the tree actions change states or alter parameters if needed, maintaining interoperability.

There are other tools out there to create B-trees, but this one for Unity is very much sufficient.

Written by Högni Gylfason

20.07.10 at 19:16

Ogre3D and ShaderFX

leave a comment »

I’ve been using Lumonix’ excellent ShaderFX plugin for 3ds max to generate shaders, and then altering the generated shaders to comply with the Ogre3D  material framework. To say the least this has not been without problems. The main problem is that Ogre3D is designed to be very open as far as the content pipeline is concerned. The material structure is very flexible, but at the same time suffers for it in its inability to use techniques native to shader programs.

A shader program usually follows a set pattern. At the top are definitions of constants and “tweakables”. These are the inputs to the shader program, such as colours, values for specular and gloss levels, texture samplers and more. After these follow definitions of the matrix structures the shader requires to work properly, such as the world matrix, world view projection, view matrix and many many others. Thereafter come definitions for input and output structs for the vertex and fragment shaders. Then comes the real meat, the vertex and fragment shader entry points themselves and their internals. Last come the technique definitions, where everything is woven together.

Most 3d engines read the techniques and apply materials to the objects in the 3d representation. Ogre goes about this circuitously at best. It does not read the techniques at all, but leaves it to the programmer to know the entry point names and then declare shader definitions that are in turn used in material scripts. To add to this, most shaders exported from any shader authoring software do not compile properly with Ogre without alteration. For example matrix multiplication is reversed when multiplying multi column matrices with single column (vectors). The shader declarations need to include the entry point name, the target (vs_2_0, ps_3_0, etc) and the source file for the shader proper. Then you define the bindings for the world matrices to the shader inputs, e.g. wvp -> world view projection matrix. These, in turn, are read by entirely different files, called material files, where you point to the declarations you made in the previous files, called program files.

This process is labourious to say the least. So, I’ve been trying to find ways to automate some of the steps. The biggest hurdle at first was editing the shader files to conform to Ogre’s format. If you’ve ever seen the contents of a shader file, you know what I mean when I say that it is not pretty. Second was writing the shader definition files (.program) and thirdly including it in the materials. I wrote a short python script that cleaned up the shader file for comsumption by ogre, but it seemed a cumbersome way to do things, parsing the code of the shader and then outputting it to a new file. After trying this with a few different shaders, I decided to trash the project and try something else.

I started looking into how ShaderFX is constructed. Without going into too much detail (proprietary software etc), I managed to build a half assed export extension that exports Ogre compatible shaders. Now I just need to get some support from Lumonix to extend the extension so that it generates the necessary material and program files. So far Lumonix have responded well to this project, so I hope they will be able to answer the questions I have raised with them.

Hopefully to be continued.

Written by Högni Gylfason

24.09.09 at 13:04

Curiosity overwhelmed me

leave a comment »

After a friendly post on Havok’s forum in response to a question of mine, I decided to spend a couple of days looking into how difficult it would be to implement a relatively simple 64 bit fixed point physics backend.

The idea would be to utilize an existing collision detection library like SOLID or OPCODE, convert it to use fixed point instead of float, and implement simple impulse and velocity effects within their framework. I’d probably use Collada for the triangle lists as it is quite complete and mature. I’d have to write some code to convert from Collada to the collision framework’s formats.

As it turns out it should not be all that difficult, and I’ll probably head into that at some point. There are of course trade-offs in speed using large fixed point numbers as opposed to floats, but what I’m contemplating would not need a great degree of local precision but would require the extremely large numbers (2^47 or approx 144 trillion) offered by using 64 bit internals.

I am very very much a nerd.

Written by Högni Gylfason

16.09.09 at 01:10