Weeks of 2/14-3/1

It's been too long since my last post, but I don't think this one will be much longer for it [editor's note: nope. This is a long one]. It's not that I'm not doing much work, I am (though I did slow down a bit to prevent burnout). Mostly, I've been doing redoing monotonous work and learning very few new things. As I'm writing this, I'm finding out about more of this work I need to redo. This is a bit exhausting.

Ever since my last post, around three weeks ago, I've only been able to produce two complete assets. A rug and railing for the interior. Both should add a bit of visual spice. Pretty boring to make, but I at least got to do some cloth sims. It's nothing new, but it is outside of my usual pipeline at least.

In addition to those assets, I've also been working on creating a material for the guts of the monster. Elias is sculpting some guts right now, so I don't yet have a mesh for them yet. But because I'm making the material procedurally, I don't need the final mesh to make the material. I wanted to use one that would roughly match the organic, curvy, bulbous nature of internal organs, so I settled on using the stuffed bunny mesh from the beginning of the year. As an added bonus, a lot of people don't like looking at a fleshy, gutty toy rabbit and sometimes have some visceral reactions to it. To complete the look, I drew on a little face with Substace's stitch brush. It's just icky, I love it. There are still many changes I want to make, and I'll probably vary it per organ, but this is what I have for the time being.

The primary timesink lately has been caused by file management: things don't save, things crash, things are overridden. It just happens, but right now it all seems to be happening at once. Find Emma's programming team decided to refactor the project, and for good reason. The file system was poorly organized, and very few things were named correctly. This is certainly my fault, to some degree, as I did the majority of asset imports. In my defense, though, I was instructed to use camelCase at the beginning of the project and I had no instructions for prefixes. This changed, and everything had to be renamed in PascalCase with UE standard prefixes. And as far as the file organization goes, that was also the programmers changing their minds. I don't blame them really, they're learning and they didn't get it perfectly right the first time around; that's normal. But it's still unfortunate for me, because it meant a lot of work with no apparent progress.

Renaming and reorganizing wasn't nearly as painful as it could have been. Conlen was learning to script with Python, and he went ahead and made us a script to do most of the renaming automatically. This still required a considerable amount of prep to use each time, but far more efficient than doing it manually. It was a real lifesaver. Unfortunately, along with restructuring files, we also restructured the Git repository. Rather than having a branch per person, we now have a branch per task (e.g. level edits, 3D assets, etc.). I was catching a lot of flack in the past for solving problems by creating new branches, which may not be proper form, but it worked. But now I'm not allowed to do that. I would be fine with all this, except that the restructured repo is a garbage fire, at least on my end.

I don't want to start ranting, so I'll just say that I'm not able to use GitHub due to a series of indecipherable errors. The programmers haven't been able to figure it out either. I've tried everything short of actually spending time learning how git works. That's my last resort, and I hope I don't have to do anything so drastic. I'm kidding of course, I will read the manual. Some day. Anyway, these issues have cost me days upon days of work, and redoing old work. That's really frustrating, but the programmers are promising a fix by the end of the day.

A few months ago, I started working on an idea for a side project. I was just beginning to dive into tech art. I was looking at a stained glass window, and I began to imagine it not only in a game, but containing the game. What if you could find a stained glass window in a game, and then interact with it, play it. That has massive gimmick potential, I think. It also has some interesting technical hurdles too.

My current approach goes like this: there is a simple 3D scene. This scene is being viewed by a pair of Scene Capture 2Ds (cameras that outputs a texture) which are in the same spot with the same view, but they are running different post processes. One outputs a greyscale, the other color. They are both getting object outlines by using a sobel operation with depth and normal information. The greyscale post process outputs only these lines, while the color outputs the lines as well as the base colors of the scene.

These textures are fed into a surface material that goes on the window mesh. The greyscale is used for height, metalness, and masking out the light passing through the window. The colored output is of course used for the base color of the window.

I have two versions of this material (below), which differ in the way that they simulate translucency. One (left) works like you might expect, using opacity to let you see through the material, duh. This technique creates issues, though. As you can see from the shader complexity viewmode below, the transparency is a lot harder on the GPU, especially when I have a room with up to a dozen of these windows in a far more complex environment, as I hope to create later on. Plus, it's ugly. Despite being at .99 opacity, you can still see through it far too clearly. I'm sure I could pretty it up if I spend time understanding material domains, refraction, etc., but I'm 90% sure that doing that would only tank performance further.

The other version of the material (right) fixes this issue quite elegantly I think. This uses an old technique called cubemapping. I had never noticed the use of this technique in games until I was pretty deep into development. I first noticed it's use in Spider-Man PS4, which I was able to find quite a few articles on. It's really fascinating, and I only partly understand the math behind it, but luckily I don't really need to, as I can draw from the code in the InteriorCubemap material function in Unreal.

I initially used the cubemap to illuminate one UV point. This was partially successful, but not compared to the more standard way of doing things (using a Scene Capture Cube with it's UVs manipulated by the cubemap). I'm blending that output with the scene capture stuff.

There are a couple other things going on in the material, including some grunge around the lines, some faux refraction to suggest surface deformations, and a voronoi texture overlaying the lines as a rough approximation of stained glass construction. I would particularly like to improve the latter. Ideally, I could make the material procedurally draw lines between the outlines - in other words, making the construction of the window based on it's contents. That would be more accurate to life, but with my current skillset, I don't know how to begin approaching that problem, or if it's feasible to do real-time.

At one point I had this demo playable to a degree. The player posessed a static camera and controlled a pawn with in the stained glass scene. You could see your little starter content chair mesh move around on the window. It was cool. But the goal is that the player will be able to toggle between controlling a character in the "real" world (the PBR environment containing the window) and controlling a character within the window. I began doing that, but halfway through I realized I was doing full-on programmer stuff, and that caused me to vomit violently, so I had to stop. I'll fix it all soon

Final note: I'm going to a *nude* figure drawing session on Sunday. That'll be fun, and good for artistic development. I do some life drawing every once in a while; just imagine there are some images of that here.