Character Creation – Part 2

I have been working through the character creation process screen-by-screen. This has required a few diversions to work on hacking some additional file formats and of course writing new controls for the GUI system.

I nearly have the whole process finished, with the current limitations of not supporting biographies, custom classes, or the questions to select your class. These will be added in a second pass over character creation once more atomic systems are in place. The biographies in particular interface with systems like inventory and reputation, neither of which are implemented yet. All of these systems will come online in their own good time.

One great side-effect of using the existing Daggerfall files as-is will be that existing translation packs by international Daggerfall fans should work flawlessly with Daggerfall Unity. This comes with the other side-effect of having the same text limitations as Daggerfall, but to remedy this I have created a text interface in Daggerfall Tools for Unity called ITextProvider. Programmers are familiar with interfaces as a kind of contract between provider and consumer. Right now, all text you see is being routed through the default ITextProvider, which uses Daggerfall-native string methods. However, it’s possible to swap this out for another ITextProvider implementation using a different source for text. This is still quite early right now, but should pave the way for more advanced translation efforts in the future.

To mix things up a little from this typically English-centric site (it’s the only language I know, I’m sorry everyone) here’s the current state of character creation after applying Le Projet French Daggerfall to my installation. Everything here is running 100% inside Unity using a standard Daggerfall install for data.

Translation1 Translation2 Translation3 Translation4 Translation5 Translation6 Translation7


Daggerfall VID Playback

I’m going all-out in Daggerfall Tools for Unity 1.4. You will also be able to play Daggerfall’s VID movies right inside Unity to any texture you like. I’ve even provided a VID player panel for the native UI discussed in my previous post.

This is just a prototype, currently without audio or correct timings. I’ll show this off in a YouTube clip sometime in the future once its properly integrated.

Native User Interface Intro

The portable UI being developed for Daggerfall Tools for Unity 1.4 is coming together. Rather than use a uGUI simulacrum of the Daggerfall interface, I decided to re-implement Daggerfall’s native UI screen by screen, making it as true to Daggerfall as possible.




This has involved a fair amount of work to ensure everything is rendered at true native resolutions and scales proportionately to any screen size. Here’s an early test clip where I’m playing with the scaling, which runs in real-time.

Another challenge was pixel-perfect text rendering. The internal UI in Daggerfall Tools for Unity uses Daggerfall’s pixel fonts exactly, which required a custom text renderer. Below is the book reader UI flicking through The Real Barenziah. The formatting codes from Daggerfall are followed so precisely that badly formatted text even overflows in the same places it does in game.

Behind the scenes, the GUI runs on a state machine stack where windows can be pushed and popped as required. Each window is a hierarchy of components (panels, buttons, labels, etc.) that all follow the same consistent layout behaviour and handle fundamental UI tasks like firing messages when clicked. Everything is rendered and hit-tested internally at Daggerfall’s native 320×200 resolution.

Communication between windows uses a custom messaging system that runs independently of platform. The messages themselves can even work a bit like command strings in that they’re able to pass parameters directly inside the message.

And the best news is that you aren’t bound to using this GUI in your projects. It exists inside the Demo namespace, which means that nothing in the core library or API has any dependency on it. You’re free to use this GUI or ignore it completely to implement your own interface using whatever UI platform you’re most comfortable with.

There’s still a lot of work to do before it’s ready for Daggerfall Tools for Unity 1.4, but everything is taking shape very quickly.

Visual Diary: XNALibrary Update

After a hectic mid-year rush things are finally settling back to normal. I will have more time to dedicate to my Daggerfall tools for another few months before the silly season begins. I am now working on getting Beta 1 of Daggerfall Modelling ready for release.

When I started Daggerfall Modelling the goal was to make a quick and easy Collada exporter for Daggerfall’s 3D assets. It didn’t take long before I realised an opportunity to revive Daggerfall Scout in a more useful form. Like all projects, escalating the scope after most of the code has been written is a recipe for trouble. While trying to wedge in action records to my scenes (levers, switches, etc.), I came to the realisation my code had become as messy as hell. To accomplish what I had in mind a total rewrite of the scene manager was needed.

As an adjunct to Daggerfall Connect, I have also been developing an XNA class library that makes using Daggerfall assets with XNA a snap (creatively called XNALibrary). This code base is something I wish reuse for other projects, so it made sense to get all the scene management and rendering out of Daggerfall Modelling and build it properly into XNALibrary. The end result is a small XNA 3D engine designed specifically for rendering Daggerfall scenes. I then had to rip out all the old code from Daggerfall Modelling and port it over to XNALibrary as the primary engine. It was a lot of work just to end up back where I started, but internally the code is much improved. Following is a quick tour of what’s new in XNALibrary, as seen from Daggerfall Modelling Beta 1.


Scene Graph

Previously, Daggerfall Modelling used a one-dimensional array of objects and looped through them to draw scenes. This is fine for small environments but doesn’t scale up very well.  It also makes visibility testing and render batching harder than it needs to be. When it came time to link up the levers and switches, I realised it was time to put in a scene graph.

I decided to use a simple Bounding Volume Hierarchy based around spheres. The beauty of bounding spheres is that you don’t have to worry about axis alignment as you do with boxes. Spheres may not wrap objects quite as tightly, but they’re a lot easier to handle when transformed (rotated, translated, scaled, etc.) as the volume is always the same shape and alignment in 3D space.

On the left are a couple of screen-shots of the bounding volumes, rendered as wireframe spheres. The root node is red, general models are white, and sprites are green. Resources are added to the scene from the top down, with renderable objects like models and sprites in the leaves of the tree. This hierarchy makes it easy to cull non-visible groups – if a node isn’t visible, then none of its children can be visible either. It also simplifies mouse picking and collision as these tests are only performed where necessary. Batching visible polygons by texture becomes easier, which greatly improves rendering times. And finally, linking up chained action records becomes simplified thanks to each scene node being a discrete class aware of its own state.

Action Chains

Certain objects in Daggerfall have action records that describe how this object can move, rotate, etc. An example every Daggerfall player will be familiar with is the throne room in Privateer’s Hold (pictured left). When you throw the switch an action record makes the lever rotate, which chains to another action record to make the platform rise, which finally chains to the throne to make it rise also. The end result is you throw the switch and the platform rises (along with the throne and the player).

If you open up the screenshot to the left, you will see a red line going from switch, to platform, to throne. This is the action chain linking the objects together. The next screenshot shows the same linkage in Mantellan Crux – from the axe on the floating island, to the crossbow, to the giant sword. At some point, I will number the nodes so it becomes easier to visualise where action chains begin and end.

In Daggerfall Modelling Beta 1 it will be possible to trigger action chains and watch the animations run. There are other actions, such as teleporting the player or casting spells, but I am only going to support action that cause things to move around the scene.

Once gravity and collision are implemented, you will be able to explore dungeons from a first-person perspective with the ability to operate doors and platforms. You can also just turn off collision and gravity to fly around the scene with total freedom.

Add-In Components

The renderer in XNALibrary can plug in components that add functionality. This is quite basic at the moment, but will be extended down the road as needed.

Currently, the add-ins are a billboard manager for rendering sprites like trees, animals, NPCs, and a sky manager for drawing the background sky in location exteriors. You can see these components in action to the left.

The next release of Daggerfall Modelling should be ready in 3-4 weeks. This will coincide with an update to the Daggerfall Connect library download with XNALibrary updates included. All of this is in the SVN now, if you want to download the code as it’s being written. Just keep in mind not everything may be in a stable state in the latest SVN version.

Visual Diary: Collada Export

Daggerfall Modelling will be capable of exporting individual models to Collada format. This is a universal format for describing digital content such as 3D models and scenes. When this feature goes live in the next release, you will be able to export Daggerfall’s 3D data and load it back into modelling packages such as Blender and 3DS Max. You could also use this data in another 3D engine. One potential such use will be replacing Daggerfall’s standard models with high-poly variants in DaggerXL.

I’ve been working on the Collada export over the last couple of days and would like to document progress so far.

Wiring Up

The first step is to create a C# wrapper for the Collada DOM.

I started by creating a static build of the Collada DOM DLL, which is then imported into a CLI/C++ project. This wrapper project is able to handle communication between native code (the Collada DOM in this case) and managed code. Fortunately it was not necessary to wrap the entire Collada DOM, just a few methods of the DAE and daeElement classes with some string marshalling thrown in. The end result is a self-contained .NET assembly exposing the Collada DOM to any .NET language.

All I need to do now is code the exporter. I started with a simple model with a distinctive shape (pictured left). This arrow turned out to be extra useful for tackling axis-alignment in the next step.

First Import

My first pass at the exporter creates a tidy .dae file which Blender opens without any complaints. I love it when code works first run.

I did notice however the arrow was no longer pointing along the correct axis. The reason for this is that Blender uses +Z for up and XNA uses +Y for up. A quick scan of the Collada spec and forums shows this is a common issue with an easy solution. My exporter class is updated so that any axis can be considered up. This is achieved with a rotation on the model node and setting the <up_axis> in <asset> to reflect the appropriate setting.

With the model vertices in place, it’s now time to add textures.

Textured Models

This was more work than I expected. Each set of triangles references a material, each material instantiates an effect, every effect points to an image, which in turn points to a file on disk. Oh, and the materials have to be bound to the model in the scene setup.

Once my head stopped spinning from all the redirection, I could see the versatility of this method. I was also impressed how detailed scenes can be constructed using Collada, right down to cameras and lights. I want to look into exporting blocks, cities, and dungeons to Collada files at a later date.

On the left are a few screenshots of some distinctive Daggerfall models as viewed in Blender.

The exporter is more or less ready and just needs a little tidy-up. I have confirmed that my exported .dae files pass the Collada Coherency Test without any errors, and so far all the models I’ve loaded into Blender look perfect.

The Collada export feature will be available in the next release of Daggerfall Modelling. I’m looking forward to seeing what you all do with it in the future.

Visual Diary: Daggerfall Modelling Views

In my last post, I talked about the thumbnails view in Daggerfall Modelling. This is just one of the possible ways of exploring 3D data from Daggerfall. Read on to see all supported view modes and get an idea of how they work together.


This has been tweaked since my last post. I’ve selected a different viewing angle to give more of a 3/4 view of each model rather than a frontal view. I have disabled back-face culling to ensure a thumbnail is rendered even when facing away from the camera. The overall effect is that almost all thumbnails show a decent representation of the model that’s easy for the eye to track.

Thumbnails are generated in real-time from model data. I plan to add a few embelishments like watching the model spin when the mouse passes over a thumbnail.

Scrolling the thumbnail view can be performed from your mouse wheel or by dragging the page as you would the touch screen of an iPhone. You can impart velocity to the scroll with a flick of the mouse. The view will keep scrolling until you grab it again or roll the mouse wheel.

The thumbnail view isn’t just for viewing thousands of models either. When you have a city or dungeon loaded, you can switch over to thumbnails to view just the models used for that location. This filtered list of thumbnails will be helpful for finding the exact model to export in large areas where models can be duplicated dozens of times.

If you double-click on a thumbnail, it takes you straight to our next view, the Single Model View.

Single Model View

After finding a model in the thumbnails view, you can explore that model in greater detail. This view is similar to the model view in Daggerfall Explorer.

It is possible to search for individual models by ID (check the left-hand pane of top screenshot).

When viewing a location, you can also jump to single model view by clicking on any model within the location itself. Daggerfall Modelling uses bounding volumes so you can pick any model right out of the scene.

Location View – Top-Down Camera

The first way of viewing locations is the default top-down camera. This camera is always facing down on the scene and you scroll around as you would a 2D map. Clicking on a specific block in the map (screenshot) will take you directly to that block.

If you’re only interested in one block, you will be able to filter out everything but the block you’ve clicked on.

When you see a model you’re interested in, you can switch to inspecting that model in the Single Model View without losing your place in the Location View (unless you change locations).

Location View – Free Camera

The free camera allows you to move around in first-person mode through city streets or narrow dungeon corridors. Pictured left is the city of Sentinel (top) and Mantellan Crux (bottom).

The Mantellan Crux screenshot shows how the dungeon layout map is displayed. Each square represents a dungeon block. Currently the starting block (dungeon entrance) is blue-green, and other blocks are gold. The RGB values match those used in Daggerfall to display dungeon layouts.

Before this tool is completed, I plan to implement an “interior view” so you can crack open building interiors to select the furniture and other models within.

You can see there will be several ways of getting around Daggerfall’s 3D data. As a pure exploring tool, Daggerfall Modelling will replace Daggerfall Explorer, Daggerfall Cartographer, and Daggerfall Scout. The goal is to create a rich visual path for exploring models individually, or as part of the locations and dungeons they build. Every view will offer some technique for identifying, isolating, and exporting a model.

I hope to have a beta of the exploring side up for download in the next few weeks. Once any problems with the GUI have been ironed out, I will begin work on export queues and saving models to Collada format.