Update!

Hey guys,

Earlier this month, I'd talked about my plans to add some new content to the game, and to see about optimizing some things for you. Well, plans changed somewhat. But with good reason!

Someone had requested I get dynamic bones up and running again, so I started to work on that, and made a little progress, but then I thought I should experiment with joints, thinking it may be beneficial to simply replace dynamic bones and their colliders with rigidbodies and configurable joints, because those would not only be able to collide with and interact with your hands, but also with the world, and any other part of your body. That however turned out to be a project for another day because it will be fairly complicated to set up.

So I dropped that for the moment, and began figuring out how I was gonna find all the dynamic bone components on the character models when I loaded the scene with them, so I could extract the list of colliders and map them to the hands.

One hiccup here was that when you tell Unity to load a scene, it doesn't actually load it till the next frame, and I'd have to wait till the load it complete to attempt to access the heriarchy, but I got some suggestions on how to work around that.

However, as I was working on this, I realized I may have had a bug in the previous build of the game. I think I may have been loading the house and characters into the scene twice. I'm not certain this was happening in the build, but it was definitely happening in the editor, so I added some code to check to make sure those scenes were not already loaded before it attempts to load them again. So if you notice a drastic improvement in the framerate in the next build, that will likely be why.

After I worked on that, another thought came to mind. There's a feature I've been keeping secret that I wanted to implement at some point, but in order to do so, I'd have to upgrade the game to the latest version of Unity, and previously my attempt to do that had failed. I don't recall why exactly it failed, but I think it was because I thought I needed to use OpenXR and OpenXR doesn't support the Index controller finger tracking yet. Or perhaps it was an issue with post processing not working correctly. In any case, there'd been several updates to Unity since then, so I decided to give it another shot.

This turned out to be way more work than I'd anticipated though!

The first issue was it took HOURS for Unity to reimport all the assets. And then it decded to do it AGAIN for no reason when I was re-importing the SDKs.

Then half the lightmaps were corrupted. I still need to rebake those.

I also had to switch from single-pass to single-pass instanced rendering, because the former was no longer supported. Single pass instanced rendering is more performant, but shaders have to be written to support it, and my skybox and water shaders were not. I have found a workaround for the skybox shader, but the RED_SIM water shader is still messed up, so I may have to replace that.

At this point however, the game was working in the latest version of Unity, with single-pass instanced rendering, and with the same post-processing as before, and with finger tracking in SteamVR.

Oh, I forgot to mention... I didn't keep any notes when I first installed all the SDK's for Hurricane VR toolkit and Steam VR, and so I had a hell of a time figuring out what I'd done and re-recrating it and setting up my menu scripts and such to have the right object references and things. This second time around however I kept detailed notes, so that if I have to do this again, the process will be far easier.

Anyway, once I got all that done there was still one big problem. I discovered that you could no longer teleport if you shrank down to 0.1x or below. It took a long time to debug this, and I had to dig through a lot of code in the VR SDK and print out a lot of numbers to the debug log and go back and forth in and out of VR testing it to see what was going on, but I finally tracked down the issue, which had to do with the latest version of the SDK calculating the capsule collider for the player differently than it used to, which was putting the player's feet into the ground essentially.

With that resolved, that brings us to today, and I still have to re-bake the lighting, and I haven't yet added any new content worth making a new build for.

So you're probably wondering, why did I go to all this effort? I mean, I don't even know if this has improved the performance significantly, though as I said, single pass instanced rendering is supposed to be faster, but I could have turned that on with the old version...

Well, the answer to that is somthing that was recently released to the Unity store that I've been testing, called Fluffy Grooming Tool!

https://assetstore.unity.com/packages/tools/modeling/fluffy-grooming-tool-193828

Fluffy is a fur shader unlike any other I've seen previously. Other fur shaders look terrible in VR. They work by creating 8-16 copies of your avatar, each slightly larger than the last, and then they apply what is essentially a noise texture to each shell, with transparency. Imagine if each hair were made up of sheets of paper stacked one on top of another instead of being one solid object. That's how those fur shaders work. And they look okay, on a flat screen, at a distance. But in VR they're just a noisy mess up close.

Fluffy on the other hand creates actual polygonal hair geometry, which is affected by wind, gravity, and motion, and can be painted and groomed from within the Unity editor! It can either create individual hairs, or it can create hair cards which use transparent textures to represent multiple hairs. Hair cards don't look as good as individual hairs of course, but they require a lot less polygons.

To give you an example of how many polygons we're talking, the sample pink monster they show in the Fluffy videos has ~20 million polygons, partly due to each hair having multiple segments so long hair can bend more realistically. That sounds like an impossibly large amount, but in a test on my 3080 I was able to view that character in VR at a solid 90fps. This got me thinking that with careful use and optimization, it may be possible to have detailed fur in my game. As a toggleable option of course. You'll normally only have one or two characters onscreen at any time, so theoretically, it should work. And even if fully modeled fur is not yet feasible, the tool still has the option for those hair cards, which are definitely performant enough to use, even for those with lower end graphics cards.

Of course, Fluffy requires the latest version of Unity to function, so I had to upgrade so I could experiment with this tool and see how far I can really push the graphics of this game! Being able to test the fur early on will also ensure I don't accidentally use some effect which is incompatible with the fur shader. For example, the water shader, or Mudbun might prove incompatible with it. But only with testing will I know for sure.

And just to reiterate: The fur will be a togglable option whenever it's implemented. So if you're concerned your card won't be able to handle it, don't worry, you'll be able to turn it off. I may eventually look into Nvidia DLSS as well, to see if perhaps it can be of help here. If the game can render the fur at even 30fps on a lower end PC, DLSS might be able to boost that to decent framerates for VR.

Back on the subject of bugs, there's one more I forgot to mention: There's an issue with scaling the player down that some of you may have noticed. The text on the in-game menus becomes corrupted. I'm not sure exactly what causes that, but it seems to be a bug with Text Mesh Pro. I came up with an idea yesterday for how to fix that though. I think I may be able to render the menus with a second camera after rendering the main scene. This second camera would not need to be scaled down, and so the bug should not present itself. I don't know when I will get to implementing this as it's a minor issue, but I just thought it worth mentioning.

Anyway, I think that about covers it for this update! I'm hoping to have a new build with some new content, and hopefully working dynamic bone colliders, and maybe better performance in February. However, this week I have to get my covid booster shot, which is probably gonna knock me on my ass, and then two and a half weeks from now I'll be at Anthro New England in Boston for four days. So that's gonna cut into my available dev time somewhat. But I made a lot of progress in January, so I'm hopeful I can get most of what I meant to do this month into the game next month and put a new build out for you around the end of the month!

See ya then!