D.Sim 0.3.0 update news part one: Optimization

Hello,

Here is an update on what I've been working on for D.Sim in the past weeks/months.

This is going to be a bit of a technical post, but the TLDR is: The game should run faster on older machines now, and machines that couldn't play it before, should now be able to.

first of all, I'll be switching from 0.0.x to 0.x.x versioning, for proper versioning, so 0.0.3 will become 0.3.0. This is only a number system change, and doesn't represent like 100 versions or something.

Most time for this update went into four things, so it's still very sizable, although there are some areas that came a bit short due to people I were working with being missing in action.

The three things I worked on are Optimization, Location, the new character, the first mini-game, and a few other features and improvements.

In this post, I'm going over the things I've done for optimization.

Optimization

It's a bit of a loaded word, as it's often a catch all for vastly different things.
In it's purest sense, optimization is making an existing procedure run faster without changing the result at all.

However, it can also be considered optimization when the result is changed, e.g. when it's visually indistinguishable for the user.

But also things like just sanitizing settings or providing fallbacks for older machines.

The update contains a mix of all of those.

I'll try to go into some of them in more technical detail for anyone interested.

• A card hair fallback was added to both characters. While this doesn't look as good as strand hair, it can almost double your fps

• I overhauled the lighting system to only load necessary resources on demand.
  So now, instead of having all daytime lightmaps loaded at all times, only the necessary one gets loaded asynchronously from disk.
  While this doesn't directly increase fps, it saves a lot of VRAM. On graphics that are starving for VRAM, this can make the difference between a slideshow and smooth fps, and it leaves more room for other effects on higher tier cards.

• Lightmap stealing: I made a system where higher level of detail objects steal the lightmapping of their parent. This means those objects no longer need any space in the lightmap itself which reduces VRAM, but also more visual fidelity (things like the clothing rack or books changing shade when moving away are fixed using this technique)
  I don't know why this isn't the default in unity, instead of having to hack it in.

• I further increased lightmapping efficiency by sanitizing geometry and normalizing settings, so much less maps are used overall for each daytime scenario per scene. Another sizable reduction in used VRAM

• The particle system that caused a bigger slowdown was optimized to no longer do that

• By using better settings for on-demand asset loading, loading clothes has been optimized. (on my machine from more than 5 seconds to less than 1). As before, on the loaded clothing is in memory, so the amount of clothing options for a character can be as big as hard drive space allows (I'll eventually include clothing items making for modding)

• There were some general updates to reduce the overhead of functions that are called very often (this is just plain code optimization stuff. Nothing groundbreaking in there, but every fraction of a millisecond count. I try to not overdo mircro optimizations, and only act according to what I see profiling the runtime)

• Similar to the above, multithreading has been improved in several areas to better utilize the CPU.

• Also, I reduced the update frequency of my animation suite by shortening the execution path for common scenarios. Essentially, the system is capable of blending animations and settings seamlessly. However, blending is more expensive than simply settings, and most of the time, the blending is at either 0% or 100%, which means that the result is the same as setting at those point, and only require blending in the short times in-between

• This one took me the longest, but I had planned it for a while: Mesh and Material merging.
  For a graphics engine, the more things it can hand off to the graphics card at once, and the more the graphics card can do in parallel, the better.
  For multiple objects with different materials/shaders/textures, this means that the context has to be changed, from overhead of sending instructions to the GPU to it having to do them one at a time.
  Now, the way my models work is that they come in over 20 submeshes, each with their own texture, so there is no way for automatic batching to combine them.
  This means there is a lot of overhead drawing a character like this, from context switches to looking up new textures in memory, to shader variants.
  To remove this, I made a tool that combines the submeshes and materials into one big mesh with one material. To do this, textures have to be put in texture-atlasses and the shader capabilities had to be extended to allow for different values across the body.
  There are some existing plugins for this, but they don't reach the requirements I needed.
  This also saves a lot of VRAM and make it easier to manage in the end.
  A lot of work went into backwards compatibility, so I can always switch back to the old mesh if I need to change textures, and then bake them again.
  I implemented this for any shader, but specifically for the ones I'm using for skin, as well as the main one I use for architecture, so e.g. the clothing rack is now combined, too, as before each item in there had its own set of textures.
  While the texture atlas textures are of course bigger than individual, compression works much better on those, and it costs the GPU no time to switch, as everything it needs is in that texture.

• I optimized the room in several parts using this combiner to reduce context switches (set pass calls), as well as for the new locations.

• While trying to fix the ambient shadow issue, I managed to speed it up by using better injection methods (however, the shadow is still overlapping unfortunately, but I'll fix that eventually)

• I optimized reflection probes to use less VRAM as well
  

Overall, the gain in FPS will be dependent on the system you're using. If you already got goof fps, the difference is not going to be a lot, as all the area's I worked on were bottlenecks for slower systems. However, it will open the possibility for more characters on screen, etc.
Even with a fast machine, the biggest difference is made by using card hair.

My next update is going to be a bit less technical, talking about improvements and added features. After that, I will go into the new character and locations.

Have a great week,

hachi