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
- 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
* 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:
* 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:
* 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.
- 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!
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!
댓글 없음:
댓글 쓰기