Page 1 of 3

High Resolution Terrain Textures

Posted: Tue Jan 14, 2020 11:05 pm
by TheLacus
This is something i have been working on. I started it more for fun than anything else, but maybe someone will like it so i decided to release what i have. I don't have much time for Daggerfall in this period but hopefully i can work on feedback if there is any. If not, at least it has proved as test material because it shows that terrain shader still need some work on mipmaps...

These are some comparisons between original textures (resized from 64x64 to 256x256 for visibility) and 2k textures i made from high resolution sources. I heavily edited an ice picture to create the water, so it doesn't fit much other textures, but i actually like how it looks in game.
Spoiler!
Image
Image
Image
Image

See this post for downloads.

EDIT: Nexus link

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 5:29 am
by Azteca
Amazing! Can't wait to try these out or see videos with them in action.

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 12:06 pm
by TheLacus
some screenshots:

df_terrain_0.png
df_terrain_0.png (1.25 MiB) Viewed 480 times
df_terrain_1.png
df_terrain_1.png (1.55 MiB) Viewed 480 times
df_terrain_2.png
df_terrain_2.png (1.17 MiB) Viewed 480 times

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 12:12 pm
by Ralzar
Hm, that looks pretty nice. This is not with DREAM right? It looks to actually fit better than the extremely low-res original ground.

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 12:22 pm
by Jeoshua
I like this better than DREAM's ground textures. It really does fit better, IMO.

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 1:27 pm
by TheLacus
Yes, no other mods are used in the screenshots above. Now i'm making some experiments with normal maps (don't mind to the dark tiles) :idea:

df_terrain_nmp_0.png
df_terrain_nmp_0.png (1.38 MiB) Viewed 456 times
df_terrain_nm_1.png
df_terrain_nm_1.png (1.24 MiB) Viewed 456 times
df_terrain_nm_2.png
df_terrain_nm_2.png (1.37 MiB) Viewed 456 times

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 1:59 pm
by MasonFace
Absolutely outstanding! Great job!

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 9:13 pm
by King of Worms
I like it, please go on. Im also interrested if you can make the normal maps work properly, I certainly wasnt unfortunately.

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 9:49 pm
by TheLacus
I made a test .dfmod for windows, while Linux and OSX versions are being uploaded. It contains temperate climate with 2k resolution, but i plan to make a 1k version too. if there is no enough difference i will stick with the lower one for future updates.

Windows Download

Linux Download

OSX Download

df_tt0.jpeg
df_tt0.jpeg (495.66 KiB) Viewed 396 times
King of Worms wrote:
Wed Jan 15, 2020 9:13 pm
I like it, please go on. Im also interrested if you can make the normal maps work properly, I certainly wasnt unfortunately.
I didn't meet particular issues at the moment. Note that i'm not running a tool for automatic generation on every texture. Instead, i took a few main materials (grass, ground, etc.) and combined them in all 56 patterns, for both color and normal maps. This ought to ensure they have all the same strength.

Re: [TEST] High Resolution Terrain Textures

Posted: Wed Jan 15, 2020 10:05 pm
by DigitalMonk
I must admit, normal maps never seemed like the kind of thing that a person could draw and remain sane... Bump/Height maps, certainly -- pretty straightforward. But a normal map, with the surface normal's unit vector's x,y,z encoded in r,g,b?

(Technically, I believe you're encoding the "relative" surface normal, or the delta of the desired surface normal from the underlying 3D model's surface normal. Which makes sense and is what you'd expect, I just wanted to be clear that it's more dx,dy,dz rather than any kind of global x,y,z coords. And, I suppose, it should be du,dv,d?, since you only know texture coords, not model coords.)

(Then you get the extra weirdness of needing to keep it a _unit_ vector. While you're getting your tilt angles right, make sure the length is 1.0, or the lighting calculations will do weird things. Oddly enough, there must be some reason to want to allow "weird things", because if you were only going to allow unit vectors, you would only need to specify du,dv at each pixel, and d? could be calculated as "whatever makes the vector have length 1.0". That could be done by the hardware, though the resulting calculation involves some square roots, which are expensive at the pixel level, so maybe they just said "sort it out yourself offline and just tell us sane numbers")

Every one I've ever seen gives me a mild headache. Straightforward enough if you're starting with a high detail 3D model and baking those fine details down into a normal map to apply to a low-poly game model. Computers have no problem with it. And I could see doing a brick texture, I guess. Left edges of bricks would have low red intensity, right edges would have high red intensity, top edges would have low green intensity, bottom would have high green intensity. But for anything organic, or even just rounded? Brain hurts.

Now, I could definitely see how to have a program go from a bump/heightmap to making a normal map, but if that's all you're doing, why supply normal maps? Why not just supply the bump/heightmap? And then I realized that it's probably for the same reason as providing the third d? component -- it saves the pixel shader from having to calculate the local surface normal and just give it to it directly.

Which is a very long-winded way of saying that I'm impressed by anybody who is making normal maps by hand... And that I appreciate your devotion. If a bump->normal program would be useful, I'd be happy to contribute such a thing.

(I'm also aware that I haven't kept up with tools, and haven't played with Unity yet, so I apologize if this entire post is ridiculous and/or misguided...)