Naughty Road
patreon
The weirdest flex, or in bits or not in bits.
🕑 Added 2024-04-10 21:55:07 +0000 UTCThe other day, I ventured out into the wilds beyond my own discord server for a bit (not something I usually do), and I fell into the weirdest conversation on some channel where AVN developers could hang out and chat. The gist of it was was that according to some developers, there's apparently this rule that sprites are lazy, and full-scene renders are hard core.
Just to clarify some terminology, sprites in this case means an image with some transparency to it that is projected on top of a background. By combining one or more sprites with a background, you can compose an image to display.
The alternative presented in that argument (the full-scene render) entails that you compose a full scene, with actors, background, lights, and everything, in one scene in Daz Studio, and render that out as a single, as-is image.
So as an example of a sprite, say we have an actor holding a glass, smiling at the camera, projected on top of a background of a small bar at night. Swap the character image out for a blinking version periodically, and the actor now also blinks, and we got a basic LomL scene.
For an example of a full-scene render, take a look at this wallpaper.
The girls, props, and background are all rendered out as a single image at the same time.
So what was the problem again?
With that terminology out of the way, let's get back to "sprites=lazy, full-scene=hard core" debate.
The argument offered was that it's really hard to light up a full scene with a set and actors and props in it in, and render that out as one image. On the other hand, creating sprites separates the process of creating the background and the actors, and you can light up each individually, the implication being that that's easy, and therefore, I dunno, akin to cheating?
But before we explore that further, let's note the obvious fact that that's a steaming load of bull from the get-go. No one is interested in how hard it is to make a scene, are they? All people see is how good (or bad) the end result looks. An image doesn't get better just because you made it blindfolded while a person narrates what's happening on the screen to you in a foreign language, while you're using your left foot to control the mouse. For the purpose of creating images, the difficulty of the technique you use is irrelevant. "Does it look good?" is the only question that matters.
So, is the person making the argument perhaps begging the question that sprites look inherently bad? I know I've seen a fair share of AVNs with horrible looking sprites. But then, I've also seen horrible looking full-scene renders.
That means there's two arguments to explore really: are sprites more easy to create than full-scene renders, and do sprites look worse than full-scene renders? And to do that, let's look at how Light of my Life employs both techniques, and combinations of the two, and to what result.
Simple use of sprites
Let's start with pointing out Light of my Life is sprite heavy. There's a good number of full-scene renders in there, but most of it is sprites, or some hybrid between full-scene and sprites.
The most obvious use of sprites in Light of my Life is in the dialog scenes that make up a good chunk of the game. One or more of the characters are projected over a background.
They move in and out of shot, they might hop around, bump into each other, etc. Immediately, it's clear that sprites offer a way to animate your scene in a way that a static render or even a rendered movie will not. The transformations applied to the sprites are scripted, and applied runtime, and that means you can make them reactive to whatever the dialog requires at that moment, based on player choices even. You can also have events happen in the background independently of what goes on in the foreground .
For instance, we can have two random girls flirting in the background, with blink animations and all.
And layer four toasting women in the foreground on top.
All those bits operate independently, and that makes this a pretty flexible way of working.
Another advantage of using sprints like this, is that they're pretty light-wait with regards to storage. They are not full screen images, and only contain the data for a character, not for the entire scene. Even if we double up for the blink animations, a sprite still doesn't come close to a full screen image when it comes to size.
Zoom, pan, and parallax movement.
But best of all, we can now add parallax movement to different layers of our composite image. You can have a far off backdrop, a mid-range background, and close-by characters, all of which can pan, zoom, and move in different ways, to create the suggestion of camera movement and imply a depth to the image that way.
So, lots of cool technical things you can do with sprites. But like we said, ultimately irrelevant, because what matters is the end result. So let's look at that.
Pretty neat, I'd say, the use of sprites really helps to make this sequence pop.
Lighting schemes
But how do we make sure the sprite and backgrounds go together. Here's Denise, a whole bunch of her in fact.
As you can see, not one of those uses the same lighting scheme. What gives?
Well, my way of working to create these sprites, is to first create a set, with a dummy character in it, and light that up, looking at the dummy character to see if it is lit in an acceptably interesting manner.
Then, using a camera object with a lens set to be spherical (to create a 360 degree image), I render out what is called an HDRI (high dynamic range image).
(ceci n'est pas une HDRI)
These HDRI images contain much more lighting information than a regular .png or .jpg image by using floating point to create a much, much higher range of possible values for each pixel, so you can have a wealth of information about light intensity in there that your naked eye cannot pick up. And since I made a spherical render of it, I can use that HDRI image to light up a character from all sides, very much as if they were standing in the set, on the position of the camera I shot that image with.
Doing this gives the lighting on the character the right "feel" for that set, so they don't look out of place when they're shown on top of the background, while being extremely lightweight in terms of rendering power needed when you render out a character. You'll even see things like windows or lamps reflected in eyes and off of glossy surfaces, so it's a wonderful way to get your sprite to look like they're part of the scene.
I then apply some additional fill and back lighting to the character (key lighting will be provided by the HDRI image, but can be augmented as well sometimes if there's a need to lift the character out from the background a bit).
Oh, wait, so that's the bit where you're cheating! I hear you say. All these extra lights you're adding here.
Well, no, all of this extra lighting is actually no different from what I'd do when I do full-scene render, and very much akin to what most real-life photographers would do when shooting a model on a set, as natural light alone is often not enough to make a great image.
Was that easy?
So, that's making sprites in Light of my Life in its simplest form. Is it lazy, or maybe easy? I'd argue not.
You still need to create up your set and set up lighting, and provide at least some basic key lighting for your character. Then you have to jump a bunch of hoops to transfer that to a character model standing in an empty space. Then you still need to apply additional lighting, same as you would have done if the character was actually on set.
If anything, it's more hoops than just shooting the character straight up in the set. But taking the time to jump those additional hoops yields some interesting benefits that, in my opinion, make it worth doing it.
So, let me take a moment here to point out that I'm not trying to argue the opposite of the original proposition, namely that using sprites is somehow better than using full-scene renders. Because it's not. We'll get to one such point just below, but I want to state clearly that while both techniques have their own pros and cons that might lead an artist to chose one over the other in certain situations, the end result is what matters, and both techniques can offer great end results, if used with a bit of skill.
Hybrids
There's one downside to using HDRIs in this way that's quite notable, and that's that the light applied to a character in this way gets fuzzy, for lack of a better word. Say you have a window in your set with slats. Rendering a character in that set, you'd see the shadows of individual slats on the character. But using a HDRI render to light that character like I showed earlier tends tends to blur that light, so you don't see individual lines for the shadows cast by the slats all that well anymore.
You miss that beautiful interplay between character and set through lighting.
Creating hybrid sets can help in that case. Take for instance this scene where the tree casts some lovely shadows on our heroin, but still allows some beams of light to fall through the canopy, giving off the impression of her being in a cool shaded forest on a warm summer's day. Lighting her up with an HDRI would not get us this kind of result.
So instead we're using the HDRI to capture the light for all parts of the set except that tree with its canopy...
...and we kept the bits that provide detailed shadows with the character to render out separately.
Then we layer it all together in the game.
That same technique is applied here, in the garden where the Coven have their sacred grove, so we can have another tree cast a partial shadow on the characters.
Here's the parts that compose that scene. by the way.
First, we have a background, a tree shadow on the floor, and shadows for up to three characters.
The shadows have to be separated out, and projected behind the characters, because it looks weird to have the ground shadow of one character projected on top of the clothes and feet of the character behind it, and the tree shadow is separated out it is linked to the background characters, and zooms in and out with them, and not with the background, so it can't be baked into the background.
Then there's layers for up to three characters to form a choir, and that's the background bits.
Next there's a midground layer where each character gets their moment in the limelight, and it has it's own shadow layer again too. so we can have several images composed (mainly discarded robes and the character standing there), and project a combined shadow underneath.
Finally, there's a foreground layer where the action eventually takes place (suitably censored here), and there's even an extreme foreground with a small table and a branch hanging before the camera, to imply even more depth for the image once all bits start moving.
Once composed, we get something like this.
All of that was rendered two times at different focal depths, so we can display the image while focused on the background or the foreground in game, depending on where the action is at a given moment. And all of it was rendered with a bit of extra resolution, so we can seamlessly transition from a wide view as shown above to a close-up view, with some panning and zooming, once the background is empty and the action moves to the foreground.
Independent parts
I'd like to bring up one more scene for your entertainment. This one has an animated backdrop and a second, closer background for the immediate surroundings for additional depth while zooming. Then, there's the back and front parts of the Ferris wheel frame. They are rendered out separately and projected in front and behind the gondola where the actors are. Each of those background and foreground parts were then individually rendered out at 10 degree intervals as the Ferris wheel turns, so there's 36 of each. And with that, we can have our protagonist in the gondola do their thing as they go round and round on the wheel.
And to top it off, we can have some independent background action going on too. If you are on the Coven path, they will have snuck on board to have a peek at what's going on. Of course, they come in a bunch of variants too, and with their own independent blink animations.
Our protagonists in the gondola, by the way, are composed from several different images as well, that are blended together, so they can independently emote and interact with each other and the main character while the Ferris wheel is turning.
And for a bunch of images where they interacted too closely to separate out and blend together in game, I just rendered out all the possible permutations of their interactions as complete images, so you still have the impression they can move and talk independently of the other.
A good number of those gondola images are rendered out using two different lighting schemes, so we can have them lit up by streetlights and shopping windows on the bottom half of their turn on the wheel, and by moonlight on the top half.
At over 2k of individual images for all the bits and pieces of that scene, it's one of the biggest ones in there. For the most part, that's because of the complexity of the character interactions, not because of the layering that's going on, which was actually the easy part here.
But I found the result very pleasing when it finally came together. Of course, this scene would be utterly impossible to make using full-scene renders.
So did we get an answer?
To return to the original questions: are sprites more easy to create than full-scene renders, and do sprites look worse than full-scene renders?
I'd say the answer to both is emphatically no.
But why not use sprites 100% of the time then? Well, there's some pretty good reasons to use full-scene renders too.
If you don't need the advantages that using sprites offers (moving around, parallax movement, pans and zooms, scripted image composition, independently operating actors, or reduced use of resources during rending), there's no particular benefit to using them. That's why the wallpapers I create are almost always full-scene renders.
Then, there's times when the character and the scene interact so much that it's hard to separate the two. Sometimes it's hard to break a set up into separate foreground and background pieces. And sometimes the geometry of a set has too much effect on the lighting of the character (or the other way around) to separate them out.
To give one example that embodies all of the above, consider a character standing in a hall of mirrors. You can't render out the set without the actor, as you need the actor reflected in the mirrors on the set, and you can't break the set up into bits for the same reason.
In conclusion.
It's clear that the "sprites=lazy, full-scene=hard core" argument has no merit all, to put it kindly. It's indeed one the most ridiculous flexes ever for a one artist to pull on another.
True, there's ways to do sprites that are unappealing to look at, but there's just as many examples of unappealing full-set renders too.
The bottom line, an artist should just make whatever they feel is good, and do so using techniques work well for them, whether that's with full-scene renders, sprites, or some mix of the two. Any other consideration is just irrelevant.
Comments
Naughty Road
Cheers, and thank you. Yeah, there's plenty of potential for messing things up, but the gains in flexibility and reusability is indeed great, and luckily, ren'py offers a lot of options to ease implementation.
lukumo
In my opinion, the biggest advantage of "sprites" is particularly evident in replayable scenes, because we can use different clothing options for each character, for example. A naked character is created as a skeleton, and different clothing options are created (I know a game where there are up to 96 options for some scenes). This saves a lot of memory compared to full-scene renders, gives variety and reduces the size of the game. All the options are controlled by the random generator so you have to play several times to see everything. But there is a hitch in the programming, it is complex and a potential source of bugs. I think you're doing it right and taking full advantage of sprites and full-scene renders. Thank you for the wonderful explanation of how you work.
Naughty Road
Cheers, Nic! Glad you found that interesting.
Nic
What an epic exposition! Starting with a concise description of the "two ways", you move on to your third, and sensible, way. Hybrid is an overused word these days but is very applicable here. I still have to go through it again as I'm sure I missed a lot. And those fabulous examples will make it so much easier. Many thanks.
Naughty Road
Cheers, I will.
Ray Provencher (Razor McBlade)
I have played many VNs, different formats and even engines. From Honey Select, to Unity to Daz. I have played sprite and full renders and have enjoyed both. I have even dabbled in trying to create them myself. The work involved is very intense, no matter the way it's done. However, I love your style and I think your vision is stunning. I echo what many have said, it's all about the art itself. Both styles have had good and bad art made. I wouldn't change the style of LomL for anything. Keep up the great and hard work.
