search

KdotJPG / OpenSimplex2

Successors to OpenSimplex Noise, plus updated OpenSimplex.
Creative Commons Zero v1.0 Universal
559 stars 53 forks source link

What kind of things can be generalized? #1

Open s5bug opened 4 years ago

s5bug commented 4 years ago

Say, porting OpenSimplex to Scala:

def eval[N <: Nat](coords: Sized[N, Double])(implicit ev: OpenSimplex[N]): Double

What constants can't be calculated (i.e. they would have to be included in OpenSimplex)? Is it possible to generalize the algorithm over N?

KdotJPG commented 4 years ago

The versions released prior to now could not be generalized straightforwardly, but the 4D function in OpenSimplex2F I just released can be generalized to N dimensions. I may do a more detailed write-up of this at some point.

s5bug commented 4 years ago

Can the 4D function be generalized downwards?

KdotJPG commented 4 years ago

It can! In 3D you will have four A3 lattices spaced out by <0.25, 0.25, 0.25>, or in 2D you will have three A2 lattices spaced out by <0.333..., 0.333..., 0.333...>. The initial step of finding the closest point on the first lattice might differ. The one included for 4D generalizes straightforwardly to other even dimensions, but for odd dimensions it will require slight modifications.

s5bug commented 4 years ago

Where should I get started? I.e. what part of the code should I be looking at (and how should I figure out how certain constants/control structures were derived) to do so?

KdotJPG commented 4 years ago

I covered a bit of that in a post here. Should cover at least some of it. https://www.reddit.com/r/proceduralgeneration/comments/hm9bam/opensimplex2_4d_implementations_now_available_new/fxcyo2q/

Let me know if you have any more questions in particular!

szethh commented 2 years ago

Sorry to necro this thread, but I had a similar issue.

I'm trying to port OpenSimplex to Julia, and I'm trying to make an N-dimensional function, as opposed to having different functions for 2D, 3D, 4D...

First, is this even possible, or are there differences in the number of dimensions that make it not generalizable? I've taken the 4D (simplified) code as a foundation.

Most things I could figure out how to generalize from your reddit post, but I still don't understand how the gradient tables are computed. I would like to avoid any lookup tables, if possible. I know I would be sacrificing performance, but I would like to give this a try.

s5bug commented 2 years ago

I never even started on this, despite having wanted to for a while, so I'm still interested in any new developments/explanations/improvements 😄

szethh commented 2 years ago

Maybe @KdotJPG can offer some help on the lookup table issue. When I finish I will post the code on github too, maybe it helps others :)

KdotJPG commented 2 years ago

FWIW I just updated the repo with new instancelessly-seedable versions, which also greatly reduce the use of lookup tables.

szethh commented 2 years ago

Thanks, looks great!

However, I still have some questions... How are these tables generated? lookup4DVertexCodes and grad4 (or any gradN table, for that matter). Since I'm trying to port it to N dimensions, I need a way to generate these tables programatically. Is that possible?

Also, take for example the function noise4_ImproveXYZ_ImproveXZ. There are some constants multiplied to the input parameters (-0.21132486540518699998 etc). How are these calculated? Could they be generalized to more dimensions?