![[de]](/mwf/flags/de.png "Germany")
Okay, got in the mood today to play around a bit with shaders. Yeah, not the fix-norefs- or the write-up-building-concept-mood yet, but hey, it's better than nothing, right? Right?
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.
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.
Depends on what you mean. The HQx source code is public (and GPL'd, so we can't use it directly). A quick look at it should also illustrate why I am talking about simplifying the implementation... :)
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 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.
this code looks weird and seems to not work on every graphics card because of the ammount of opcodes.
It's essentially a hard-coded lookup map for all 3x3 pixel groups (and then some), listing for each one how to mix the final color from the original colors. The essence is that it has some underlying understanding of how to "polygonize" a 3x3 pixel group and this mixing is doing the appropriate anti-aliasing to reach the desired effect.
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
is done slightly different than
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
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 Cis done slightly different than
A A B
A A B
B B Bin 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
ifs 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.
a shader-code generator would be more efficient and easier to debug than a hard coded one.
> 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...
sorry if im wrong or i missed something, but wasnt it the plan to implement polygonal landscapes?
Newton played a bit around with polygonal landscapes, but that's all.
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.
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?
![[ca]](/mwf/flags/ca.png "Canada")
Woah, looks nice! It looks pretty rough at the edges (and at the 3 colour corner as you mentioned), though.
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)
But this is only for solid colors. Will HQ3x be able to mix textures instead of colors as well? (Do we still know the textures to be used at that point?)
We could use the smoothed color as an index into a texture table. (Assuming we can get it to spit out a smoothed, non-blurred version or the original colors)
Yep, that's the plan - and why I wrote "Texturing should be possible" above. The approach I'm going to try is to have the texture index in the first color component and the density in the second. The latter would be used for lightening.
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.
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.
Maybe you could use a 3D texture with a depth of 256, from which you can sample the "real" 2D textures.
Yeah, I have now stumbled across that, too. The above still uses ugly branches until I figure out how those 3D textures work ;)
Also, if I'm not mistaken, we might want mipmaps on our textures, won't we?
>we might want mipmaps on our textures, won't we?
That will create less super-lag when zooming out? That would be quite appreciated.
We won't have super-lag either way, that's the point about the shaders: It's equally expensive no matter the zoom level.
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:
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:
Okay, another update, 3D textures and with some fine-tuning of the scaler map. Still need to sort out mip-mapping and problems number 1 and 2.
Heh, this is crazy. The GPU calculates some kind of texture coordinate derivate in order to decide which mipmap level to use. The thing is: the artefacts were appearing exactly where this derivate is undefined (at the edges). Even though I'm not even using mimaps or any other thing that might use the derivate. But when I'm now manually setting the LOD to 0, the problem suddenly disappears.
Somebody have an explanation?
Somebody have an explanation?
Just looks incredible, good work!
Larger terrain, this is about 2.5x I think. Mipmapping seems to be problematic together with 3D textures for some reason. At least the textures start to get mixed up when I'm trying to use it.
I see no glitches left. So sharp edges, wow!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.
I prefer clear edges. For some texture combinations, blurring might look good and if we can activate it separately e.g. only for textures of equal density, we could use it. But stuff like earth and water just must not be blurred together; both for graphical and for gameplay reasons.
I guess Newton is talking about specific material borderings, like earth-sand in his example. That's the context for my above answer: It's technically possible for the shader to use a different scaler map when, say, two material with the same placement are right next to each other.
> 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.)
Second reason for doing multi-pass would be that the shader can calculate proper normels - enabling more realistic lightening. That would especially allow us to have dynamic light sources. That might just be within reach before the GPU starts passing out.
Why not calculate the normals in ApplyLighting (on the CPU), and store them along the texture index?
i dont like those lightening. i alrdy found it not nice-looking in clonk rage. Why should this even be implemented?
I don't like them too much either, but it helps a lot for recognizing tunnel borders.Maybe we can add a bit of pseudo-randomness (e.g. turbulence) both horizontally and vertically to the next border search?
Or a predefined randomness by a small greyscale image that shows a "ridged" and (horizontally) loopable gradient from black to white. Mapping a more structured and broad gradient onto the flat landscape can help to make the landscape look more 3-dimensional as the player would really get the impression that e.g. a rock is really shaped roughly round towards its edge instead of just cut off like in an ant farm. Though, the problem with a very broad gradient with recognizeable structure mapped on the landscape is that these structures would seem to move while digging (the same would apply for automatically generated turbulence I figure).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).
That's just like an overlay texture. Support for a secondary landscape modulation textures existed in CR but has been removed from OC.Anyway, the key to a lightning texture would be that it would have to be aligned to placement step boundaries.
"Broad" is evil, btw, as the complexity obviously increases quadratically when the shader needs to consider more pixels for each output pixel. Well, or linearly if the CPU gets to do it.
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.
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
