Page 1 of 1

Simple Non-Repeating Texture Generation Method (GLSL)

Posted: Sun Mar 29, 2009 5:55 pm
by KrimZon
On Saturday I coded this up, it basically takes a repeating texture and makes it look less repetitive, or at least makes it repeat in a random non-grid way. Bits are the same but the output is not tiled.

I've written it up here, all posh like

Here are some screenshots of what it does with some Quake textures: One Two Three

I'm wondering how easy it would be to implement in a Quake engine now. I know Darkplaces uses GLSL already, but I'm not sure if everything's set up for using it to render world polygons as it stands.

Anyway, there's a code demo in the link if anybody wants to look at that or have a go at adding it to their own engine. I'll be poking around in DP I think.

Posted: Sun Mar 29, 2009 7:14 pm
by MeTcHsteekle
ooh man, looks so sweet :D

Posted: Sun Mar 29, 2009 7:23 pm
by MauveBib
That's freaking awesome! I would love to have something like that in DiD2. Repetitive ground textures are a real pain.

Come to think of it, could this not be done with q3 shaders anyway? Have the blend in the alpha channel, and use two layers ala terrain texture blending?

Posted: Sun Mar 29, 2009 7:54 pm
by GiffE
Very cool!
If this could be implemented into DP :) I would definately need to use it.

Posted: Sun Mar 29, 2009 9:06 pm
by r00k
Very nice!

Most Quake engines are old-school openGL projects using intermediate mode. This, helps programmers pull their head out of the sand and see what's possible on newer oGL versions, ~2.0 etc...

Dp and FTE are the most "up-to-date" savvy engines out there. I think it's a safe bet that DP would support such a feature, straight up.

But using your method, can't this be done by the artist instead of in real-time? You are manipulating textures, but those textures are STILL confined to the actual dimensions of the polygon. It looks perfectly cool for gravel, rocks etc. Wait i take that pre-previous statement back. Doing it realtime on the gpu might cost a few cycles but would save hours of effort by hand manipulation, and thus the random angle etc makes each "new" texture unique thus nonrepeating! Ah-ha! :D

I would like to thank you for your interest in Quake, as not many MIT students peer into this glass. Fresh talent is very welcome !

Posted: Sun Mar 29, 2009 9:23 pm
by scar3crow
I think MIT is in reference to a style of licensing, I doubt KrimZon goes to MIT being British, and hes not new to inside3d, hes just quiet on the forums - hes more active in #qc

KrimZon - How do you think this could impact animated textures, namely the liquids? I'd be curious to see that one...

Posted: Sun Mar 29, 2009 9:38 pm
by MauveBib
I can't emphasise enough how awesome it would be to have this in DP!

Posted: Sun Mar 29, 2009 9:52 pm
by metlslime
This is cool, but I just wanted to point out that it is possible to make tiling textures where the repetition isn't obvious in an ugly way.

Generally you do it by making sure that there are no prominent and unique features on the texture, such as one obvious crack on a concrete texture. You can either remove such features, making for fairly plain-looking artwork, or you can include multiple similar features scattered across the texture. If there are 3-4 cracks of similar character but not identical, the repetition of those cracks will be much less noticable. Or a texture which is a bunch of grey pebbles, with one brown one. You can either remove the brown one or add more brown ones to the mix.

Sometimes it's not actually a feature but a coloration problem -- a high-pass filter is a good way to remove large shifts in color across an image.

Posted: Mon Mar 30, 2009 12:23 am
by Spike
metlslime wrote:Generally you do it by making sure that there are no prominent and unique features on the texture
Alternatively there's quake's method. Make everything brown.

Yes, you can make simple textures that arn't obviously tiled. But they look boring, and just generally washes out the looks of the game.

This method won't fix everything (unlike making everything a single shade of brown), but it does let you retain some detail :)

Posted: Mon Mar 30, 2009 3:38 am
by leileilol
you could also alternatively pull off a .shader, having multiple layers blended with varying tcMod scales. Serious Sam sorta does that with a layer of pre-painted shading stretched over terrain to break up the visual. Zelda 64 even has a similar technique.

THIS IS NOT DETAIL TEXTURES I AM TALKING ABOUT FYI!

Posted: Mon Mar 30, 2009 11:20 am
by KrimZon
MauveBib:
It might be possible to approximate in q3 shaders, though the main thing missing would be the non-repeating nature of the noise itself. The two texture layers and the noise layer would have to be at three different angles.

r00k:
I went to uni in Britain (a middle of the road one) and dropped out after two years because I really badly wanted to code games faster than things were going, and had spent my time coding Quake stuff instead. The license is a blend of MIT and BSD. I took the middle from the BSD license because it only requires the copyright to be kept on the source code and doesn't ask anything of binary distribution.

scar3crow:
To add warp, I think the lookup blends would have to be warped. On the scaled and rotated lookup, the warp would have to be rotated and scaled inversely to what's done to the texture. Or it could look funky and warp the two parts separately. That might look good or bad depending on how it all moves together.

metlslime:
Good point. I should mention that I picked a texture that obviously repeated, partly to demonstrate the repetition clearly and partly to show the improvement in rendering.

leileilol:
I'll check out Serious Sam, because I think I might need larger scale textures when using this on terrain. (I actually started out thinking of just blending stuff when div0 in #DarkPlaces showed me scaling and rotating of noise)

I'm thinking that if textures had the noise texture stored in their alpha channel then it would only require one texture instead of two, but that wouldn't work for automatically processing Quake's existing textures.

Posted: Mon Mar 30, 2009 1:07 pm
by mh
KrimZon wrote:I'm thinking that if textures had the noise texture stored in their alpha channel then it would only require one texture instead of two, but that wouldn't work for automatically processing Quake's existing textures.
It should actually be possible: calculate a noise texture on the CPU at startup, then at texture load time stash it in the alpha channel in your GL_Upload32 function (not everything has to be done in GLSL ;) ).

The one area where I see it breaking down - and which you have (partially, I think) acknowledged in your tutorial - is non-tiling textures such as windows/etc, although this is not really a fault of your implementation, but is rather something that needs to be addressed as a content issue.

Also, I can kinda spot some blurring artefacts on parts of some of these generated textures, where there seems to be an imperfect join in some places. You'd probably have to be looking for it to really notice it though, and it might be just my eyes (I'm getting old! :lol: )

Posted: Thu Sep 10, 2009 11:25 am
by mh
Looking at the formula again, this can be done using a GL_INTERPOLATE combine function where normalTexture is Arg0, scaledTexture is Arg1 and modulationTexture is Arg2. Doesn't need shaders at all.