DayZ Status Report - 30 June 2015
Posted on June 30th, 2015 02:10 PM EST
Greetings Survivors,
While development keeps moving along as usual, a lot of you have patiently been waiting for info on the new renderer, and for this week's Status Report Lead Producer Brian Hicks touches upon that very subject. Also, Senior Designer Jan Tomasik gives us some input on the ingame FOV; the theory and thought process behind the design solutions as well as decisions for the current iteration of FOV.
For this week we also present you with a link to the DayZ Trello board where Lead Artist Chris Torchia provides us with a small peek at environment updates, and lastly, we have a small feature on one of DayZ's content creators - Super Dan.
Contents This Week
Development Board Spotlight
Dev Update/Hicks
Greetings Survivors,
This week we'll touch on two topics. We'll start off discussing the work ongoing with the new renderer for Enfusion, and then wrap up discussing the current behaviour and mechanics behind sprinting, holding breath, and so on.
Players who have been actively following the development of DayZ are aware of the large task the engine team undertook to separate the legacy RV renderer from the simulation, and replace it with a more modular and updated version. The task itself of creating a new renderer is not huge, the length and weight of the task is related primarily to:
- Separating the legacy renderer from the simulation
- Ensuring the separation is complete, as the RV engine and its functions tied to it are extensive
Once the above was complete, the new renderer itself was broken into three primary modules. (Bear with us, this can be moderately technical)
* Pipeline module (1)
* the pipeline of objects rendering is new (defines the "way" how the objects are moving from entity in world to set of rendering commands)
* is responsible to prepare meshes to be rendered
* is multi-threaded
* filling of pipeline will be also multi-threaded, in phase of testing and debugging
* Material system module (2)
* objects are rendered using new material system, old one is still present to have the comparison
* each mesh has assigned a material (not rvmat) with material class which is responsible for it's rendering
* setting of material is editable in workbench editor and you see real-time the changes in render
* each material class was written from scratch, visualisation currently as much similar as possible to old render but now we can add simply new features (like PBR)
* huge simplification for filling GPU command buffers, can be easily sorted to minimize changes in command buffers
* all renderable game objects have now representation in material class
* High level rendering API module (3)
* GPU API is DX11 for now (With DX 12 supporting coming later)
* implementation of GPU API now hidden behind rendering API, no one is allowed to use direct GPU API commands
* it allows us to add new GPU API like DX12, XBOX one, PS4...much easier
* Initial implementation done, currently in testing and bug fixing phase (optimization still in progress but looks promising)
In addition:
* GUI manager
* GUI pipeline and rendering system is completely new and different from the one in original RV engine
* GUI layouts will be defined in workbench using graphic editor not by config system (huge improvement for designers)
* rendering works, currently debugging and working on the editor
* In a future experimental build it'll be possible to try it using command line switch (startup switch)
* other notes
* postprocesses were completely rewritten into new system of effects
* more worlds can be renderered in one frame, it allows to create independent scenes
* needed for workbench
* usable also in game to create e.g. mirrors, cameras...
As work on the new renderer continues and we look at our plans for the eventual push to experimental we have several goals:
- Testing partnerships with Intel, AMD, and nVidia to ensure compatability with market leader and average hardware configurations
- Marked performance for gameplay in large cities (Elektro, Cherno, Novod, Severograd, Berezino, etc)
Next up - There has been a good deal of discussion, and questions on exactly how hold breath, lung capacity, and dispersion when characters are tired. Below we have a few example videos with debug data on screen so you can see the specific values.
In the first video you see the user start out stationary - not tired, and begin to hold his breath. With the inaccuracy value falling sharply upon holding his breath, as the character continues to hold his breath and his lung capacity drains - the inaccuracy slowly starts climbing.
With the second video, we have a character who starts off tired (has been sprinting for an extended duration - 90 to 120 seconds of solid sprinting) who takes a knee (supported firing position) as his tired value decreases, his lung capacity increases - and he begins to hold his breath.
Mind you, this is only how it performs now (on 0.57 stable) and this is prior to the implementation of weight and character stamina. That said, we would love to hear your thoughts on the current behavior of the mechanic. Please make sure to head over to the Official DayZ forums and discuss this in the latest Status Report discussion thread!
Finally - the gameplay programming team has made headway on the annoying issue of sounds playing globally (splitting ammo, bandages, etc) and 0.58 should see the issue resolved! If you happen to still manage to repro, please open a ticket at feedback.dayzgame.com!
- Brian Hicks / Lead Producer
Dev Update/Jan
Since there's been some discussion regarding changes in the character zoom mechanic I decided to jump in and explain what are we trying to achieve.
We should probably start by asking the question "Why have a characters-eye zoom in the first place?". It's the old problem with emulating a 3D world on insufficient hardware. The human field of vision (fov) is around 190° and the area where the vision cones of both eyes overlap is around 100°. Unfortunately, most of todays monitors viewed from a regular distance usually tend to cover only 45°of human fov in real life. This means that if you want for target on screen to appear in real-life size you are only able to display around ~1/2 of what you would see in reality, stereoscopically.
And so as a designer you have to choose - Should I display objects in the distance properly but sacrifice the overall vision or set the fov to 100° but deform the whole picture? The trick of Arma is actually not to choose and instead introduce an "eye zoom" instead. This way you can keep the surrounding awareness by setting the default fov to 100°, but when necessary to perceive a depth of field properly occurs (ie. you are shooting), you can "zoom in" to 45°. 
0.57 Unzoomed Eye Vision
0.57 Eye Zoom
But is it ok to force fix a fov on players? We thought not. Not only because 100° fov does not feel right to everyone, but some players can't even physically play with it. (Motion sickness, performance of PC, different monitor setup...). So the FOV slider was introduced and with it multiple problems we are ironing out now.
The most important step was to even out players by moving fixed fov to ironsights. This way you can most of the time play with whatever fov you like, but when the fov becomes a matter of life or death (shoot outs) it is set same for everyone to keep the game fair.
We know that zoomed fov or ironsights must be 45° because it emulates the eye and we stated earlier that 45° is realistic. But what should the unzoomed fov be? It can't be higher than a number the player can set through FOV slider. (This way would going into iron sights actually shows the unzoomed picture which is definitely not something you would desire). So the fov of ironsights should be also the the smallest fov we allow players to set by the fov slider.
We decided to set range of fov slider from 60° to 90°. 
0.58 Eye Zoom
It's important to keep in mind, that double pressing + or - extends it to 45° or 105°, so the range is not so small as it might appears. It also doesn't matter what is your current fov - double pressing + key will always set it to 45°. This means you can quickly switch between observing surroundings and focusing on objects "modes", while being able to play with your prefered fov for most of the time. I belive this descision helps equalize players and reduce fov slider abuse.
Of course all those settings are opened to iteration and changes if they prove to be wrong, or they just feel bad.
- Jan Tomasik / Senior Designer
Community Spotlight: Super Dan
Hey all,
It's been a bit of a hard decision in selecting which content creator to feature for this week what with all the great stuff produced by players! For this week though, we present to you the work done by: Super Dan
Super Dan has created a good amount of DayZ videos where he showcases plenty of different player interactions as he meets random players across Chernarus. The first video for this week shows the choices players sometimes have to make when finding themselves in a tight spot (it could also be the choices that some players make when they just want to be mean towards others, heh). Nice enough though that Super Dan's victim is a good sport about it all :)
In Super Dan's library, I also came across the following video in which he uses the chance to encorporate a bit of cinematic feel into his video based on the experiences he has with a couple of other players. It's all fun and games until you start outliving all the players that you come across. Nicely done Super Dan!
As the last video for this week, we bring you Super Dan's video “A Normal Day in Chernarus”. What starts out as a seemingly friendly meeting of random players takes a funny turn for one of the survivors as he tries to form an alliance with another one of the guys:
