Close-up

Some spoiler free architectural detail shots of a place I’ve been working on:

shot_2014.09.05__time_14_13_n01

shot_2014.09.24__time_17_35_n04

shot_2014.09.24__time_17_36_n06

 

 

Posted in Uncategorized | 26 Responses

What we’ve been working on lately.

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.

 

Posted in Development, Engine Tech | 37 Responses

HLSLParser

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:

  • Support for 3D, 2DMS and shadow samplers, and most of the associated intrinsics.
  • Added support for many missing intrinsics.
  • out argument modifier.
  • Default argument values.
  • Block statements.
  • Attribute annotations.
  • Static, inline, uniform and other type modifiers.
  • Bitwise operators.
  • Hex literals.
  • Full declaration syntax, including multiple declarations in the statement.
  • Add support for full declarations in buffer fields.
  • Effect syntax (techniques, passes, sampler states, state assignments).

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:

https://github.com/Thekla/hlslparser

Once we have the syntax tree in memory we can do many cool code transformations. In particular, we do:

  • Dead code elimination.
  • Determine used parameters and resources.
  • Assign registers/offsets explicitly to control layout of parameters and resources.
  • Sort resource registers and group parameters in buffers based on frequency of change.
  • Rename semantics.
  • Reorder pixel shader arguments so that vertex shader outputs match pixel shader inputs and avoid linkage errors.

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:

  • No type inference for sampler types. It assumes sampler == sampler2D.
  • No support for {} initializers. Instead of float2 p = {0, 0} you have to write float2 p = float2(0, 0). This particular case is not complicated, but it does get more hairy when initializing structures. For now, I’ve simply modified our shaders to avoid this.
  • No support for rectangular matrices. We did not support them in the GLSL translators either, so we avoided their use in our shaders. It would be nice to add this eventually.
  • No support for do, while or switch statements. These should be easy to add, but we just didn’t need them!
  • No proper error recovery. We stop reporting errors after first one. This would be nice, but is not critical.
  • Semantic analysis is incomplete. The parser does some, but not a complete semantic check. The generated shader is not guaranteed to be correct in the absence of errors, but since we have proper file/line annotations, this usually doesn’t really matter.

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.

Posted in Engine Tech | 14 Responses

Getting Things Done

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:

shot_2014.08.15__time_10_17_n04

 

 

Posted in Uncategorized | 25 Responses

Irradiance Caching – Continued


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.

neighbor_clamping_02

Posted in Development, Engine Tech | 8 Responses

Road to E3 – Day 5

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:

shot_2014.06.06__time_19_11_n01

Posted in Development | Tagged | 30 Responses

Road to E3 – Day 4

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.

shot_2014.06.05__time_18_10_n01Tomorrow I’ll make sure I walk around a lot to hunt down any major issues, get the overall color vibe (mostly get more variation on the walls) and any extra details.

 

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:

shot_2014.06.05__time_17_41_n12

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:

shot_2014.06.05__time_17_42_n13

shot_2014.06.05__time_17_43_n16

 

I still have polish to do, to match everything to the walls Luis finalizes tomorrow, and then we should be ready for E3!

 

 

Posted in Development | Tagged | 3 Responses

Road to E3 – Day 3

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:

shot_2014.06.04__time_18_33_n03The center building is now complete and we got the layout for the ruined walls so the major task for tomorrow is to get them all detailed (very time consuming!)

shot_2014.06.04__time_18_29_n02

And finally some new interior spaces that you can’t really see from the previous angles.

shot_2014.06.04__time_18_38_n01

 

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.

 

 

Posted in Uncategorized | Tagged | 5 Responses

Road to E3 – Day 2


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.

shot_2014.06.03__time_18_11_n01

Here are the new modular pieces that were done for detailing:

Pieces

 

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:

shot_2014.06.03__time_18_26_n04

Posted in Development, Uncategorized | Tagged | 3 Responses

Road to E3 – Day 1

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.

image

 

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:

stairsEntranceEdits1

 

 

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.

DSC_0168

Here is the current result using different modular stairs/floor/battlement pieces:

shot_2014.06.02__time_18_31_n03

And the current overall look by the end of today:


Day_01

Tomorrow I’ll be tackling  the rest of the exterior walls and the 3 other towers.

 

Posted in Development, Progress Shots | Tagged | 4 Responses