KdotJPG
What kind of things can be generalized?
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?
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.
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.
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?
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!
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.
I never even started on this, despite having wanted to for a while, so I'm still interested in any new developments/explanations/improvements 😄
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 :)
FWIW I just updated the repo with new instancelessly-seedable versions, which also greatly reduce the use of lookup tables.
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?