Daggerfall Unity – Cities

The code to import cities is now working, and crikey does it need some improvement. Importing a full city into Unity takes around 10 seconds (compared to less than 1 second in Daggerfall Modelling) and results in a massive scene hierarchy requiring over 5000 draw calls per frame! Obviously this won’t be good enough for a final version. I don’t even have ground planes in yet…


The good news is this can be easily improved. Daggerfall Modelling made heavy use of caching, batching, mesh combining, and texture atlasing. I can do the same in Unity to bring those numbers right down. However, I will leave in the ability to import fully atomic scenes in case someone wants to see the native layout without regard to performance. Actually, I think even that can be streamlined. Lots of work to do, but I think I’m on track to finish in a few months as planned.

One more thing, the source code is now online. I’ll be updating this every day or so. If you’re really keen you can grab the code and copy it into a Unity project to play with. However if you wait a few days, I’ll create a .unitypackage for download with a manual included.



Daggerfall Unity Update

I’ve completed the first pass at porting code over to Unity. I now have textured models, city blocks, dungeon blocks, and flat objects working. I could lay out complete cities and dungeons at this stage, but want to do some code tidy-up first. Overall, I’m very happy with progress considering I only started work on this a few days ago.

There is a lot of Unity-specific work to go. I need to flesh out editor scripts and add options controlling how scene data is spawned. In case you’re wondering, everything is created procedurally from game files directly within the editor with a single click. After that it just works like a normal scene. The same could be done directly from code as well. Check out the new screens below.

dfunity-rdb dfunity-rdb2 dfunity-rmb dfunity-rmb2


In the last screenshot, you can see realtime shadows acting on the scene. Even the flats are casting and receiving shadows. This is using a standard cutout shader, which works in both forward & deferred.

Right now the scenes are built very atomically (from very small pieces). This is perfect for seeing how everything is put together and mucking about with the individual pieces. However it won’t be optimal for real-time uses. One of the options I’m planning will combine meshes and textures sensibly to minimise draw calls and state changes.

Check back in a few days for another update. The next update will include the first release for you to play with.

Daggerfall Tools For Unity

Since leaving the Workshop, I’ve been using Unity a good bit for other projects. It occurred to me the other day it should be trivial to drop my Daggerfall library (Daggerfall Connect) into Unity as everything was written in very portable C#. A few hours later, I had Daggerfall models firing up in Unity.

Scourg Barrow exterior in Unity

Scourg Barrow exterior in Unity.

It’s only a small step from here to spawning entire game-ready cities and dungeons in Unity. For the most part, this can be done using layout code I’ve already written for Daggerfall Modelling. I’d just need to refactor for Unity and build some editor scripts to hold it all together.

Based on this, I’ve decided to repackage the useful parts of Daggerfall Connect and Daggerfall Modelling into a small suite of scripts for Unity developers. As usual, this will be free and open source for everyone.

This doesn’t mean I’m returning to the Workshop full-time. I’ll only be allocating a few months of spare time for this project. I just think it would be great to see all the code I’ve written over the years being put to use by someone, and what better way to wrap up my years with Daggerfall than making one final tool available for a game engine anyone can use?

Let me know what you think! Is there something particular you’d like to see in Daggerfall Unity? If you’re a Unity developer and want to contribute, I would be more than happy to share access to the SVN (will be setting this up soon) to people with the right skillset.

DF Modelling – Crash On Startup

Just a quick post for anyone experiencing a crash on startup in Daggerfall Modelling 0.8. To run this application, you will need the following prerequisites installed:

1. Microsoft .NET Framework 2.0
Note: Only required for Windows XP.

2. Microsoft XNA Framework Redistributable 3.1
Note: This version is always required even if you have a later version of XNA installed.

I hope that is helpful for anyone trying to use Daggerfall Modelling and have not been able to get started.

The Future

I had an awakening recently. My wife commented that she enjoys more of my company when I’m busy in real-life because I put my hobbies on hold. We ended up discussing just how much time I pour into my hobby projects, especially those relating to Daggerfall.

On a normal night, I will come home from work and spend an hour or two with my family, then spend the rest of my night coding. On weekends, I start coding after breakfast and continue right into the small hours of the next morning.

During intense periods of real-life work (such as now after end of financial year), things are different. There’s just too much going on to spend time with my hobbies. The result is that I spend more free time with my family and less time stressing over self-imposed goals and deadlines. It goes without saying that my family loves me. To discover that any respite from my hobby projects is time they look forward to was a devastating realisation.

Some of my hobbies, including Daggerfall, have been in my life since I was a single man in my early 20s. I’ve carried these extra work habits forward into my adult life and not paid enough attention to how it might be affecting those around me.

So here’s the problem. I’m spending all of this time doing something I enjoy without much regard for my loved ones. They let me get away with it because I’m a motivated person and they know how important it is for me to keep busy. But this isn’t crunch time on a commercial project with others counting on me. These hobbies aren’t part of my income. None of this extra work contributes to our future, or pays the mortgage, or puts food on the table. It’s just extra work (substantial extra work) I take on because I like to extend myself, learn, and push against my limits. Up to a point these are desirable qualities, but I have taken things past that point by a wide margin. The only word I can properly give to my behaviour now is ‘selfishness’.

And the sad part is not many people really care about what I’m doing. Probably a few hundred are casually interested, and a much smaller number are actively excited by my work. There’s a genuine imbalance between the time I’ve taken away from my family and how much value that time has to the world at large. I’m spending valuable emotional coin in exchange for a currency of much lower value.

So now that you understand my reasoning, I want to let you all know that I’ve reached the decision to permanently step away from my Daggerfall projects. It’s time to do something different. From today, I will cease all work relating to Daggerfall Workshop and Ruins of Hill Deep. This is something I need to do as part of growing up and nurturing the things in life that will be most valuable to me as I grow older.

I apologise to anyone disappointed by this decision, and I hope you understand. I also want to thank everyone who has supported me over the years with encouragement and kind words. This is the greatest online community I’ve been a part of, filled with genuinely intelligent and passionate people. I’m going to miss you all.


Lighting Up #3

I’ve restored billboards (trees, rocks, etc.) to scenes and they generally light up correctly from surrounding point lights and the player’s personal light source. There is a simple light animation playing that changes the scale of the light volume +/- a small amount. Light attenuation means this effect is more obvious at the edge of the light radius than near the source.

The lighting system still needs a tidy-up, and a few bugs remain (such as the emissive wood textures you see in a few spots). I will continue to polish this leading up to Beta 2 release. Still, I’m happy overall with how the lighting is shaping up and posted a video preview.

Lighting Up

After moving everything to XNA 4.0, I decided to build a lighting system into Daggerfall Modelling Beta 2. I’ve always wanted to play with deferred rendering and it seemed like a good fit for Daggerfall’s many point lights.

If you’re unfamiliar with this technique, the gist is that different information about the scene is rendered into different buffers (collectively called a GBuffer) and combined together to make the final image. You can see three of these buffers in the debug screenshots below. From top to bottom are the color, normal, and light buffers. These get combined with a depth buffer to create our fully lit scene. The results are very fast, even on a mid-range GPU. The heaviest scene below is “Daggerfall from Above”, with almost every building and light visible. Total render time is about 12ms, and most of that is spent rendering the geometry. The lighting itself takes almost no time at all.

This is only the first of several visual enhancements intended for Daggerfall Modelling Beta 2. Don’t worry if you have an older computer and just want to export the models. You will be able to turn off or scale back these rendering features using options.

Daggerfall Castle Privateer’s Hold Throne Room
Daggerfall from Above Scourg Barrow Entrance

SVN Updated

The SVN repository has been updated to VS2010/XNA4.0 solution & code. If you are building DaggerfallModelling from source please ensure you have the latest version of the .NET Framework 4.0 and XNA Game Studio 4.0. You will also need to be using Visual Studio 2010 (or Express 2010) to load the new project.

A few bugs remain after porting to XNA 4.0. These will be ironed out over the next few weeks.

Building From Source and Other Issues

I’ve received a few emails from programmers trying to build Daggerfall Modelling from source and experiencing problems. The reason for their frustrations is that Daggerfall Modelling is built as a VS2008/XNA3.1 project. This means it will only build with Visual Studio (Express) 2008 with XNA Game Studio 3.1 installed. Attempting to build with VS2010/XNA4.0 will fail due to breaking changes in the latest version of XNA.

I also get the occasional email from Windows XP users with an older version of the .NET Framework 2.0 (pre-SP2) that experience a crash when opening a dungeon. This problem is caused by a bug in the .NET Framework 2.0 that was resolved in Service Pack 2, and can be fixed by upgrading/patching .NET.

The reason I stuck to older versions was to ensure my tools remained accessible to more people. On the flip side, not everyone wants to install an older version of Visual Studio and XNA just to compile my code. I’m also running the risk that Windows XP users will come across that crash without having read my getting started page for Daggerfall Modelling.

After serious thought, I have decided to make some changes to my source code:

  • Solution format upgraded to Visual Studio 2010 / Visual C# 2010 Express.
  • Daggerfall Modelling and XNALibrary will be refactored for XNA Game Studio 4.0.

The DaggerfallConnect class library and Daggerfall Imaging 2 will remain based on .NET 2.0 for now, but I might bring these forward at a later date.

The SVN will be updated in the next few days with these changes. The next release of Daggerfall Modelling (Beta 2) will require the latest versions of .NET and XNA Frameworks to run.

Daggerfall Modelling Collision and Gravity Preview

I’ve completed the first pass at collision and gravity systems in Daggerfall Modelling. This still needs a few passes to fix some bugs, but is largely completed.

I’m not implementing a full physics simulation, just camera-scene collision and simple velocity for gravity. This is a looong way from a real game system, but it’s more than acceptable for a fancy model viewer. If you’d like to see an early preview of this feature check out the YouTube video below. This was recorded while using an XBOX360 controller, which is why you see a crosshair in the middle of the screen.