Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / A new shader demo for creating tilable Perlin noise images

Author
Message
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 14th Feb 2017 21:45 Edited at: 15th Feb 2017 23:52
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.


Powered by Free Banners

Attachments

Login to view attachments
Stab in the Dark software
Valued Member
15
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 14th Feb 2017 22:35
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?
The coffee is lovely dark and deep,and I have code to write before I sleep.
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 14th Feb 2017 23:28
Make me 20 years younger perhaps? I'm in desperate need of a Dr Who style regeneration at the moment.


Powered by Free Banners
Phaelax
DBPro Master
14
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 15th Feb 2017 01:59
Perlin noise by design should tile as long as the image is a power of 2, right?

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 15th Feb 2017 11:38
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.


Powered by Free Banners
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 15th Feb 2017 23:47
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.


Powered by Free Banners
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 18th Feb 2017 09:25
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
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 19th Feb 2017 23:08
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.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Feb 2017 17:12 Edited at: 20th Feb 2017 17:13
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.
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 20th Feb 2017 21:12
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.

Login to post a reply

Server time is: 2017-12-15 13:53:53
Your offset time is: 2017-12-15 13:53:53