Jump to content

  • Log In with Google      Sign In   
  • Create Account

Alex Hopkins' Journal

Progress on "IOF" file format for OBJs

Posted by , in IOF, Uncategorized, C#, DirectX 11, Engine 28 August 2012 - - - - - - · 680 views
obj, wavefront, directx, opengl and 11 more...
I have finished "spec 1" of my custom model format, IOF. It is intended to remove a lot of the complexity of OBJ files that I won't be using but also introduce important features that I feel OBJ files are missing.

I am splitting the work of this format up until smaller "specifications" so that I don't spend months on finishing the complete model format. The model file contains the spec version it was made for and so all files can be loaded for backwards compatibility. Unfortunately certain features will require a re-build of the IOF file from the original OBJ file.

For example, in "spec 2" I plan to support mesh groups and hierarchies. The former is partially encoded in the original OBJ file as separate group entries but the latter isn't supported at all. So a "spec 1" IOF file will have lost the group information, meaning it can't be upgraded to spec 2.

Currently, "spec 1" is very simple. Instead of the multiple separate index values for position,normal and texture coordinates in the OBJ file, the IOF file stores unique vertices and indexes to them as a whole. That means that more vertices generally will be output from the IOF than were stored in the OBJ but it also means that the Index into the vertices is compatible with OpenGL and DirectX indexed arrays.

To achieve this, an 8-tuple is used as the key in a Dictionary. This 8-tuple is merely the entire vertex information, comprising the position, normal and texture all together. This uniquely identifies each vertex. The 'faces' list is iterated through and every time, the dictionary of unique vertices is checked for that vertex. If the entry exists, the index is returned (the index is stored inside the vertex structure as Dictionary classes generally don't care about ordering) and stored in the Index list. If the entry doesn't exist, it simply creates a new vertex, fills out the index and adds it to the Dictionary before adding to the index list.

One of the features I wanted from the IOF model format was easy serialisation and deserialisation. Parsing through an OBJ file isn't hard, but its more cumbersome than it ought to be. Using a serialising system allows JSON objects to be used instead of plain-text line prefixes, making later deserialsing much easier.

The single down-side to this (that I can see) right now, is that the exported IOF files are in the order of 4 times the size of the original. This is a combination of the extra vertex information and also the names of the JSON fields being output for each vertex. This issue takes an ~90kb file up to ~250kb. While this isn't going to fill a hard-drive yet, I expect that IOF Spec 2 will have to support compression of some kind. A quick test shows that the 250kb IOF file is zip compressed down to ~23kb, a 90% saving in disk space. This must be optional though, as it will obviously put extra computation time on the deserialising later on.

Attached Image

Moving from C++ to C# (and SharpDX)

Posted by , in Uncategorized, C#, DirectX 11, Engine 27 August 2012 - - - - - - · 1,462 views
sharpdx, c#, directx, native and 7 more...
I am switching my focus from C++ to C# for my landscape / environment engine, and switching from native DX to SharpDX.

There are many reasons for this, chief among them the speed at which you can achieve things in C#. I could continue my engine in C++ but the rate of progress wouldn't be great and given that this project will end up being a submission (hopefully) for a University project, I'd like to have time spare to write a dissertation! I appreciate there is a performance penalty for using managed code and calling DirectX but the engine I am writing will be portable to C++ as and when I have adequate time to do so.

One of the main areas of exploration for me here is to see how many of DirectX 11's new features can be applied simultaneously to achieve fast-performing rendering techniques for an open world environment. It may seem counter-intuitive then to use managed code to do this but as well as offering a practical investigation into how plausible game engines are in C# it also offers a chance to see whether a DirectX10 C++ engine written to be as close to a DirectX11 C# as possible competes. Obviously a scientific evaluation of DirectX 11 and 10 would pit them against each other on common ground, but I can say I'm ascertaining whether DirectX11's new features are enough to overcome certain limitations elsewhere (like using C#).

OBJ files and indices

Posted by , 27 August 2012 - - - - - - · 600 views
and 1 more...
So whenever I read about how to import a model into your game, it tends to be followed by suggestions that the user go and read the appropriate file format specification. Then a few suggestions related to model asset libraries like ASSIMP. I have tried many of the libraries and always seemed to have one or two issues with them, none of which were fatal, all of which were annoying to debug.

For my project going forward, I will require many models to be imported and I'd like to minimise the pain of doing so further on. I wrote an OpenGL-based 'sniper' game for University that allowed the importing of hundreds of models at run-time and you could fly around the city "painting" models in and rotating them individually. There were a lot of models so I wrote a custom level format which housed a list of possible models and all the meta-data. This was in XML format.

Now, I'd like to go further and gain more control over the models themselves as well as the levels. I'm favouring JSON as a format for things as it seems to map slightly more to what I want to do, plus with serialisation tricks and some reflection, it might be possible to output replays/gamestates.

So, I'm writing a custom model format. It's going to be very basic and include only things such as
  • Vertex positions,
  • Normals
  • Texture coordinates
  • Texture-file linkages
  • Lighting information per-vertex
  • Maybe smoothing information
  • Possibly hierarchical meshes
  • Extra meta-data for run-time use
The first obstacle I found while running my OBJ importer is that the "Faces" index into separate position, normal and texture index arrays which isn't compatible with a DirectX index buffer. So, algorithmically parsing these index arrays must be done first. So, my output file format will be called, tentatively, "Indexed ObjectFile Format" or IOF. I'm half-way through writing a custom tool to convert between OBJ to IOF.

It's both fun and educational to write your own model formats and certainly good practice writing game tools such as model converters. Knowing your model format intimately can only be a good thing later on down the line when you wish to incorporate more advanced features like skinning, animation etc.

DirectX Graphics Debugging

Posted by , in Uncategorized, DirectX 11, Visual Studio 23 August 2012 - - - - - - · 593 views
DirectX 11, DirectX and 9 more...
I once had to write a DirectX "scene" for a module at University. Back then, I wasn't aware of graphics debugging tools such as PIX or nSight. They are amazing! They allow you to capture a frame of your application and examine every tiny detail of the graphics pipeline.

You can see all of the DirectX calls and the render targets as they existed at each point in time. You can click on a single pixel and they can tell you which draw calls affected that pixel and how. Stepping through the shaders (black magic) allowed you to visually see the effects of the shader code and verify them with the output in the render targets. Contents of Vertex and Index buffers are easily displayed and even viewed in 3D preview.

So now, it's 2012 and Microsoft has caught up and released a suite of graphics debugging tools in their newest Visual Studio (11 / 2012). Having access to every little piece of the puzzle means people are able to diagnose bugs more quickly and in my experience, the graphical bugs are some of the hardest to understand.

Currently, nSight doesn't work with Visual Studio 2012. I wonder if they are going to update it or if they feel it's a fruitless endeavour, given Microsoft's new found efforts in this area.

Attached Image

Start of my blogging on GameDev

Posted by , 23 August 2012 - - - - - - · 731 views

Hello World! My name is Alex and this is my first post on my first blog on GameDev. I am currently studying for a Bsc. Hons in Computer Game Application Development at Abertay University, in Dundee, Scotland. I am about to enter my fourth year and decided that before I do, I'd start work on experimenting with the development of my own game engine.

I've never done this before, so I expect that I'll make plenty of mistakes along the way and will constantly fight myself to not try to over-optimise early-on. That kind of thing, I regularly read, is a bad thing. Optimise when there is a need.

I became interested in making a game engine when I first started to read about the advancements made possible in DirectX11. It seems quite amazing the things that are possible using DirectX and the care taken in it's development seem to suggest Microsoft cares about PC gaming, Although they have seemed to bin XNA and a lot of developers seem unhappy with the impending Windows 8 release.

So, I came to write this blog because I wanted a place to journal my thoughts and findings. After watching a video on YouTube about DirectX 11 Tessellation, I noticed the uploader had a blog here. I regularly visit this site, it's an amazing resource, but have never thought about blogging here.

It begins...

October 2016 »

23 24 2526272829

Recent Comments