Interesting. Might try that, but I suspect performance is worse than the standard rand() floating around. Gonna run some tests.
@theagentd: That code shadertoy code is a mess. Noise functions have an analytic derivativeā¦no need to approximate. Baking a multi-resolution noise into an atlas of corner wang tiles could be an option.
Ugghā¦thatās horrible. If youāre going to use integers on the GPU and donāt know what youāre doingā¦use something statistically sound (and faster) that someone who does know what theyāre doing has already written for you. (one-at-a-time was written in 97ā¦the hash world has changed alot since then. A 10 dep-chain 32-bit hash function is very long these days)
Yepp, according to the author, the performance is worse than the fract(sin(ā¦)) approach, but it has so far absolutely no visible patterns, which was the main concern for me. But according to @Roquen it sure can be optimized.
I know, but thereās an added layer where the input to a sin/cos-based function is based on both UV and noise(UV), so youād need to do some f(g(x)) derivative magic to calculate it analytically. Itās definitely doable, but again I canāt use his code directly.
Well, what are you waiting for? Out with it! 
EDIT: And if you canāt beat that hash function at speed, it still has its uses.
EDIT: It might be possible to optimize that noise function at the cost of some accuracy. Since we only use the lower 23 bits, wouldnāt it be possible to reduce the accuracy even lower to 16-bit and compute it twice as fast by packing it into a 32-bit integer?
EDIT2: GPU ShaderAnalyzer says that hash function has around 65% more instructions (28 vs 17), but they also pipeline a lot less effectively on vector GPUs (26 vs 10 ALU clocks). That only matters on older AMD GPUs though. Gonna benchmark it in real life though.
EDIT3: In a real-life benchmark, computing 64 random numbers per pixel, the 2D hash-based random() takes over 3x as much time as the old sin-fract rand(). Comparison of noise quality: http://screenshotcomparison.com/comparison/153401. The biggest difference for the eye is that the new one doesnāt have these awful horizontal lines of black and red pixels (if you look closely).
Are there any game engines like Unity3D and Unreal Engine made in Java? I mean, thereās jMoneyEngine, which is more for people who actually know coding. But you donāt need to know coding to make games with Unity3D and Unreal Engine, because engines like those just pamper you all the way. Iām planning on making a game engine like that: something with a visual workflow and something thatās not necessarily for people who know coding.
EDIT: Sorry, I hate game engines like those, because they really do pamper you all the way, and I hate being pampered. Nah, I aināt gonna make an engine like that.
Oops, accidental medalā¦
Thereās this weird stigma around those game engines that I grew out of. I used to think āhah, those n00bz donāt actually know how to make games! They donāt code!ā. Which is partially true, a lot of the people that use those engines donāt know much about programming. But then you go back to your IDE and hack away for the next couple days and you might have a new feature finished. And then you realize those game engines could have implemented that same feature for you in mere seconds.
Those game engines are targeted towards people who want to finish games. Some people just want to smash a game out with little programming, and thatās fine! I enjoy building games from (almost) the ground up, so I donāt use them. But if my company suddenly because EA2 and I was tasked to created Battlefield Bad Company 32, no way in hell would I be starting from the bottom with a simple graphics processing library like LibGDX.
I know itās hard to see it now, but those engines arenāt āpamperingā people. Itās a strange mentality to see; New game developers thinking game engines āpamperā people. I think many of the more experienced game developers on here would agree with me when I say that developing a game from the ground up is much, much harder than using one of those engines (once you get the hang of them). So donāt discredit those engines solely because you donāt have to program much. Instead, rejoice because they exist and you have the opportunity to use them for free.
/Monday morning pre-coffee motivational/rant speech
Getting into specifics would require carefully going over the code. My rough suggestion is corner-wang tiles of some composed noise w/baked normals. Compose 2 (or perhaps more for very quality levels) layers of this and combine the normal via one of the techniques used in applying a normal map. Thereās also the option of using the glsl derivative functionsā¦but Iām guessing that would be pretty noisy. (https://dl.dropboxusercontent.com/u/55891920/papers/mm_sfgrad_bump.pdf)
Too many use-cases. In your case, Iām suggesting to move almost all of the work out of the pixel shader anyway, so itās moot.
On this specific example, you donāt need to know anything about hashing for red-flags to start popping up: āThe way I combined the inputs is totally arbitrary and rather lazy. I just experimented with them until I found something that worked on my test inputs.ā
And if you know āa little bitā about modern hashing, it results in banging your head on the table:
uint hash( uint x ) {
x += ( x << 10u );
x ^= ( x >> 6u );
x += ( x << 3u );
x ^= ( x >> 11u );
x += ( x << 15u );
return x;
}
uint hash( uvec2 v ) { return hash( v.x ^ hash(v.y) ); }
Jenkinās one-at-a-time is modern in design. hash blobs of data and then āfinalizeā when youāre done. The hash the author wrote is hash one 32-bit blob and finalize. See the problem?
uint hashInit(uint x) {
x += (x << 10u);
x ^= (x >> 6u);
return x;
}
uint hashAdd(uint x, uint hash ) {
hash += x;
hash += (hash << 10u);
hash ^= (hash >> 6u);
return hash;
}
uint hashFinal(uint hash) {
hash += (hash << 3u);
hash ^= (hash >> 11u);
hash += (hash << 15u);
}
uint hash(uint v) { return hashFinal(hashInit(v)); }
uint hash(uvec2 v) { return hashFinal(hashAdd(v.y, hashInit(v.x))); }
uint hash(uvec3 v) { return hashFinal(hashAdd(v.z, hashAdd(v.y, hashInit(v.x)))); }
Assuming I didnāt screw up typing in post. But itās not helpful. Generalized hashing assumes 1D data. It assume keys are not low entropy, although it does assume some chunks might vary by one āvalueā. So using a general hashing function for 2,3,4D data vary by counting (ā¦,-2,-1,0,1,ā¦) typically really sucks. (Either has visible defects or is very slow if not both).
Fast n dimensional hashing on integer grid is tough.
Is the penetration of GPUs that can perform integer ops at full-speed approaching the point where using integer ops is reasonable? I havenāt been paying attention.
Sure, I get it. Itās just that those game engines arenāt really meant for serious programmers, because I think a real programmer would appreciate having a challenge to overcome. Like you said, those game engine are for people who want to get things done without dealing much with the backend stuff (scripting, etc.) So itās for people who prefer admiring the result to overcoming obstacles during the creation process. I think a real programmer wouldnāt care about the end result as much as the process; coming up with new algorithms, typing away for hours, drinking gallons of coffee to keep them goingā¦thatās the sort of thing programmers like. Game engines like UE4, Unity3Dā¦they take that away from programmers. Well, not so much Unity3D, but Unreal Engine and Cry Engine? They just take away what it means to be a real programmer. But thatās just my opinion. People who use those engines would definitely disagree with me.
@Roquen: Itās pretty easy to use
to analytically calculate the derivative. Then you can just sum up the height and derivatives of each octave, and finally calculate the normal as normalize(gradient.x, 1.0, gradient.y) (assuming Y is up). Thatās what I do now and it itās accurate. Using hardware gradients (dFdx/y) doesnāt work since you get almost the same gradient in a 2x2 pixel quad, which causes the normal to look low-res.
GPUs have supported integer arithmetic at full speed since OGL3.
Iām not going to argue my point because youāre allowed to have your opinion (obviously), but I just want to you to try to keep an open mind when it comes to these things. Sometimes a āreal programmerā does not want to build things from the ground up, hacking away and drinking gallons of coffee. Case in point; most developers in a business oriented /money-earning setting. Hobby devs have the luxury of no deadlines (unless they are āself-inflictedā) where professional devs do not, which allows the hobby dev to spend those precious hours building something from the ground up.
People get into programming for different reasons. Some people like the process, some people like the end result. Eventually, though, everyone wants to streamline the process and reach their goal in a smarter way. Youāll get to that point someday and youāll understand then why āreal programmersā also use game engines when they are the right tool for the job.
In danger of veering into the chitchat monster ā¦ what tends to rub some people up the wrong way is when people take these so-called āshortcutsā to end results but then get stymied by trivial problems that they could otherwise have solved if they had any deeper understanding of what they were doing, which they would almost certainly have gained by starting from scratch or at least working on the job for a few years. And thatās not the bit that actually makes people grind their teeth - itās when said developers bother everyone else on the internet for answers. Continually.
The same thing happens with Plain Old Java. Programmers who have never had to deal with C have no real understanding underneath how a JVM might be working and subsequently are quite clueless in Java about memory allocation and garbage collection and how references work. Itās irritating as hell but these days Java is the first exposure most programmers are actually getting to programming.
Cas 
Yepā¦just tossing out some cheats that might be lower latency. On int ops thereās ogl3 hardware where int ops have significantly longer latency than FP. Assuming Iām not misremembering.
You on an imaginary JGO back a few decades:
The same thing happens with Plain Old C. Programmers who have never had to deal with x86 assembly have no real understanding underneath how a processor might be working and subsequently are quite clueless in C about instruction scheduling and latencies. Itās irritating as hell but these days C is the first exposure most programmers are actually getting to programming.
And so it goes. Though as each step builds on the foundations of the previous step, the shakiness at the top gets worse the higher up the stack you go.
BWT I really rate Unityā¦ but beware, it is a honey trap. Unless already well versed in game design, programming, project management, etc. youāll just end up with total mediocrity. It is really only a shortcut to rendering fairly nice stuff in 3D made easy, nothing more.
Cas
I agree you should have a foundation before you start using those tools, as with everything. I was talking to someone on Reddit the other day who was in complete dismay that I believe you should at least understand how basic file IO works in Java before using Apache Commons IO. He thought it shouldnāt matter that you know how these things work internally, something I strongly believe the opposite of.
I just want to point out that āreal programmersā use the right tool for the job, and discrediting game engines simply because they provide lots of abstraction over a complex practice isnāt looking at the tool with an open mind. Either way you go about it, game development is difficult. But so long as you know what you are doing, why does it matter how you reach the end result? I believe a āreal programmerā knows his/her programming theories very well because they have built these engines firsthand, but I also believe that they know how to use the right tool to get something done. Just because one way does not involve lots of āgruntā work does not mean itās pampering said developer. That developer is utilizing what he/she has around them, which is smart.
Use whichever method you like, it really does not matter so long as you are satisfied but just keep in mind that that the idea of being a āreal developerā differs from person to person.
WHAT IF I CODE DIRECTLY IN BINARY, HAH! :
-ClaasJG
It changes your understanding of usual things in programming
Like Java programmer that first time see unsigned value or multiply extend object,
or 2+ return values from function, or out of bounds function GO TO =)