Some spoiler free architectural detail shots of a place I’ve been working on:
We built a DirectX11 rendering backend for our engine, which is likely to be the default when running on Windows. Up until now we had been running on DirectX9, which made sense when we thought the game was going to be done a while ago. But these days, DX9 is getting pretty old and busted. So far the DirectX11 version has been very successful; the engine runs much more smoothly, especially on low-end platforms, due to the drastically lowered CPU overhead of draw calls. There’s a little work to do here still — some of our weirder shaders don’t work in DX11 yet and there are a couple of lighting bugs — but this all should be nailed down soon.
We’ve been revising the modeling and texturing for areas near the end of the game. There are some nice treats in store!
We’ve been working on some of the “special effects” in the game, most notably particle effects. Our particle system was old and slow, so we are speeding this up, and then we will make some modifications to help make particle authoring an easier process.
We’ve been making some baseline functionality smoother. For example, so that you don’t need to think about saving your game, The Witness autosaves your progress every minute or so. On a high-end PC, you don’t notice the autosave, but on a low-end PC or on a console (because consoles tend to have different memory access properties than PCs), scanning the world for stuff that needs to be saved can be pretty slow, like, it could take 1/10 of a second, which would result in a hitch in the frame rate happening every minute. So we are hammering on this to make it faster, which should also result in saved game files being smaller, since we’ll be excluding a lot of things that don’t need to be saved.
We just finished porting The Witness to D3D11. It took a little longer than I was hoping and one of the unexpected difficulties was getting our D3D9 HLSL shaders to work in D3D11.
The D3D shader compiler provides a backward compatibility flag (D3DCOMPILE_ENABLE_BACKWARDS_COMPATIBILITY) that I was hoping would allow us to use our shaders ‘as is’. Unfortunately, it seems the backward compatibility mode has not received much love and things were not that simple. I run into several compiler internal errors, and even after finding workarounds most of our shaders did not actually compile, but would have required significant modifications, the resulting vertex and pixel shaders would often not link at runtime, and the use of register annotations on samplers only allowed us to control the layout of the samplers, but not of the associated textures.
For other targets (Cg & PSSL) we had been able to get away with some preprocessor macros and simple text transformations, but it seemed that was not going to be an option in this case. Not only that, having to write and adapt our shader code for the idiosyncrasies of each compiler was starting to become a challenge.
Instead, I thought it would be much cleaner and much more powerful to standardize on a fixed subset of HLSL and transform it to the shading language of the target by building a syntax tree, applying syntactic transformations, and generating shader code by traversing the resulting syntax tree.
This is essentially what we already do in the OpenGL backend to transform GLSL into HLSL. For that we use HLSL2GLSL and GLSLOptimizer. I considered using these same projects, either modifying HLSL2GLSL to output HLSL1x code instead of GLSL, or modifying GLSLOptimizer to accept and produce HLSL code. I avoided the former, because HLSL2GLSL’s code was a big mess and it was not very attractive to work with it. The latter was more interesting, and I believe it’s the approach taken by the UE4 engine. However, while much cleaner, GLSLOptimizer is still a fairly large project and I did not care too much about the optimization aspects that it offered.
Another option that I had just come across is Max McGuire’s HLSLParser. HLSLParser was a lot smaller and cleaner than either of those code bases. It was pretty much the code I would have written if I were to do this from scratch, so it seemed like the best possible starting point.
One of the main annoyances when working in the OpenGL backend is that GLSL errors are extremely hard to track down. They can be reported by either HLSL2GLSL, GLSLOptimizer, or the driver’s GLSL compiler. Each of the inputs to these compilers has different file and line information and none of them matches the original source code. Whenever an error occurs we have to dump the intermediate code and figure out from there what’s going on. It’s usually a waste of time and if D3D11 is to become our primary backend I did not want to have to deal with this issue.
I was happy to see that HLSLParser handled this correctly associating file and line info to the tree nodes and producing correct #file preprocessor statements in the generated output.
In order to parse our shaders with HLSLParser we had to extend it in several ways, here’s a partial list of the features I added:
I’m very thankful for the work Max McGuire did on HLSLParser and the least I can do is to release these our improvements to the public as well. You can find our fork of the project in our github repository:
Once we have the syntax tree in memory we can do many cool code transformations. In particular, we do:
The shaders that result from these transformations are minimal, that is, they only contain the definitions and declarations that are necessary for a specific entry point. We have complete control of the layout of resources and parameters and extract all the necessary information about the shader from the tree instead of relying on the platform-specific reflection APIs. The shader transformation is very fast and the resulting shaders compile faster than the original ones. Our new D3D11 shader processor and compiler is about 4 times faster than its D3D9 counterpart.
While it currently accepts all of our shaders, HLSLParser still has some limitations. Here are a few that come to mind:
Looking forward, I expect we will add code generators to target other platforms. It should be really easy to bring the existing GLSLGenerator up to date, or add new generators for PSSL and Metal.
I’m not particularly fond of our shader code. On one side, we abuse the preprocessor to generate shader variations and the result is often a mess that is hard to read and modify. On the other, our code is often highly repetitive, but there doesn’t seem to be a clean way to share it across different materials or structure it in a way that’s more compact. I’m particularly interested in experimenting with higher level code transformations, or coming up with new constructs to facilitate writing and sharing shader code.
Just wanted to do a quick post saying that we are all working hard on the game, figuring out some of the last unknowns and polishing things up. We are definitely in finish-the-game mode, that’s why the posts have gotten more rare. Here is a shot of the finalized hub area I first posted about in the beginning of the year, to tide you over:
Ignacio has posted the conclusion of his series on irradiance caching — at long last! — and released the source code.
This code is a significant chunk of what makes lighting in The Witness as nice as it is.
Final day and a lot more little things to polish than I expected. Every time I got something fixed another problem would pop up.
We got everything in a good state for E3 but there are quite a few more ideas we want to try for the castle visuals, probably 2 or 3 more days of work .
Here is a screenshot from another angle:
Getting close to the end of the week.
Most of the key detail has been added to the walls and I feel, if we had to send this build to E3, it wouldn’t be terrible.
We managed to get in some really nice framing details that I won’t spoil here but I’m sure players will appreciate them!
Here is a shot showing the ruined walls work.
Orsi’s Vegetation Update:
To give a little variation to the post today, I thought I would include some things I have been working on as well. While Luis had been working on the structures around the entry yard, I have been placing the vegetation and cables, and re-working some puzzle related things. Laying out the vegetation early on was important to give the place a sense of scale and to get the overall vibe of the place. I am very happy we got an other chance to re-do all of it, because I think it turned out much more magical this time around:
Even though it’s a much smaller area than it used to be before, I used a different combination of plants in different areas, so people would be less likely to get lost:
I still have polish to do, to match everything to the walls Luis finalizes tomorrow, and then we should be ready for E3!
This was a very productive day but visually less noticeable.
A lot of “invisible’ stuff got done like collision and occluders to make the area decently playable:
And finally some new interior spaces that you can’t really see from the previous angles.
Orsi is in charge of the vegetation (she is amazing at it) so that is one big chunk of work I don’t have to worry about!
I’ll be aiming to have everything done by tomorrow so I can use Friday for polishing and any major issues that I might have missed.
Here is the progress for today. Detail has been added to the rest of the walls and towers as well as windows and other smaller features.
We’ve had some discussions about the style of the battlements so those might change tomorrow or after.
Here are the new modular pieces that were done for detailing:
We just finished the day by meeting with the architects and discussing the interior layout of the space so tomorrow I’ll start on the interior building and ruin walls.
Here is how it currently looks:
Since we have only one week to get the entry area ready before E3 I was thinking it could be interesting to have a post at the end of each day to show how we are progressing.
It will balance out the high programming post count we’ve had the past few days and hopefully show a bit of how the art team works!
Last week, as you could see from previous screenshot, we got a rough layout of the area in the engine and tried to find answers to any remaining issues.
Today the goal was to sort out the design and navigation of the main entrance and the small towers.
This is one of my first mockups that didn’t look quite right.
The architects took a look at it and provided some 3d models of how castle stairs are usually assembled as well as sketches of how it should look:
After, I tried to figure out the details from references and what “pieces” I would need to build the structure.
Two years ago I went for vacations in Portugal and tried to see some castles. One of them in Guimaraes struck me as very similar to the entry yard. I made sure I got some pictures and now they are proving to be useful with angles that would be hard to get from online research.
Here is the current result using different modular stairs/floor/battlement pieces:
And the current overall look by the end of today:
Tomorrow I’ll be tackling the rest of the exterior walls and the 3 other towers.