Relighting v4.0165b - blurry shadows w/ rlassets

[Hey Doomer_]

WIWO v4.0165b - more smart lighting

I've decided to go down the rabbit hole to "correct" sectors without lighting that appear brightly lit. Since I already know the flats and already know which ones emanate color from palette variables, I can add existing flat lights from a level to sectors that are snapped to grid that meet criteria. This seems easy enough in the context of the mod, although I've no idea what this will look like.

Update soon.

[Hey Doomer_]

WIWO v4.0165b - more smart lighting

I've decided to go down the rabbit hole to "correct" sectors without lighting that appear brightly lit. Since I already know the flats and already know which ones emanate color from palette variables, I can add existing flat lights from a level to sectors that are snapped to grid that meet criteria. This seems easy enough in the context of the mod, although I've no idea what this will look like.

Update soon.

Update

It works OK, but the results are spotty. On the one hand it's the same problem presented with deciding what textures are "lights." I can generally identify lights based on the author's lighting, but sometimes this is off the mark. Sometimes snapping to grid works, sometimes it doesn't depending on how sectors are distributed along same flats in a sector to simulate shadows with sector-based lighting. When it does work it makes sense. When it doesn't... well, I've abandoned this idea.

[cortes2k]

Dude. I was playing Doom and crashed, it shows this error, I'm not relly sure if is a Relighting error. Cheers.
https://imgur.com/a/Ku2DLuX

[Dan_The_Noob]

howdy, haven't played doom in a while, but 4.0163b caused decorate errors when used with Kinsie Metaprops and Universal Gibs

--EDIT--

just tried it again (I forgot i updated GZdoom to 4.10) and it's working fine now

[Hey Doomer_]

Dude. I was playing Doom and crashed, it shows this error, I'm not relly sure if is a Relighting error. Cheers.
https://imgur.com/a/Ku2DLuX

I assume this is a custom map. Most likely this has an outside sky with a light level of 0. You can try this tweak to line 988 that I'll put in the next version:

Code: Select all

	if (sky) r = (sec.LightLevel / (sky_light + 1)) / rl_CVar.rl_dim_min.GetFloat();

[cortes2k]

Dude. I was playing Doom and crashed, it shows this error, I'm not relly sure if is a Relighting error. Cheers.
https://imgur.com/a/Ku2DLuX

I assume this is a custom map. Most likely this has an outside sky with a light level of 0. You can try this tweak to line 988 that I'll put in the next version:

Code: Select all

	if (sky) r = (sec.LightLevel / (sky_light + 1)) / rl_CVar.rl_dim_min.GetFloat();

Dude. Your fix works fine. Thank you

[Hey Doomer_]

WIWO v4.0165b - more smart lighting

I've decided to go down the rabbit hole to "correct" sectors without lighting that appear brightly lit. Since I already know the flats and already know which ones emanate color from palette variables, I can add existing flat lights from a level to sectors that are snapped to grid that meet criteria. This seems easy enough in the context of the mod, although I've no idea what this will look like.

Update soon.

Update

It works OK, but the results are spotty. On the one hand it's the same problem presented with deciding what textures are "lights." I can generally identify lights based on the author's lighting, but sometimes this is off the mark. Sometimes snapping to grid works, sometimes it doesn't depending on how sectors are distributed along same flats in a sector to simulate shadows with sector-based lighting. When it does work it makes sense. When it doesn't... well, I've abandoned this idea.

More testing, this time with attaching sprite shadows to Voxel Doom.

POC link here.

How this works is ridiculously simple, although this POC only works with the POSS sprite. I copied the POSS sprites and renamed all to ZOSS. Added this actor to make sure the new sprites are indexed by the engine:

Code: Select all

class ZossTest: Actor
{
 	States
	{
	Spawn:
		ZOSS A 1;
		Stop;
	}
}

Then substituted the "correct" shadow sprite in the hd_shadow Tick() function:

Code: Select all

		Texman texture;
		let csprite = texture.GetName(caster.CurState.GetSpriteTexture(0));
		if (csprite.IndexOf("POSS") != -1)
		{
			Sprite = GetSpriteIndex("ZOSS");
		}
		else
		{
			Sprite = caster.Sprite;
		}

That's about it. Floor and wall shadows are cast on the fly as the alternative ZOSS sprites.

Since all the voxel definitions are captured, it's simple enough to make this work for all voxels assuming all assets are copied and renamed. I'm not saying I'll do that nor do I know if that's even legal. It is, however, interesting that this works at all.

As an aside, I'm also certain that these shadow sprites could be altered to be genuinely fuzzy around the edges. They would still be flat, of course, but more realistic. This won't affect anything since these extra assets would be for shadows only and not otherwise used. Thus this has other utility outside of Voxel Doom... but still only Doom.

[Dan_The_Noob]

oh nice, i was wondering if you were messing with Voxel Doom2

[Hey Doomer_]

oh nice, i was wondering if you were messing with Voxel Doom2

Thanks!

I'm thinking there are advantages to this other than Voxel Doom. It's easy to whip up a script to extract, rename, and convert sprites. This would be a utility run before using Relighting to create an asset pk3 for all game sprites (most likely in Python - cross-platform solution). Code is already in place to "throw" shadows at a wall or floor; separate assets work fine with or without VD. I'll need to do some reading and pondering on this to see if it's feasible to blur edges where this is transparency. My guess is yes.

Such a script would be fast. I suppose it's also possible to create clipped assets (the Holy Grail of Doom sprites) but that's getting ahead of myself.

[Hey Doomer_]

oh nice, i was wondering if you were messing with Voxel Doom2

Thanks!

I'm thinking there are advantages to this other than Voxel Doom. It's easy to whip up a script to extract, rename, and convert sprites. This would be a utility run before using Relighting to create an asset pk3 for all game sprites (most likely in Python - cross-platform solution). Code is already in place to "throw" shadows at a wall or floor; separate assets work fine with or without VD. I'll need to do some reading and pondering on this to see if it's feasible to blur edges where this is transparency. My guess is yes.

Such a script would be fast. I suppose it's also possible to create clipped assets (the Holy Grail of Doom sprites) but that's getting ahead of myself.

Yep, easy using existing libraries. More to come.

[Hey Doomer_]

Simple POC start:

Code: Select all

from omg import *
from PIL import ImageFilter, ImageEnhance

wad = WAD('DOOM.WAD')

p = r'rl_assets\sprites'

for s in wad.sprites:
    if 'POSS' in s:
        img = wad.sprites[s].to_Image()
        img = img.convert('RGB')
        img_blurred = img.filter(ImageFilter.BLUR)
        img_blurred.save('{0}\Z{1}.jpeg'.format(p, s[1:]))

This is the general idea. Although this uses an IWAD for testing, assets from a pk3 can be extracted like any other zip. Then the rl_assets folder is zipped into a pk3 (just haven't added that code).

Members of the sprites object are looped through; in this case I'm interested in POSS (zombieman) sprites since a naming crosswalk text lump will be needed to avoid duplication (BOSS = cyberdemon); the PIL image has to be convert to full RGB to apply a Gaussian filter, after which is it saved to a subfolder where it can be zipped to a pk3.

ZOSSA1.jpeg

Still testing since these are not rendered correctly by the engine, and I'm not sure at all that blurred images can be rendered at all. Perhaps someone who has already done this can chime in! But extracting / creating the assets is very simple as evident.

[Hey Doomer_]

This works as can be seen here.

A problem I'm having is setting offsets correctly; for the above I manually set the offsets for frames A and B, otherwise Python did all the work. Clearly the shadows are blurred.

I still have some more work to do in understanding how to set offsets correctly for the transformed images. But otherwise this is pretty much done and on its way to the next release. Should work for voxels.

[Dan_The_Noob]

maybe for the blur you can make them angle so the feet stay in roughly the same spot. to give the illusion of a shadow that gets scattered toward the top

[Hey Doomer_]

I've got this working although it involves Node and Python. Here's the code:

Code: Select all

from omg import *
from PIL import ImageFilter, ImageEnhance
import subprocess

wad = WAD('DOOM.WAD')

path = r'rl_assets\sprites'

for s in wad.sprites:
    if s[:4] == 'POSS':
        fname = '{0}\Z{1}.png'.format(path, s[1:])
        img = wad.sprites[s].to_Image('RGBA')
        img_blurred = img.filter(ImageFilter.BLUR)
        img_blurred.save(fname)

        p = subprocess.Popen(['node.exe', 'c:\save\doom\python\pngOffset.js', fname, '{}'.format(wad.sprites[s].x_offset), '{}'.format(wad.sprites[s].y_offset)], stdout=subprocess.PIPE)
        print(p.stdout.read())

I have not yet found a simple way in Python to update PNG IHDR chunk offsets so for these purposes I used a Node script found here. Note that these can be updated in PIL, but this alters the image. As you can see from the above, the offsets are directly grabbed from the lump data and applied.

Again this POC is for POSS because of sprite name similarity. This uses default settings for filtering and compression. Dependencies are omgifol (Python), pillow (Python), and png-chunks-extract (Node), png-chunks-encode (Node). I've yet to add code for the crosswalk and allowing for different file types (WAD vs. pk3/zip). But you get the idea. There is very little code involved.

Here is the output.

Note blurred shadows and the comparison between zombieman (blurred) and imp (not blurred) shadows at the end.

[Hey Doomer_]

More progress.

I've added creation of ZScript assets to the Python script: crosswalk.zs, a class that creates and returns the swap name, and initswap.zs, DECORATE classes that index the new sprites. I've also added unique swap names and tried a lower Gaussian blur on the transformation using DOOM2 IWAD. This works great with Voxel Doom as can be seen here. (I have brightened the GIF to make it easier to see the shadows.)

This is all pretty basic coding with two Python lists, sbase and sswap. This is to mimic ZScript dynamic arrays for ease of creating a crosswalk class, and also because they are mirrored lists.

The final file is bloated to around 10K. I've applied optimization to the PIL sprite files, which are already cropped and compressed. This isn't bad considering. The good news here is extra sprites won't hurt anything. I am unsure if there is a limit in the engine.

Once the Python script creates the assets folder (ultimately called "sprites") that can be moved into the Relighting root. The code itself looks for the crosswalk class and includes the two ZScript files. I've yet to work out adding sprites from multiple files, including pk3 files.

Still testing.