Sorry your browser is not supported!

Hi All!

This is a revised version of the shader I posted here:

A shader for creating Perlin noise images

The new demo shows one way of creating several different images which will tile seamlessly. A possible application might be creating successive heightmaps for use in a never ending world. The tiling is achieved by making sure that the seed variables used for the edges of the images match those used by adjacent images. Some details of how this works in the demo are available in the two files "image layout.png" and "seed layout.txt" included in the zip file.

The shader takes a long time to compile (a few minutes on my laptop ) so I have used a compiled version of the shader (extension .obj instead of .fx) in the demo. I found it hard to use Dark Shader for this particular shader and compiled it using the DX9 SDK "fxc.exe" utility. You can use the .fx file if you prefer but you may experience a long wait while DBPro calls the DX9 shader compiler. The compiled version loads into DBPro very quickly in the demo .

As in the earlier demo you can choose which octaves to use. You can also change some of the seeds used for the random number generatior in the shader. The shader uses 10 different pairs of seeds: 8 for the four corners and edges of the image , one for the random number generator itself (this allows a completely different set of images to be created), and one for the numbers generated in the interior of the image (together with the seeds used for the edges this allows the images to differ from each other within a set of 9 images).

Here's a screenshot of a sample of 9 images which tile seamlessly:



The demo creates 9 256x256 images arranged as a 3x3 grid. The shader is not limited to that size - I simply used it for ease of presentation. The images are only recalculated when their defining parameters are changed, i.e. seeds, octaves etc. The tiles are shown adjacent to each other by default. If you press <s> the demo inserts a i pixel width black border between them so you can see where the boundaries are. Turn this off by pressing <s> again.

You will need a PS3 capable GFX card. I've tested the demo using both DBPro U77 RC7 and Rudolpho's DBP DX9Ex version. Works fine with either.

As usual, any problems just ask.

EditI've just attached the correct version of the FX file to this post. It is functionally the same as the one in the zip file but is hopefully a bit more readable.

You never cease to amaze me with your shader knowledge.
What can we do to convince you to bring your talents to the AppGameKit coding?

Make me 20 years younger perhaps? I'm in desperate need of a Dr Who style regeneration at the moment.

Perlin noise by design should tile as long as the image is a power of 2, right?

Not necessarily. You need to make sure that the tangents calculated during the process match along the edges and corners. Yes, you can design it that way (which is what I have done in effect) but you don't have to. In fact the shader is much simpler if you don't require a seamless image which was one of the techniques in my earlier thread.

Just noticed that the fx file that I included in the zip file is not the latest version. The latest version has a number of cosmetic changes to make it a bit more readable. It is functionally the same though.

I've attached the latest version as a separate file in the original post.

Nice one!
Also wow, that's a really funky way to generate pseudo-random numbers on the GPU. I've set to just building a buffer (or texture if using <SM4) with "random" numbers on the CPU side and then sequentially indexed into it on the shader side, but that sure looks intriguing... I wonder though, how efficient is it? Might be worth changing for that if it's fast enough

Yes, I wonder about the efficiency issue too, but decided it had to be far faster than umpteen texture lookups per pixel. I could be wrong though - and it was tidier not having to keep track of an image. Food for thought though....

M,y impression is that maths is very fast on modern GPUs but texture lookups can be slow. It used to be the case that it was worth replacing a few lines of maths with a texture lookup, but I'm not sure that is the case now.

There is also the benefit of reduced RAM consumption. Textures can really eat up all of your game's texture memory the more high-res you go. With some perlin noise, and couple of luminosity and colour maps, you could generate quite a large number of materials, star fields and terrain fields.

Yes, that might be relevant as well. However, I think Ken Perlin's original implementation used only a small set of directions plus some crafty indexing into that set to get his final direction when required. It's the crafty indexing bit that I don't know how to implement efficiently. I think some kind of hashing might be involved.