Ask me anything

I've seen a few people bring it up. I am assuming you're running a laptop that's like 1366x768. The UI is designed for 1080p, is why I bring it up.

I will look into it. No promises or timelines.

You might be interested in the epilogue for the Frozen project. We're not there yet, and we've got a fair bit of animation yet to go before we get there, but I'll just say that you manage to guess some of it. Not everything you guessed is there, but I think you'll like it regardless.

I know I had thoughts to include it in a few places, but I can't remember if the logistics ever worked out. Stuffing the ladies airtight is sort of the overriding priority in the project's tone and theme. Human bodies are big and bulky and take up a lot of space. Getting all of those bodies in there can be a challenge.

Depends on if I can come up with more interesting ideas for the characters!

It's still in development. It's being put together entirely on-stream. You can see the latest stream WIP over on the on-stream WIPs page.

Do note that people are uploading these videos on sites against my express wishes. It's not that I don't want the videos shared publicly - I mean, I officially host them myself, free for the public to view. It's that I don't want them to be removed from their context - which is that they are unfinished, on-stream projects, and not meant to be taken as finished releases.

I get a lot of people who find these videos uploaded on these websites, stripped of all context, and then get mad at me for "releasing unfinished videos." Nevermind the fact I didn't even upload these videos, but these videos were never meant to be considered finished releases. They are unfinished, by design. They're work in progress videos. But when people just reupload these videos and strip that context, people don't understand that.

We've taken a detour from it to work on the Witcher video that will hopefully be released April 1st. Tomorrow's Saturday stream will possibly see us return to it, since I suspect it will be the last stream needed to finish said Witcher video.

I have no idea what video that is, and I can't find any correlation to the information given to the URLs that spankbang uses, so I can't figure it out.

Currently paused as I untangle the absolute mess that is the on-stream and off-stream projects colliding. You can read the blog post about it for more details.

"Will you please add more updates to the Shepard visual novel?"

Unfortunately, probably not.

The core of the problem is the fact that lips aren't just a solid two-tone color. There is a gradient, a blend, between the skin-color and the lip-color. That causes problems with the material system that DazV5-5 uses to minimize memory usage, which allows for more characters on-scene at a time.

DazV5-5 characters all have the same exact base skintone in the textures, and then their individual skintones are set by using materials to tint that base skintone. So for example, the Witcher ladies have a lot of a red tint to their skin, Rebecca Chambers has a gray tint, and Samantha Traynor has a dark orange tint. This by itself is perfectly fine, there's no problem with this system in itself, because tinting the textures as a whole has all of the individual components tint with them, which generally trends correctly with human anatomy.

The problem comes in with attempting to manually adjust the color of specific regions of the texture. The most common regions to want to recolor would be the genitals, nipples, and lips. The traditional way to recolor regions of textures is with what is known as a color mask. If you've ever painted a house, and you used painter's tape to mask off a window trim before painting the wall, then you know exactly what masking is - in fact, painter's tape is also known as masking tape, which is where the term "color masking" comes from. It's marking off specific regions of a texture to not be affected by a recoloring.

There are two traditional approaches to color masking in 3d engines: RGB masking, and alpha masking. Or if you prefer, three-channel and one-channel masking. In three-channel masking, a separate mask texture is used that is colored in solid shades of red, green, and blue. To make this explanation easier, let's call these channels one, two, and three respectively.

When the material is tinting the target texture, it loads in that mask texture and then targets a specific channel. So for example, the material could tint only what is masked by channel one to be purple. This means that what was painted red in the mask texture correlates to what is now purple in the final tinted texture. Then the material could tint what is masked by channel two to be yellow - meaning what is green in the mask texture becomes yellow in the final tinted texture.

Most games you see with easily swappable color palettes, such as character or gun skins, uses this system. It's a quick and easy way to get up to 3 different color schemes on a single model.

The alternative to RGB masking is alpha masking. Unlike RGB masking, this does NOT require an additional texture, and as such it takes up less filesize and less memory, instead loading the mask data into the alpha channel of the texture - which is always loaded regardless. This means you get a color mask basically for free. The problem is that there is only one alpha channel, meaning you only get one channel of masking. Or, in other words, you can only set a single tint across a texture - everything else doesn't get tinted at all.

When Valve made Source, they explicitly designed it to be able to run on a slightly moldy potato, and so minimizing memory-use and file-size was paramount to them. As such, Source uses alpha masking, instead of RGB masking.

Now, take the knowledge that Source only allows masking a single tinting channel in mind, and combine it with the fact that DazV5-5 models use tinting to set character skintones. I think you can immediately see the problem. I can ignore the mask and color both the skin and the lips, which is what I currently do. Or I can use the mask and color only the skin, leaving the lips their default pale skin-tone. Or I can use the mask and color only the lips, leaving the skin their default pale skin-tone. I cannot use masks to color both the skin and the lips - that would require two channels of masking, which Source does not support.

SO the solution I attempted was a hacky workaround. I created a duplicate of the lips mesh, pushed it ever so slightly in front of the lips, and then gave them a unique material. This material was an exact copy of the face texture behind it, with one exception: everything that wasn't the lips was transparent, with a smooth gradient between the lips and the skin. The end result is a transparent overlay that draws only the lips, overtop the existing lips. This new lips material then can be tinted arbitrarily, and because it doesn't need to mask anything - it's only the lips and nothing else, after all - it doesn't need to worry about masking channels, or affecting anything other than just the lips. The end user could then just tint or even swap out this custom lip texture as they saw fit, to get any color and pattern they wanted. A trivial example of this would be Kasumi Goto's lips, where she has those two purple bars on her bottom lip - that could be a custom texture, quickly installed onto this overlay, to get the effect.

To avoid any potential weirdness, such as the texture of the custom lips being smaller than the lips behind them, I painted over the base lips with skin color. So if the custom lip overlay was disabled, the character would have no lips at all.

The PROBLEM with this solution is, uhh, highly technical. And if you had trouble following everything I just explained, there's no hope in following the details of the problem. To keep things simple, I will just say that computers are really bad at decimal numbers, and they tend to "snap" decimal numbers together. So for example, while you and I can see the numbers "0.001" and "0.003" and clearly say that the latter is bigger, computers will just round both of these to "0.002" and say they're exactly the same. When I say computers are bad with decimals, this is the sort of thing I mean.

Recall how I said that the transparent lips overlay is very slightly in front of the actual lips. Well, that "very slightly" means "decimals". And computers are bad at decimals, meaning that when the camera is far enough away, it would just round the lip overlay positions to be exactly on top of the actual lip. And when you have two meshes that are exactly on top of each other, the computer doesn't know which to draw first, and so it constantly jumps between them, resulting in flickering. This is commonly known as "depth-fighting" or "z-fighting", because the mechanism used by computers to determine what to draw first is often called a "z-depth buffer".

So, that is why Elizabeth's customizable lips flickered. I used a hacky workaround that was bested by the fact computers are bad at decimals.

And unfortunately, that also means they will probably never come back. I experimented with a few solutions around this issue, such as pushing the customizable lips overlay further away from the actual lips when the camera was far apart, but they had to be pushed so far away to avoid clipping at even just waist-up shots that you could visibly see that the lips were floating and it looked really bad.

I like to think that I'm pretty handy when it comes to working around technical limitations. I've sort of made it a career of sorts, with the myriad tools I've written for my various toolsets. But alas, some limitations just can't be worked around. And I think this is one of them.

I have nil interest. Plus so far as I know that's a 2d show so..?