The lower image has the same texture data as the above image, just with the HQ3x-inspired shader attached. It is clearly visible that the HQ3x shader does a good job finding edges and somewhat successfully both manages to be neither pixely nor blurry (I can upgrade to HQ4x in case it's still not sharp enough - after that we're on our own).
On the other hand, known bugs in this prototype:
* Right at the edges between pixels the shader sometimes does strange stuff. Probably floating-point related, brr.
* My extremly simplified implementation only considers two colors per original pixel. This breaks once there are three colors involved at some point (see the point where earth, sand, tunnel and sky collide).
* For some reason the secondary color is never reached fully. Well, should be easy to fix.
Other notes: CR-style lightning should be trivial in comparison. Texturing should be possible, haven't checked properly yet.
My prototype is currently, er, very prototypic. For now, I'm just checking whether my ideas actually work. If that's the case, I'll try to encapsulate it properly and port it into the engine.
My approach is similar: I just build a texture containing all 3x3 pixel combinations, which the shader then needs to look up. The added bonus is that the GPU will interpolate for me if I need more or less than 3x.
The main problem is the "and then some" part, as for example
A A B
A A B
C C C
is done slightly different than
A A B
A A B
B B B
in that the second case will have the "B" area go a bit more into the "A" area in order to make the corner nice and round (in the source code, that's the
if
s inside the switch
). I'm not sure yet how I should fix this - maybe I'll have to build some special cases into the shader. If shaders do jump prediction properly, doing special cases should be pretty cheap.
> If shaders do jump prediction properly, doing special cases should be pretty cheap.
On some GPUs, shaders will simply execute all paths, and throw away the result of the path that wasn't taken...
In my eyes this is not something that can or should be decided upfront since both techniques require much experimenting. So unless we have the luxury of two full-fledged implementations we could choose from let's take what actually gets implemented.
>Newton played a bit around with polygonal landscapes, but that's all.
I thought that's his bachelor dissertation?
Updated version: Fixed the third problem, made the second problem less severe (essentially I'm falling back to GPU scaling here), first problem is proving to be difficult. Looks good up to about 5x now.
(the original image is 40x20, btw - so the thumbnail above is 3,5x and the full version is about 12x)
Getting the raw color is possible if you are careful to only query the texture at the right places. For the HQ3x shader implementation, I am already comparing colors without threshold - so I guess this approach is pretty accurate.
On the other hand, I'm still thinking how I'm going to query textures. Using a texture unit per texture should be the most elegant solution, but there might obviously be situations where there are more textures than texture units. Maybe I'll have to split landscape chunks on-the-fly if that happens, we'll see.
>we might want mipmaps on our textures, won't we?
That will create less super-lag when zooming out? That would be quite appreciated.
It's more of a cosmetic thing: When multiple texture pixels map to one screen pixel, the correct way would be to average over the texture pixels. Instead, right now the shader would just select one of the pixels at random, causing artefacts when zoomed out.
Take the example above - it's a thumbnail generated by the forum, so the proper averaging was done. Here's how it looks like if the shader directly generates the image:
Somebody have an explanation?
But seeing the landscape with such a unblurred edges, I remember the other issue, the issue that the landscape textures should actually be displayed 1:1 on 3x zoom (and thus not blurred on any zoom level smaller or equal 3x) which is much more obvious now.
Also, this rises the question if sharp edges are really desired between all material (textures): The graphics style of the material textures moved towards something more photorealistic. Sharp edges between, sand and earth or even different earth textures look no good. If you got a game with a brick wall on which some areas should be more dirty than the normal texture and got a second texture for that (showing a "dirty" version of the normal brick texture), it will look odd if the two textures are not blended into each other at the borders of these areas. The same applies for many materials on the clonk landscape. Have a look at the attachment: If this is in any way possible, at least materials and textures of the same density should blend into each other rather than form sharp edges - perhaps even all textures (except sky/tunnel and liquid) should blend into each other at their borders.
What the sharp edges are wonderful for, however, are for the edges of the landscape - namely sky/tunnel with anything else. Hq3x hides the blurry pixels which would otherwise be very obvious - but it also removes the blur which was quite good in many situations.
> I remember the other issue, the issue that the landscape textures should actually be displayed 1:1 on 3x zoom
Well, the way I see it, this means that we both really need:
* mipmapping - which is a problem because it seems to be pretty incompatible with 3D textures. Some more research needed.
* much larger textures - because otherwise tiling issues will be painfully visible.
> The graphics style of the material textures moved towards something more photorealistic.
Which I don't like at all, btw. We should not go for photorealism, but for something that looks good. And having photos in our cartoony Clonk world just feels out of place for me.
> [Blending material together]
Well, my attempt at doing lightening showed me yesterday that getting a smooth gradient over more than one original pixel is hard to do. Smoothing is (obviously) exactly orthogonal in philosophy to sharpening, so it's not easy to integrate.
But it certainly is within the realms of the possible to fallback to the original - or even more specialized versions of the scaling. To do that, you just have to provide another shader lookup map. If you're willing to edit this map (quite laborious, as I know from my fine-tuning) you can get just about any effect. As long as it's just the edges, see above.
>* much larger textures - because otherwise tiling issues will be painfully visible.
This will be no issue - I am the one who created most of the textures and I specifically tailored them to be displafed at that size.
> Which I don't like at all, btw. We should not go for photorealism, but for something that looks good. And having photos in our cartoony Clonk world just feels out of place for me.
What can I say? No attempt oyf providing a different graphics style has been made. We have to work with what we have (/get contributions for). BTW most textures for models are also photoshopped from photos.
> What can I say? No attempt oyf providing a different graphics style has been made.
Might have been a bit implicit (sorry), but my main point is that I actually prefer stretching the textures a bit so it's more of a general structured surface than something that you can actually recognize. I just want "realism" out as an argument. Let's try different zoom levels and see what's best.
My big landscape currently stretches the texture to the whole width of the landscape, which is obviously too much. For my smaller examples, on the other hand, I think it's too small - imo the structure should be recognizable as such even at 1x.
> So sharp edges, wow!
Oh, btw, just a technical side note: The reason for this is that the lines are actually perfectly anti-aliased. The edge quality is better than what the GPU anti-aliasing could calculate with its probe-pixels. And we get that at no additional cost :)
> Also, this rises the question if sharp edges are really desired between all material (textures): The graphics style of the material textures moved towards something more photorealistic. Sharp edges between, sand and earth or even different earth textures look no good.
I'd wait with that assertion until shadows are implemented again: Instead of the look of finely cut paper textures, the landscape gets a look of something real, which just happens to have sharp edges. I'd guess that the sharp edges look actually good with them.
Now with lightening. Kind of. I don't like the implementation at all, it made the count of texture lookups skyrocket (about 4 times). It's also the first version that causes notable stutters.
The reason is that I'm essentially doing pixel interpolation in the shader, which is obviously hugely expensive. A better way would be to have a first pass calculate the (low-res!) lightening values and then have the GPU read and interpolate those for the actual shader.
(Ignore those high-placement water things in there. That's just materials that I haven't defined yet.)
Maybe we can add a bit of pseudo-randomness (e.g. turbulence) both horizontally and vertically to the next border search?
However I could imagine something like this to look awesome if computed and mapped onto the landscape (w/ multiply) as a shading one-time at scenario start - with a gradient of min 100px height and enough diversity that it doesn't look like it's repeating itsef all the time (e.g. 1000px width).
Anyway, the key to a lightning texture would be that it would have to be aligned to placement step boundaries.
And I believe the term we are searching for here is bump mapping. I have already pushed a bit into the direction by calculating real normals internally, but the results don't really look any better. A simple idea could be to have per-texture bump maps and rotate their normals when we get closer to an edge.
Yeah, still working on it. The last 10% are going to be exactly as much work as often claimed.
Right now I'm already calculating the "normals" in the CPU, but the shader currently only uses it in a very rough way (might look "upside-down" here). The problem I have to solve right now is how to make it play nice with the scaler, as visible above. I might have to do another scaler-rework to solve this.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill