Status Report -30. June 15
reportet June 30, 2015
[img width=700 height=285]http://dayz.com/files/post/978…2ZKqS1wwdXDrqp_header.jpg[/img]
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
Dev Update/Jan
Community Spotlight: Super Dan
Development Board Spotlight
[img width=700 height=483]http://trello-attachments.s3.a…e/IMG_26062015_165513.png[/img]
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.
[img width=700 height=458]http://i.imgur.com/m9sNC5w.jpg[/img]
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)
[img width=377 height=324]http://i.imgur.com/DVgYcvK.jpg[/img] [img width=444 height=386]http://i.imgur.com/hXuEf4l.jpg[/img]
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.
http://www.youtube.com/watch?v=nxSjqXGpF6M#ws
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.
http://www.youtube.com/watch?v=RbURyZ0s9XA#ws
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°.
[img width=700 height=393]http://i.imgur.com/6JpDaM2.jpg[/img]
0.57 Unzoomed Eye Vision
[img width=700 height=393]http://i.imgur.com/U1ViUlj.jpg[/img]
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°.
[img width=700 height=393]http://i.imgur.com/Bc47rHt.jpg[/img]
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
[img width=700 height=115]http://i.imgur.com/yzLOZlP.jpg[/img]
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 
http://www.youtube.com/watch?v=4U_Q5VL_2iQ#ws
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!
http://www.youtube.com/watch?v=PR9MccSg4LA#ws
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:
http://www.youtube.com/watch?v=q-MBp6sDY_0#ws
Oh, you Judas, you! Best to brush up on your persuasion skills.
As always, if interested in more, please feel free to follow Super Dan via his Twitter and Youtube accounts:
http://twitter.com/xdannyboix
http://www.youtube.com/user/Dannystevo100
Header image credit: Raptorz
- Michael aka SMoss / Community Manager
Quelle: dayz.com
Übersetzung
Grüßt euch,
Da die Entwicklung wie gewohnt voranschreitet und viele auf Neuigkeiten vom Renderer warten, hier nun von Brian Hicks ein paar Worte zu diesem Thema. Außerdem wird Senior Designer Jan Tomasik auf das FOV (Sichtfeld) eingehen.
Dev Update / Hicks
Diese Woche befassen wir uns mit zwei Themen. Zuerst etwas zum neuen Renderer der Enfusion Engine und danach ein paar Infos zu den Mechaniken "Sprinten, Luft anhalten" usw.
Die Spieler die sich aktiv mit der Entwicklung des Spiels beschäftigen, sollten sich bewusst sein wie groß die Aufgabe ist den RV Renderer auf eine neuere Version zu updaten. Die Aufgabe einen Renderer zu programmieren in sich ist nicht groß, folgende Aufgaben machen das ganze so aufwendig und zeitintensiv:
• Die Trennung des legacy-Renderers aus der Simulation
• Sicherstellung das die Trennung vollständig ist und die RV Engine und deren Funktionen in vollen Umfang übernommen wurde
Sobald diese Dinge abgeschlossen waren, wurde der Renderer in drei Grundmodule aufgeteilt. (Achtung sehr technische Ausdrucksweise)
1. Pipelinemodul:
• Die Renderung der Objekte ist neu (Definiert den Weg WIE sich Objekte in der Welt bewegen)
• Ist verantwortlich für die vorbereitende Renderung der Maschen
• Multi-threaded
• Fehlerbehebungsphase
2. Material Systemmodul
• Objektrenderung benutzt das neue Materialsystem, das alte ist zum Vergleich noch vorhanden
• Jede Masche ist ein Material zugeordnet (kein RVmaterial), welche eine Materialklasse besitzt, die für das Rendering verantwortlich ist
• Die Einstellung des Materials lässt sich über den Editor ändern und diese werden in Echtzeit verändert gerendert
• Jede Materialklasse wurde von Grund auf neugeschrieben und dabei wurde versucht visuell es so ähnlich wie möglich zum alten Renderer zu halten, aber dabei ermöglichen neue Features einzuführen (wie PBR)
• Große Vereinfachung für das Füllen des GPU Commandbuffers, kann einfach sortiert werden
• Alle gerenderten Objekte werden jetzt in einer Materialklasse präsentiert
3. High level rendering API Modul (Programmierschnittstelle):
• GPU API wird erst DX11, später DX12
• Einführung von GPU API ist nun hinter der rendering API versteckt, niemand darf direkte GPU API Befehle ausführen
• Ermöglicht das einfacheres Einfügen von neuer GPU API wie DX12, XBOX one, PS4 usw.
• Erste Umsetzung ist eingefügt, momentan in der Test- und Fehlerbehebungsphase (Optimierung noch nicht abgeschlossen, sieht aber vielversprechend aus)
Außerdem:
1. GUI Manager:
• GUI Pipeline und das Renderingsystem sind komplett neu und unterschiedlich zum alten RV System
• GUI Layouts werden mithilfe eines Grafikeditors erstellt und nicht mit dem Config-System (große Verbesserung für die Designer)
• Rendering funktioniert, momentan wird am Editor und an allgemeinen Bugfixing gearbeitet
• In einer späteren Exp. version wird es über die Startparameter zu testen sein
Weitere Notizen:
• Postprocessing wurde komplett neu in das Effekt-System eingeschrieben
• Mehrere Welten können in einem Frame gerendert werden, das ermöglicht mehrere unabhängige Szenen in einem Bild
• So können bald Spiegel und Kameras dargestellt werden
Während wie gewohnt weitergearbeitet wird, haben wir noch verschiedene Ziele:
• Kooperationen mit Intel, AMD und Nvidia
• Bessere Performance in Großstädten wie Novo, Elektro, Zeleno usw.
Nächstes Thema: Die Funktion des Atem Anhaltens, Lungenkapazität und der vieldiskutierten Ungenauigkeit beim Zielen mit der Waffe nach Erschöpfung. Ein paar Beispiele seht ihr in den Videos.
Im ersten Video ist der Spieler ausgeruht und kann daher mit dem Anhalten des Atems sehr genau zielen. Je länger man diesen anhält, desto mehr steigt die Ungenauigkeit wieder.
Im zweiten Video ist der Spieler nach einem 2min. Sprint erschöpft. Der Erschöpfungszustand sinkt mit der Zeit und er kann wieder ruhig zielen.
Beachtet bitte, dass dieser Zustand aus 0.57 noch komplett unabhänhig vom kommenden Gewichts- und Ausdauersystem ist. Wir würden uns freuen wenn ihr uns eure Meinung im Forum kundtut.
Zum Schluss noch etwas erfreuliches, das Gameplay-Programmierteam hat die nervigen Soundbugs behoben, welche global abgespielt werden (splitting ammo, rags usw.) Kann ich mit 0.58 bestätigen !
- Brian Hicks / Lead Producer
Dev Update / Jan
Es gab in letzter Zeit ein paar Diskussionen über die Zoom-Mechanik, auf die ich nun etwas eingehen möchte.
Wir sollten anfangs uns vielleicht die Frage stellen "Warum gibt es überhaupt diese Zoom-Möglichkeit?". Das Problem liegt an der 3D-Simulation auf alter Hardware. Das menschliche Sichtfeld ist ca. 190° und die Zone wo sie die beiden Augen überlappen beträgt ca. 100°. Leider decken heutzutage die meisten Monitore nur 45° des Sichtfeldes ab, dass heißt man sieht im Spiel nur ca. die Hälfte von dem was man sehen sollte.
Nun standen die Designer vor der Entscheidung, ob die Entfernung im Spiel richtig dargestellt wird oder ob wir das Sichtfeld auf 100° fest einstellen und so das Bild verzerren? Der Trick aus Arma ist dabei diesen kleinen Zoom einzusetzen. Das gleicht das ganze System ganz gut aus.
Aber ist es richtig, dass man Spieler ein bestimmtes Sichtfeld aufzwingt? Wir denken nicht. Nicht nur weil es viele gibt, die sich bei 100° Sichtfeld nicht wohl fühlen, sondern weil es für manche ganz einfach nicht möglich ist so zu spielen. So entschieden wir uns für den FOV-slider, welcher den Spielern eine gewisse Entscheidungsmöglichkeit gibt. Dieser sorgte aber für Probleme, da das Verstellen beim Zielen mit der Waffe große Vorteile bietet. Mit der Anpassung im letzten Stable-Update haben wir diese Vorteile genommen.
Es ist bekannt, dass im Visier das Sichtfeld 45° sein müssen, um das menschliche Auge realistisch nachahmen zu können. Aber welche Größe sollte das Sichtfeld ohne Zoom haben? Es darf natürlich nicht größer sein als die vom Spieler erstellbare Größe. Dadurch würde es ja zu einem ungezoomten Bild kommen, was definitiv nicht erwünscht ist. Also sollte das Sichtfeld das kleinstmöglich, einstellbare sein. Wir haben uns entschieden es zwischen 60-90° zu setzen.
Es ist wichtig nicht zu vergessen, dass mit den Tasten + und - das Sichtfeld auf 45° bzw. 105° verstellt werden kann. Unabhänhig von den anderen Werten wir das Sichtfeld so verstellt. So lässt sich schnell vom Modus "Objekt beobachten" und "Überwachung der Umgebung" wechseln. Das sollte dem Missbrauchen aus der Vergangenheit sehr gut entgegenwirken.
Natürlich können Veränderungen trotzdem noch kommen und über eure Meinungen würden wir uns freuen.
- Jan Tomasik / Senior Designer