Strange behavior of the imported flats

Discuss modding questions and implementation details.
User avatar
TheLacus
Posts: 1305
Joined: Wed Sep 14, 2016 6:22 pm

Re: Strange behavior of the imported flats

Post by TheLacus »

King of Worms wrote: so setting 4k at 1080p display for example. I typically use downsampling from 1600p/1800p to my 1200p monitor. It works like a PERFECT antialiasing and more. And that is not working now - thats what I was asking about, sorry for confusion.

Is there a plan to make it work? That would solve all the problems I face now.

I can see the higher resolutions than my native in the options, which is a good start, but If I select them, they dont apply and game is rendered in native 1920*1200 anyway.
DSR renders at a higher resolution and then downscale to what the monitor allows. I'm not sure what make you think this is not working.
Interkarma wrote: There's also a different shader setup used by foliage than interior billboards, which is where you might be facing extra challenges to jman0war. Maybe TheLacus would be able to offer some more advice here, as he's most involved with the asset injection side of things.
I'll take a look when i can, and see how i can help :)

User avatar
King of Worms
Posts: 4752
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Strange behavior of the imported flats

Post by King of Worms »

Thanks for all the info, I appretiate it. Also, Ive read the thread you linked... it reminded me reading it back in 2017. I will try to orient myself in the topic more. What I ment with you not wanting to answer the question was in relation to the DSR, sorry if I was confusing.

I was thinking about DSR for quite a while, and now I see if I can use 4k DSR, the game would look awesome and it would allow me to get rid of a problem, which manifests itself IF the flat is bigger than a resolution you play the game at. Yes, its a dirty trick. But nevertheless, its a question which was not answered, thats what I was reffering to.


And to answer Mr. Lacus question on what makes me think DSR is not working:

When I set a 4k DSR, game is still rendered in orignal resolution. I CAN see it, its still aliased... and my GFX card usage is same at HD and "4k" + the overlay of MSI afterburner is scaling with DSR resolutions, and in DFU theres no scaling when I switch resolution above the native. So these 3 things indicate its not working atm

Took a screens and combined em so you can see for yourself, left is 1920*1200, right is "3840*2400" - they do look the same (exactly same aliasing on the yellow banners for example) GFX card usage is the same, and the overlay is of the same size = its NOT working ;) GPU USAGE IS THE 2nd number in a 1st row, after the number of degrees... its 26% in both cases.

Its like this since I was here, it never worked for me. Would be great if it worked as its enhances graphics dramatically.
Untitled-2.jpg
Untitled-2.jpg (1.21 MiB) Viewed 4306 times
Thanks guys!

PS: Tryed DSR in a game Vaporum which runs on unity as well and its not working. But they have a slider "super resolution scale" and that works, when u set 2x, u get 3840*2400 resolution. Than I tryed Legend of Grimrock 2 and the DSR is working immediately. Same with 75%+ of other games on my PC (if I had a time to play them.. that is :lol: )

User avatar
TheLacus
Posts: 1305
Joined: Wed Sep 14, 2016 6:22 pm

Re: Strange behavior of the imported flats

Post by TheLacus »

Ah, it's because the game uses borderless window and DSR requires exlcusive fullscreen. It should work if you set the resolution for Windows (desktop).

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Strange behavior of the imported flats

Post by Interkarma »

King of Worms wrote: What I ment with you not wanting to answer the question was in relation to the DSR, sorry if I was confusing.
What you're asking about is called supersampling, when a larger render target is scaled down to fit presentation space (i.e. the physical screen's pixel grid). This is different to downsampling, when a smaller render target is scaled up to fit presentation space.

"Sampling" here refers to sampling of virtual scene as viewed by the camera relative to your output device. A higher resolution render target means a higher sampling rate. A lower resolution render target means a lower sampling rate. They're both going to the same physical pixel grid at the moment of presentation. The supersampled output looks great because it started with a higher relative sampling rate. The downsampled scene looks chunkier because it started with a lower relative sampling rate.

The reason I didn't continue with the supersampling conversation is because it's not a portable solution and I was trying to help you solve the core issue in a way that would continue to look great at any resolution, distance, mipmap level, and across a wide variety of target hardware. If you plan to distribute your mod into the wild then we need to be talking about how linear filtering works, not about supersampling. I'm trying to keep you on track. :)

If you can slingshot me one of your source images, I'll be more than happy to put together a detailed post. This will also be useful for anyone who encounters the same problem with asset injection of billboard textures down the road.

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Strange behavior of the imported flats

Post by Interkarma »

TheLacus wrote:Ah, it's because the game uses borderless window and DSR requires exlcusive fullscreen. It should work if you set the resolution for Windows (desktop).
Spot on. :) I've only added a borderless window fullscreen option to Daggerfall Unity. I don't have an exclusive fullscreen option, which is why his supersampling isn't working. It shouldn't be that difficult to add an exclusive fullscreen option though.

Forcing the desktop itself to supersample is a clever workaround, I did not think of that!

User avatar
King of Worms
Posts: 4752
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Strange behavior of the imported flats

Post by King of Worms »

Thanks for explanation!

I knew DSR talk was offtopic but it had a corelation to the topic in a sense it solved the problem in a dirty way. Anyway, lets leave that for now, Im glad I know I can use the desktop resolution to force the ingame DSR, but having the exclusive fullscreen mode can be beneficial in a longer run... esp the Vsync is a bit funky now at times and I GUESS it might be related. (at the castle Sentinel I get 100+fps without Vsync and with Vsync I cant keep 60 but hover at 55fps, also the movement there feels sluggish but thats OT now sry)

Heres one of the flats. This dude can be found at castle sentinel in a throne room. And I reduced his resolution so the height is 1200 as my monitor and than the problem with white outline was "solved". Since than I applyed refine edge on it with 50% contrast - that leaves the flat with a semi soft edge. This is how my flats look like now. So its a valid representation of my current technical standard lets say (flat is not 100% finished)
357_11-0.png
357_11-0.png (442.74 KiB) Viewed 4262 times

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Strange behavior of the imported flats

Post by Interkarma »

Here's a more visual explanation of how to avoid those pesky borders sampled by linear filtering. Let's start with a processed version of this fellow so you can see all the elements I'm trying to discuss clearly.
357_11-0-alpha-fringe.png
357_11-0-alpha-fringe.png (365.16 KiB) Viewed 4218 times
There are a total of three important elements in the above screenshot:
  • The colour RGB components we want to see (the sprite itself). These have an Alpha of 1.
  • The colour RGB components we can't see (the fringe created by feathering). These have an Alpha of less than 1 down to 0. I have inverted these colours and removed alpha transparency so you can see them clearly as a blue-ish outline.
  • The transparent RGBA components which are fully clear (all RGBA components are 0). These are represented in black above, although in the real image they are completely clear. Just remember they have an RGB of 0,0,0 (black) and an A of 0. This will be important in a moment.
When linear filtering samples a texture, it does not consider the alpha values at all. It only considers the RGB values. Depending on sample rate, linear filtering is likely to sample from adjacent pixels. This is fine for the thin feathered border (shown in blue) but at low enough sample rates, linear filtering will also sample in the black RGB values from the nearby clear pixels. This can create a coloured/black/white/gray/etc. border depending on what the transparent pixels have in their RGB values and how the filter mixes everything together. Regardless, the outcome is a border you don't want to see. We need to get these clear pixels away from the sprite!

Now, you can work around this by changing the sample rate (as you did by changing dimensions or working with supersampling), but this doesn't solve the underlying issue. Someone is going to see an ugly border around the sprites sooner or later.

To fix this, we need a much thicker band of coloured alpha pixels around the sprite. This is normally done with dilation, but you can use gaussian blurs or any number of techniques. Dilation will generally give you the best result though. Here's an example of the same fellow creating a border with gaussian blur of the source image in a layer behind. I've kept the negative colours so you can see them clearly. Notice how much larger the surrounding fringe area is compared to the first image.
357_11-0-blur-negative.png
357_11-0-blur-negative.png (475.75 KiB) Viewed 4218 times
If we were to see these alpha pixels as their actual colours (without transparency), he looks like below. This is the concept the dilation article I linked earlier was demonstrating.
357_11-0-blur-color.png
357_11-0-blur-color.png (460.68 KiB) Viewed 4218 times
And in the final screenshot, I've changed alpha of the blur to an almost-transparent value (alpha of 2) to ensure my paint package did not discard the values. You can just barely see them in this final example.
357_11-0-blur-color-alpha.png
357_11-0-blur-color-alpha.png (475.24 KiB) Viewed 4218 times
When running this image with linear filtering and cutout transparency, the GPU has a nice large border to sample colour from around the sprite, and is unlikely to sample from the surrounding areas with an RGB value of 0.

You have much better tools and more knowledge of digital painting than I do, so can likely find a better way to integrate this idea into your pipeline. See if you can find a dilation plugin for your paint package for best results.

The key concept is that empty parts of the image should not be adjacent to colour parts as linear filtering can blend those parts together.

I hope that helps explain the problem more visually and offers a starting point to create assets with dilated alpha fringes which inhibit the sampling of black borders around billboard sprites.

Please let me know if anything needs further detail.

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Strange behavior of the imported flats

Post by Interkarma »

When you're ready, there's more detail for the above.

Linear filtering will also wrap to other side of image when sampling edges (e.g. left edge will blend with right edge, top edge will blend with bottom edge). This can also create a border even with otherwise nicely dilated images. If you refer back to your original posts where you can still see a little border near his shoulder on right-side of image (where you say "still there a bit") - this is caused by linear wraparound sampling to left (black) side of image. Note there's virtually no fringe on that right hand edge. Now you can see visually why that was happening in your earlier screenshot near that shoulder.

The trick to fixing this is to add a buffer zone of several pixels around all sides of the image before dilating. But this can cause sprites to seem misaligned in scene. Daggerfall positions most billboard sprites with a centre-bottom origin, whereas dungeons use a centre-middle origin. The extra border area could make sprites appear to hover disconnected from the ground (more than usual).

To fix this, you need to adjust UV coordinates to "zoom in" on the right parts of the texture inside the billboard area and disregard borders.

When I built the foundation of Daggerfall Unity, I had to accomplish all of the above (dilation, borders, UV adjustments), in addition to conversion to modern formats, in addition to packing into atlases, all so that classic art would look good with and without linear filtering. I had to write an entire image processing library and custom import methods to make all of this happen exactly as required in realtime.

Then I turned off linear filtering by default for that true classic look and 99% of people don't even know all this stuff is happening under the hood when Daggerfall Unity reads textures from their DOS game files.

That's the sheer gleeful hell of game development. Your work is almost never fully appreciated. Welcome to the show. :)

User avatar
King of Worms
Posts: 4752
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Strange behavior of the imported flats

Post by King of Worms »

Ive read it, almost twice on my phone :) Thanks a lot for this! Im very busy this week but I wanted to make sure to let you know I appreciate this tutorial and the time you have put into it. I will try to use it and will come back with the results, it will be worth it to learn this :shock:

Post Reply