Weekly report [#28]

Discussion in 'Devblog' started by Karl, Apr 4, 2019.

  1. Karl

    Karl Администратор Staff Member

    163
    844
    343
    Oct 2, 2017
    It is Friday and we are back online with our weekly 28th news report!

    We start with the ongoing works on the Necromancer, then we will discuss animations and optimization, and, finally, a little bit about the UI.

    Here we go!

    I The necromancer

    Currently, we have reached the texturing stage. And here is what we got:

    [​IMG] [​IMG]

    The next step is aging with the help of materials with transparency (masking) simplified in terms of performance requirements. We will use it to tear hemlines, sleeves, and the collar.

    Apart from that, we have a prototype of the 6th final level when the necromancer, who is completely devoted to the traditions of the school, in exchang, is rewarded with a rather heavy armor pieces but from bones.

    [​IMG]

    The challenge the school offers is that, on the one hand, diving into the black magic drains life energy from the character and takes its endurance. And on the other hand, it rewards him with heavy armor of darkness.

    The necromancer will have the lowest value of HP while having the highest combination of Physical and Magical defense.

    II Animations of a one-handed weapon and the obelisk

    We are approaching animations of the obelisk that serves as an alternative to the shield for weak but intellectually strong characters.

    There will be 2 types of obelisks: a scepter and an orb. Here is an animation of holding the orb.

    [​IMG]
    Hit 02-08


    [​IMG]
    Hit 03-09


    [​IMG]
    Hit 09-03


    [​IMG]
    Hit 12-07


    III Special attack with a one-handed weapon from the 3rd person view

    In Report #26 we showed an animation of a special attack with a one-handed weapon and free left hand from the 1st person view. You may find more details about the attack there as well.

    And this is how the animation looks like from the 3rd person view:

    [​IMG]

    IV Optimization

    This brings us to the creation of LOD for the armor.

    Any work on optimization begins with the assessment of how relevant future work is.

    It is intuitively clear that LODs are necessary, but the relevance of hi-end optimization for, for instance, disabling normal textures for LOD_2/LOD_3 is questionable.

    Let's begin with the most simple case.

    Look at tests with armor with the following settings:

    LOD0 - Original
    LOD1 - Percent Triangles 50%; Screen Size 0,15
    LOD2 - Percent Triangles 25%; Screen Size 0,08
    LOD3 - Percent Triangles 12,5%; Screen Size 0,05

    For reference. Percent triangles is the level of simplification, i.e. 12.5% means that the geometry has been simplified by 87.5%. The screen size is the distance where the simplification is enabled. The higher the value the earlier the respectful simplification will be enabled.

    The current settings were chosen for the best quality-price-ratio. The transitions occur on adequate distances. It is rather difficult to spot them in the full-screen mode.

    Here is the scene of the heaviest part of our world (cell x7y1) with the number of various armor pieces about 500 items.

    LODs Off
    Frame ~19,8 ms
    [​IMG]

    LODs On
    Frame ~17,9 ms
    [​IMG]


    The results speak for themselves: extra 10% to the frame rate. Basically, this is what we wanted to show you.

    Now let's look at visualizations of LOD with the help of color-coding.

    LOD0 is white, LOD1 is red, LOD2 is green, and LOD3 is blue.

    LODs Off
    [​IMG]

    LODs On
    [​IMG]
    Let us now turn to a more complicated question: shall we simplify the material by removing the normal map from it when rendering the furthest LODs?

    Normal mapping is an example of the most basic relief texturing. On the one hand, the render of materials with applied normal maps (so-called 2.5D materials) is cheaper. On the other hand, such maps are the heaviest during render. For instance, at 4K, a single normal map requires 22MB of video memory.

    If all modern video cards are equipped with 3+ Gigabytes of video memory, then it is still possible to load such texture in video memory. The bottleneck is the performance together with the frequency of video memory and bus width.

    Material instances for LODs with disabled normal map.
    Texture memory - 1882 Mb
    [​IMG]

    Material instances for LODs with enabled normal map.
    Texture memory - 1955 Mb
    [​IMG]
    With such optimization, even though it seems logical, we got the opposite result. The reason is that the removal of the normal map from the material instance of armor for far away LODs essentially results in re-compilation of the second material even though it is the same material as the first one by 99%. When one doubles the number of materials, it only increases the usage of video memory.

    When making LODs for the armor, we use software which recently was only available to very big studios due to its high price (Simplygon). Due to several reasons, it became almost free for UE4 users. This almost halves the amount of work for 3D artists since it makes automatically acceptable geometries not only for Static Meshes but also for Skeletal Meshes.

    It's not that simple: the LODs for the majority of armor pieces have to be made manually. These are changeable areas used in the modular system, for example, to tuck trousers into boots, so that nothing pops out. For LODs of chest plates and robes at mid-range, one has to either manually set up the clothes physics or purchase the professional version of the program and compile a custom version of the engine with it.

    V UI

    Since the mechanics of capturing a castle by a guild was available in the prototype and we made a huge abandoned castle for the Alpha stage, it is time to refresh the UI for this procedure.

    [​IMG]

    VI Conclusion

    The day is coming when we invite the ROG club to Private Test Realm (PTR) with pre-Alpha. At the current moment, we are finishing the test of the combat system 2.0 for PvE. To be specific, when blocking with a shield, the hit detection whether it is head or torso does not work correctly. In PvP, everything is fine with this function.

    [By the way, ...]

    We would like to remind you that there are two types of shields, and, while a player cannot squat, the shielding mechanics work based on these rules. There is:
    1. a regular shield (buckler). It only covers the torso, i.e. same body parts we take into account when doing hit detection;
    2. long shield (covers both head and torso).
    Both shields protect from strikes from the frontal side only.

    At the same time, it is forbidden during blocking to:

    1. use the right hand. There will be two types of buffs which will allow hitting through blocks. They will be available to the Armorer and the Gladiator;
    2. leap out of the way;
    3. it is completely forbidden to jump and leap with the long shield (even when not blocking);
    4. there will not be sprinting with the block. It has been replaced with hitting.
    ***

    More details about the preparations are in the updated status.

    Now about registration for Alpha. We planned to give away the keys on 31/03/2019. However, we moved the date of the giveaway to sometime after the competition. The reason is that about 10% of the initial amount of people re-registered, which is slightly sad.

    That’s all for now!

    It’s Friday evening - ROGgoms up, friends!

    Kind regards,
    The team of Reign of Guilds