height field to sphere?

[xoxos]

i haven't ventured further into 3d than the calculation of 3d points in the frustrum for wireframe graphics, so i'm not sure what i'm missing to answer this on my own.

accordingly, i understand the concept of projection (apart from cartographic references, projection is the introductory topic for this 2 hour movie on visualisation of higher dimensions.. modeled in pov-ray, where i have experienced the application of height fields to spheres
http://dimensions-math.org/

i've been mulling over exactly how one would apply a height field to a sphere, and i think i must have the basic idea wrong.

being aware that points towards the upper and lower edges of a 2d height field are applied to increasingly smaller diameters, what i am visualising is the generation of standard 2d noise image, then translating this to the spherical height field by using an increasingly smaller width of pixels towards the upper and lower edges, using a sinusoidal 'lemon' shaped region of the source height field.

to reword for clarity, the output 'product' height field is sourced from a region of a temporary 'source' height field that is shaped like a lemon, with the points tangent to the top and bottom. amplitude is scaled/reduced for samples towards the top and bottom.

well.. the obvious issue with this method is that if you are using a method of interpolation using more than the immediate samples (eg. the preferred bicubic interpolation for perlin noise) you are up a very complex creek (eg. as one would have to wrap points of interpolation, requiring having to perform stages of intermediary interpolation..)


i feel certain that the predominant method must be more sensible than what i am envisioning, which seems to be lemon shaped.

reading?

[xoxos]

(kinda long but perhaps a good introductory link for this site)
dimensions-math on youtube..
http://www.youtube.com/watch?v=6cpTEPT5i0A
jump to 7:08 for mapping

[waldronate]

Use a higher-dimensional noise (3D or 4D) to directly give you your height samples on the sphere (which can then be reprojected to a flat map using the projection of your choice). This technique also has no seams anywhere.

Another choice for working space is to use a square with the north and south poles at opposite corners. It isn't exactly perfect, but it's much simpler to manage if you're trying to paint onto the height field.

A popular choice is to use a set of height maps rather than a single height map. A basic cube map works well because the 6 sides can be done as individual height maps or they can be done with a single map (that loses a fair amount of space).

[xoxos]

Use a higher-dimensional noise (3D or 4D) to directly give you your height samples on the sphere (which can then be reprojected to a flat map using the projection of your choice). This technique also has no seams anywhere.

! that's the proverbial ticket!

makes sense, really, sphere, 3 dimensions..

[xoxos]

mr. waldronate -

i don't really want to get into this, because there is obviously a great discrepancy between our eruditions and experience, which cannot be translated in the course of a forum discussion, so no slight if you choose not to respond.

my perlin uses a base array of 256 so i can index with unsigned chars for faster bicubic interpolation.

2d requires five bicubic interpolation operations, 3d requires 21.

to create a bicubic 2048 * 1536 2d height field of 8 octaves takes my 1.6g processor about 8 seconds, which is going to take 4 times longer with 3d. in comparison, wilbur is practically instantaneous.


audio is a competitive field, so i'm fairly confident regarding the efficiency of my operations.. (my algo may have some slack in it, but i doubt a critical amount) so i see the difference as possibly due to..

using the graphics device for math, which i have no experience with yet, and may be the key factor
using a lower res/octave for editing, perhaps keeping an edit map with is applied to a higher octave render at output
(i doubt it, but possibly using a lower than screen image resolution for data)
(also doubt it, possibly using a faster interpolation technique as perhaps the artifacts aren't so obvious in 3d)

in five syllables or less, why are you awesome?



OT:
for those interested or have input that may result in a more useful product, i very much enjoy algorithmic generation, and i believe what i'm driving towards is ~a more/fully automatic world generator, with minimal parameterisation and climate, road and political mapping, none of which will be particularly refined as i'm more interested in the practice, still, it's always nice to have something that isn't completely worthless at the end.

[waldronate]

Why am I so awesome? Practice!

Wilbur uses the basic Musgrave and Perlin code (well, slight variation, but not from a performance perspective). It stores the data as a floating-point surface and renders from there. Convenience of programming was always the important part. It's all C/C++ code, compiled with reasonable optimizations. Note that Wilbur always does a 3D noise solution rather than 2D.

(Assuming x86/x64): On any semi-modern processor, it may be faster to use native-sized variables rather than unsigned characters. Depending on your processor, floating-point multiplies may be faster than integer (but not a lot). Compiling with SSE2 (if available) may aso speed up float-based math a bit. Using OpenMP or other multi-threading library to share the work across all available cores will also help. Truncation float float to integer can eat a lot of time if you do float operations and aren't using SSE2. http://stackoverflow.com/questions/2...odern-hardware has some good discussions on the subject.

My spiffy new i7-3770 calculates the 2048*1536 image (including generating displaying the lighted image) in under a second. Adjusting for number of cores, processor speed, architecture, and so on suggests that your code is in the ballpark of the Wilbur code speed.

If you want a less computationally expensive basis function that's reasonable, do an Internet search for "simplex noise".

[xoxos]

Practice!

hehe, he's just kidding, folks. waldronate's secret is that he only uses Vim™ brand development tools.

thanks for the speed comparison. it's common to handle float to int with assembly in audio.. hosts used to include cpu meters making performance one of the most publicly criticised features (i remember metering someone's implementation and being able to discern the word length they were using for certain oscillator variables..)

expect i'll downsize my perlin array to 32^3. i was using 16 across for my lowest octave on the HF, looked okay. deliberating using floats

[Hai-Etlik]

hehe, he's just kidding, folks. waldronate's secret is that he only uses Vim™ brand development tools.

vi isn't a brand, it's a heinous cult that mocks the holy perfection that is EMACS.

[xoxos]

documenting progress as such..

"equirectangular" projection commonly used for spherical height fields in ray tracing.

mapped to 4096 by 2048.. one octave takes my 1.6g about 11 seconds..
musgrave1.jpg

proof of sphericality - imported to pov-ray, map_type 1
spherical.jpg


8 octaves took 60-70 seconds. should i ever release this as an app, preinstallation requirements will include a bong (which i do not have) because there's no bloody way anyone's sticking around for it to finish otherwise.
ridged.png

currently depending on manual editing to inhibit continents being a bunch of windy lines. considering a voronoi type process to define plates. i'd like to try an evolutionary algorithm that rotates the plates and/or produces aggregation or what have you. deliberating how involved i want to get considering the research.. fishing for a simpler solution (which could resolve to manual editing..)

[Hai-Etlik]

currently depending on manual editing to inhibit continents being a bunch of windy lines. considering a voronoi type process to define plates. i'd like to try an evolutionary algorithm that rotates the plates and/or produces aggregation or what have you. deliberating how involved i want to get considering the research.. fishing for a simpler solution (which could resolve to manual editing..)

Yeah I did some digging into voronoi algorithms on the surface of a sphere too, but didn't get very far. The only implementation I recall finding was part of a pack of tools written in FORTRAN.