Simplex Noise functions (2D, 3D, and 4D) #1268
Comments
|
You would want 4d noise too, so you can get noise in 3d + time. That said, it makes considerably more sense to find and use existing glsl code yourself in shaders rather than use in gdscript (where it would be running in c++ underneath). The parallelism of the video card would make the calculations manythousands of times faster to be real time. |
|
@spooner Great point with the 4d noise and using shaders whenever possible. Rethinking this, I can't really come up with any real use case where it would be favourable to use simplex noise in CPU time over GPU. It might still be favourable for light one-off things, but even for stuff like voxel engines, generating initial block placement would probably best be done with fragment shaders.. |
|
I'd like to also suggest the addition of Voronoi/Worley noise and Musgrave noise. Both are useful for procedural generation, especially when used in combination with one another. |
|
Okay, apparently simplex noise is covered by a patent for implementations using three or more dimensions. There is, however, an alternative implementation called OpenSimplex that skirts the patent issues, though afaik it is only implemented in Java. |
|
Found an implementation of opensimplex written in C: https://github.com/smcameron/open-simplex-noise-in-c |
akien-mga
changed the title
|
The problem with simplex noise is that its patent protected. One would have to chose an implementation that avoids to be covered by the patent's claims. |
|
@est31 Which is why I suggested OpenSimplex, which (despite the name) is NOT based off of the patented implementation of Simplex. |
|
Coming from 2d game dev, I've used noise functions extensively in my games, and never in shaders. So I would have to vote to keep it out of the shader-related stuff :) |
|
Until its supported natively by godot, there is a 2D/3D simplex implementation in gdscript: https://github.com/OvermindDL1/Godot-Helpers/blob/master/Simplex/Simplex.gd |
|
Someone wrote a C version of simplex noise. I think will be of much help with implementing it in the core game engine. https://github.com/smcameron/open-simplex-noise-in-c. If I get time I'll try to make a module for it meanwhile (if no one else beats me to it :d) |
|
@razvanc-r It is worth noting that it is Open Simplex, not Simplex. The implementation is different than that of Simplex, and (importantly) is not encumbered by patents. |
|
It would be nice to have noise functionality in godot 👍 |
|
I'm playing with terrain generation and noise functions would be very useful to speed up GDScript implementations. I tried with shaders but in Godot it feels too limited yet and I don't know if it can multi-thread well (maybe with Vulkan compute shaders in the future?). I also found this library, FastNoise, which is MIT-licensed: https://github.com/Auburns/FastNoise. I would also point out that not only a noise3d(x,y,z) is good to have, but also noise3d(x,y,z, grid) so we can ask C++ to generate a whole grid of values at once, in various formats (floats, bytes, flags...). Side note: composing arrays of 1D, 2D, 3D numbers could be implemented outside the scope of noise generation. It sounds like something a GPU does with textures already, but would still be of use on multi-thread CPUs for non-graphic number crunching, if the GPU is already used a lot of lacks features. |
|
I've just got FastNoise to work in Godot as a module. World generation is blazing fast now :) # A glimpse of the usage
var noise = Noise.new()
noise.set_seed(666)
noise.set_frequency(32)
noise.set_octaves(3)
...
var h = noise.get_noise_3d(x, y, t)But I read about the patent issues with Simplex noise so I also started to integrate OpenSimplex, following the same kind of GDScript interface. A notable difference is that by design, OpenSimplex allocates memory for permutations per noise instance, which FastNoise doesn't. It shouldn't be a serious issue because it's uncommon to have many instances of noise generators, but might be worth mentionning. |
|
I finished an OpenSimplex Godot integration :) |
bdero
changed the title
|
Thank you for your work @Zylann , I took a look and it looks like a great implementation. The native inclusion of the fractal noise class seems epecially good, since it covers probably the most common use pattern. Edit: Oops, I just realized the license in the |
|
The license of the OpenSimplex C library is public domain. |
|
Oh!!! I can't wait to check your wrapper, thanks Zylann!! |
|
Just in case, here is my FastNoise integration I was talking about earlier: https://github.com/Zylann/godot_fastnoise |
|
Apparently the patent on Simplex noise (referred as Perlin Noise) covers its use for image generation: "A method for generating images" |
|
I am no lawyer, but isn't the terrain displayed on the screen via images (aka "frames")? So its probably fine if you don't display the generated terrain on an image. |
|
Why isn't this bundled with the engine already? :) |
Because nobody sent any PR... |
|
Lets wait until we can supply binary modules for 3.0, then we bundle this
|
|
Oh, didn't know there's plan to add binary modules. That would be great cause to recompile it every time... well, that's why I don't use these modules now :). Probably not only me either. |
|
Yeah I've been eyeing that libnoise myself, and I do agree that noise is useful in more way's than just the one. :) However my point still stands, as far as shaders are concerned all we need is to be able to do iteration in shaders to generate our own noise, and I'm inclined to say that noise can already be generated in GDScript. |
|
Personally, for some game projects I often need more than shaders (in which I actually sample textures, which is faster), and when I do for other purposes it's usually a huge CPU bottleneck when done in GDScript. My requirements are usually the ability to setup seeds and query any point in 1, 2, 3 or 4D infinite seamless space, with preferably as less memory allocations as possible. |
|
Oh, yeah, fastnoise is a compatible license so a definite +1 to that. :) |
|
@reduz OpenSimplexNoise would be a DLScript? Or when you said "bundle", did you mean Godot will be bundled with some modules that will be supported in official export templates rather than being 3rd party? Also, the fact OpenSimplexNoise would be a DLScript implies that C++ code making use of it without overhead would also have to be a DLScript... |
|
@Zylann are we thinking your noise module would be integrated for the 3.1 release, or is this something that would have to be a GDNative submodule for some reason (would prefer a module implementation)? |
|
Given how widespread the usage is, a module would be great. I made an OpenSimplex implementation as a module, feel free to check it out |
|
I thought you used FastNoise too though? @Zylann |
|
Would be fine too (might even be better) if you don't mind patents |
|
@Zylann How would patents get involved? FastNoise is MIT-licensed, so there shouldn't be any issue in integrating a Noise Reference-type into Godot (I would think). |
|
It's not about the implementation license, but the patent on the method itself. I think it was mentionned earlier in this thread |
|
@Zylann Ohhhh, I get it now. So you were wanting to substitute the portions of FastNoise that would infringe on the patent for 2D content with Open Simplex implementations? Or are we just doing Open Simplex all the way? |
|
Put shortly, I prefer FastNoise because it is faster, lighter in memory and has more features. But due to patents I also ported an OpenSimplex module, which is slower, has less features and allocates more memory. I didn't write the libs, and I didn't work on mixing them because I use my free time for other things at the moment :p |
|
So due to that, I proposed OpenSimplex all the way despite my preference, but feem free to tweak the module. |
|
I suppose this patent is active only in empire of evil(USA) :) Because in Russia and Europe patents for program methods are not exist. I wonder if someone decided to push game with patented FastNoise algo to Steam the problems could happens ? However its not easy provably... |
This is not the right way to think. And probably false, if they know the game is made in Godot, which has the source available, it's easy to connect the dots. Patent for software and algorithms does not exist AFAIK, but this case falls into a sort of grey area, since it's described as an "apparatus" which includes a computer and a display. Nevertheless, I'm not a lawyer and don't know all the implications of it, therefore I would be on the safe side. If someone with proper knowledge of the USA law explain why this would be okay, then fine, otherwise I prefer the status quo. In any case, the patent only covers image generation. The problem is if some user unknowingly uses it to create images in the game, which could cause them trouble and such trouble likely would fall into Godot's lap since they were just using the engine. |
|
Ah, then having it as separate library is the only option. Pushing slow unpatented version to Godot does not firstly seems like a good idea, but if someone would prefer to use faster version instead slower for image generation, this fact will be hidden(if not open source) by slow version and hardly proven(I guess Godot binary is not easy for decompile). Am I on the right way to think ? :) |
|
Well, I'm trying to create a unified implementation that uses FastNoise in most cases, but suddenly switches over to OpenSimplex any time you want to do a 2D simplex noise operation. |
|
@Chaosus technically, OpenSimplex should still be faster than PerlinNoise, only slower than Simplex. |
|
And maybe performance is not so critical for this, because it called usually several times at level creation step and not in process function.. Not much games uses noise for generate level chunks on fly. And for graphical part of shaders there is already existed assets in Asset library... |
|
Any progress on this so far? |
|
If we add 4D noise, it may be worthwhile to add 4D math types first (such as Vector4). |
|
For note, 5D and higher noise has immense uses as well, don't just constrain it to lower dimensions. It is not hard to create an N-Dimension version of the algorithm (though I did that via C++ templates long long ago so the usages got optimized extremely well, and I think I was using perlin then...). |
|
For 5+ D noise, it would make sense to add it since it is useful, but I would suggest only as a generic-ish function. For example, a function accepts float arrays, and passing an array of 7 floats = 7D noise. |
That's what I did in C++, if it could statically know the size of the array then it generated optimized code, else it fell back to recursion (which depending on what was being done could be about the same speed or a lot slower, depending on how well SSE could be used). |
|
I went ahead and added open-simplex-noise as a Godot module in #21569. Just commenting here in case someone wants to improve on it (maybe add 5+D noise?) since I won't be working on it in the near future. If anyone wants to work on it I'm open to answering questions. |
Simplex Noise (also known as improved Perlin Noise) has many uses in modern game development, as it lies at the heart of procedural generation. Infinite terrain, voxel worlds, clouds, and just about any texture with realistic, natural patterns can be generated using Simplex Noise. It's commonplace in modern game engines.
Simple examples of simplex noise use:
Example implementations:
Fortunately, it's also pretty easy to implement.
The ideal implementation would involve allowing the user to set the RNG's seed somehow (whether it's set using a separate function in advance or passed as a parameter to the noise functions), and exposing the noise functions in "@GDscript", which might look something like this:
The text was updated successfully, but these errors were encountered: