Before Start Modding

*To be updated

This is an old game, and when we dive into deep modding, we will came across a series of limitations that will be discussed later in this post. If your idea is simple, these tips may be less or even not noticeable. However for bigger projects with ambitious ideas it may have a big impact.

It's critical to follow some rules in order to have an optimized stage. Even if the mod don't make big changes, it may be benefited from it, as optimization is always welcome. Difficult mods are an example of that, with dozens of enemies on screen it can push the limits of effects and particles rendered at the same time, leaving little room for stage modifications like EFF for example.

This following info is directed to modders who intent to make improvements, custom stages and other major modifications. Take it with a grain of salt, as these are recommendations for the maximum efficiency. Sometimes the balance of return/effort may not worth it, it depends on the scope of the idea. But when starting something from scratch, following some rules may be beneficial for your project on the long run. Some of the limitations are listed down bellow.

The 6 Light Limit

I think everyone at this point is aware about it. But if you're new, what you need to know is that every model can only interact with 6 lights at the same time. More than that, and the model will not react to any of the new lights. The user Zatarita researched about the possibility of setting a priority for these lights, which can be read in an old Discord conversation. I never tested this priority setting so I can't talk about it, I just try to always keep my models under the 6 lights.

I've been using a troubleshoot tool for a long time, which is a modified PRL 412 that was made with this purpose in mind. The PRL is a weapon that can have two light stages, so it fits the task perfectly. We can hold the trigger and look around, to easily identify the problematic areas. You can use it to know what regions require fixes, by isolation of the particular model, SMX tweaks or even reducing the range or the total number of LIT lights. Taking my weapon as reference:

Cyan Blue: Means the model has two or more lights left before overload.

Dark Blue: Means the model has one light left before overload.

Nothing: Means the model is already overloaded, has interactions with 6 or more lights or is too big. Yeah sometimes creating a large model can make it unable to properly interact with lights, even when is under 6 lights. I believe that some of the out of range and disabled lights still have some kind of interaction so the model gets glitched. I also like to use scale 1.0x for my models.

SMX Mask

Is possible to tweak how many light interacts with the model by editing the SMX parameters. Please note that the SMX can only mask up to 32 lights (0-31) so any light after it will not have the possibility of being disabled for a particular model. Light entries that are Leon only, Enemies Only, and similar should be always at the end, leaving this possibility for the other lights that affects stage for example.

SoP SMX Tool

Keep in mind that some values for Offset[8..11] can restrict certain lights even if they are enabled in SMX. For ETM, I still couldn't figure out a way of masking the lights with SMX as we do with SMD. Seems that there's no flag that reaches the stage while avoiding ETM.

In general tissue is very straight forward, it can be avoided by following this simple rule.

SAR and Enemy Weapons

For some reason the enemy weapons are recognized in a different way and SAR has no effect over them. This may cause it to remain lit while the enemy bodies gets darker once in the SAR triggerzone.

LIT Groups Transitions

The LIT file can have multiple groups that can be called for different situations. Imagine an exterior area and then the player walks to a interior. What happens in most newer games is a smooth transition in order to blend gradually both lighting values. But here there's no fade at all, and we'll see the differences immediately which feels uncomfortable to the eyes. This is a something I haven't seen a fix yet. I usually just use it to tweak the draw distance when needed.

The 3,5 GB RAM Limit

This is another issue that is very simple to avoid. Just keep the room under this value (with some headroom for menu and examine screens) and the game should not crash.

Masking models with alpha is a good way to mimic high poly models with a efficient low poly model. It's useful for tree branches, vegetation, fences and complexity in general.

It's recommended to merge the alpha textures with their counterpart when possible. This way we end up with only one texture instead of two. In the .mtl "map_d" we can use the same texture number, it also allow us to reuse the texture number once for the transparency map in add a new texture.

There are multiple compression types for textures, but the most used are: DXT1, DXT5A and TGA 32 RLE.

Texture Packs

Local: The textures are stored in the pack files. Some .pack files are loaded only when a particular event is triggered and are local. It can be browsing the movies in the menu, loading a room, or even spawning an enemy, these are local texture files.

Global: Other .packs are always loaded in memory, like the ones responsible for the fonts and core effects of the game, these I call global texture files.

Try to add textures locally rather than globally. It's not recommended to use 07000000.pack and similar to store things that are only going to be loaded for a single or a fraction of the rooms. Even Leon Face textures should be in the Leon pack files, because when playing with other characters the Leon textures will be occupying precious space in memory.

This will of course increase the amount of space used by the game, so it's a double-edge sword. For me at least, the extra size is justified by less memory usage. The storage nowadays is almost infinite, but the amount of memory the game can use has a 3,5GB cap. This is related to a series of crashes that can happen when playing with HD Project combined with dlls, and other demanding mods.

I don't recommend using master ITM or ETM, use it just for testing and then for the final version of your room, make sure to include only what's really needed. These master files requires the textures to be in the global pack files, which will be loaded for every single moment of the game even when nothing related is present, even in the menus.

Side loading files also increase the memory usage, so try to merge all possible files inside the .udas of your room. Files like SMD can increase the memory usage due to its big size, so try to merge it in the .udas. You may ask then why I'm still sideloading in REvamped, that's because it's faster and convenient to work that way, but to squeeze maximum efficiency always merge and avoid to sideload when possible. Only the necessary files like events.cfg and other similar should be in the sideload folder.

SMX Hierarchy

This is very import to understand when dealing with vegetation, usually the edges of the masked vegetation show transparency artifacts. Using "Offset 8...11 = 0x8" and setting the blend in "ColorA = 0x4" can really improve these artifacts at cost of some aliasing.

EFF - SMX Issues

Sometimes we'll see billboard trees in front of each other and it creates an undesired side effect, the edges of the branches can show artifacts. Fortunately these can be replicated as SMD so they can have the hierarchy fine tuned, the wind movement can be replicated by using the SMX swing parameters. Down bellow there was supposed to be an image showcasing it, but the .webp compression ruined it.

"Imagine transparency artifacts here"

The Locked Camera Problem

The reasons for this issue still a mystery for me so I don't know exactly why it happens, but seems to be another limiting factor for big scope projects. Let's take my Main Village Sunset as an example, that room was heavily modified. The area was a playground where I could learn new things, but also discover this issue. You can check more info about this room here.

The room features about 1100 vegetation models all manually placed with individual SMD entries. It happens that after a certain number of entries, I realized that the camera got stuck when aiming, precisely when facing the part of the room containing most of the geometry.

But the reason it felt strange, is that I've modded other rooms in the past, with higher poly count, which did not shown such side effects. I had the sewer room ported from The Evil Within 1, with more than 1,4 million verts and had no issues, of course after a certain point the game can crash and so, but nothing like a locked aim. So it's not about poly count but something else.

I don't know exactly what makes the game behave like that, but I supposed to be some kind of restriction, a limit that affect how many things can be rendered at the same time. Tried different things, memory allocation codes, CNS editing but no success.

Interestingly using the CNS not to increase, but instead reduce the number of simultaneous effects, resulted in an small improvement in the aim. This improvement was marginal because as soon as the draw distance was set to max the game got back to the locked aim issue.

Something makes me think it is related to ESP (effects), but it gets confusing because as we will see, other files seems to influence the situation too. Perhaps it's not only EFF although it has a direct impact.

To troubleshoot the room, I've made a LIT/SMD setup that got me in between the totally locked aim and the normal aim. It happens gradually, like if it there was some sort of queue, that once empty allows the aim to move again. The delay of effects when continuously shooting groups of ganados with shotgun for example, has some similarities with this problem.

Back to the test my aim was moving, but like a slideshow. This was the ideal scenario to check if other files could have influence, if yes then they could be optimized and give the game some headroom. A fine tune was started file by file.

What I found was that basically everything counts and has an I impact on performance! By removing some of the entries of various files resulted in smoother aiming, which means that yes, they interfere.

I believe that nothing is compute-free, and everything have a cost to run: EFF, LIT, SMX, SMD entries, everything counts, even the disabled ones!

The Optimization

The EFF is a file that can easily overload the game so we should start by it, working with EAR to only leave effects that are strictly necessary using 0xFFFF. The local effects could use EAR to be toggled only inside the radius they can be seen.

Some effects are more expensive to run than others, as examples of costly effects we have the heat effect, multiple billboard trees, the rain drops in the lake margins from r11b (two in the area), the water pools from r205, the Main Village smoke, etc. It worth mentioning that any enemy plaga, constant hit effects using machine guns, torches, explosions, and any effect that rely on Offset[264..267] = 0x1 being continuously generated, are among the heavier effects to have in a room. When combined it can be really challenging to make it all work, without having something broke before the bell rings.

"Wait... My camera!"

Unused LIT entries should be removed, not disabled, and depending on the type of lighting it may be expensive to run. For example the custom projected flashlight based on TEX is more expensive for the game to run when compared to a regular type 2, I could check it during this experiment. We should always create our rooms with the least things possible. So entries that are not being used should be deleted (not disabled).

The unused SMX entries were also removed giving the game more headroom (from 120+ down to 40~). And finally the empty SMD entries were removed. The models were merged using the least possible number of .objs. The number of ETM objects spawned in a room like doors, ladders, and EM bear traps, explosive traps counts to this limit.

After the optimization the aim kept broken, but much better than prior to the cuts made. Another thing I've noticed is that the number of meshes directly impacts on how the game will run. Not to be confused with total poly count, but instead individual objects.

I explain, when we import the model in our 3d software it is presented in multiple layers, these layers are costly to run if exported that way. Objects with multiple layers using the same texture should be merged. This helps to improve performance, size, and avoid this infamous problem.

I've compared a single vegetation model which was 1100 times placed in the room. Using a single sided model is the lightest approach, but sometimes using Offset[3] = 0x2 in SMX to make it double sided don't show good results. I usually like to clone it and then flip the polygon faces, visually it is better.

The only issue with this double-sided approach is that it is expensive to run, and we have double the poly count. We can export it as a single mesh to have some performance gains. For this particular model the size of the obj moved from 7kb to 5kb.

This change may seem small, but reflected on hundreds of models, it was able to increase 3 FPS which is 7% more. Changing the precision while exporting seems to produce smaller .obj files however the repack seems to generate bins with the same size, and performance remains the same.

In my testing the game moved from 41 to an average of 44 fps (7%). Again, this may seems small, but remember this was using a very simple model with less than 100 vertex. The same logic applied to a big model can result in much significant gains. The Method 1 seems to be the most benefited from it. Keep in mind that exporting models as one single mesh will not preserve the individuality, and consequently the editing possibility in case we want to change it in the future.

I only recommend going for it to save resources, if the room is already too heavy to run, or if we don't pretend to edit the model anymore. This individuality is specially important for vegetation, where the bushes are next to each other and they overlap. For objects like in r107 where we have a bunch of wooden boxes far from each other, I think that merging them has no problem, as they are far from each other and can be detached easily during future edits.

I've also did some tests in r111 which is the rainy variant of the Village. The extra rain effects make it easier to get to the overload point. Some of the water effects like the one ported from r11b (lake night) are very expensive to run. There are also extra enemies and plagas that makes this room more challenging to run, even without an active fire, smoke, bloom and heat effects in the center of the Village.

In conclusion we should always optimize our rooms to be under the limits, remove unused entries, and any waste that is not needed. The better we build it from the ground up, the less headache we'll have during the final stages.

ESL Desync

Each Esl loads enemies for a specific number of rooms. There's an issue when we insert a new room in between a door warp, breaking how the rooms are ordered by default. For example, warping from r100 to r11c, then coming back to 101 will break all the enemy spawn in the village, despite it's the first time entering the room, crazy huh? This can also break the enemy spawns for subsequent areas, and even crash when the next ESL is about to get loaded (tested Del Lago ESL transition).

There are a few ways to avoid that, the first and more simple is to use the r22c Shooting Range room as a bridge between other rooms (Credits to Mr. Curious). The other way is to sideload the same ESL in the new room, then get back to the next room normally loaded. However my tests shown that warping from rooms ending with numbers to rooms where the last digit is a letter e. g. r100 > r11c can still break ESL even when using the sideload trick.

St6 ETM Persistent State

For the moment the testing stages which uses the ST6 folder have an ETM bug. It happens that if we break any of the ETM it will not reset state after reloading a checkpoint. These rooms could be very useful for modders if not by that.

Unfortunately no one has found a way to get around this limitation. This is a persistent state that can only be fixed by restarting the game, even going to the menus do not fixes the issue. So beware before using them as they cannot deal with any breakable ETM.

To be continued...

REvamped Project

Search This Blog