Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Shades]

But accessing this data would be fastest if you used your noise function to fill out an array first, unless you need to dynamically get new values.

so "give a random value for x=1, y=2.00056, z=0.1111039"

His range of locations seems a little continuous to sensibly do this.

[Max White]

Eh, it might be another case of levels that go on forever. Feels like I'm playing stone soup in theory.

See this is why I wish people would describe the problem domain.

[Starver]

But accessing this data would be fastest if you used your noise function to fill out an array first, unless you need to dynamically get new values.

If I was to be repeatedly accessing the values of various points[1], then I think I'd have a scratch-storage for the most recent thousand-or-million points[2].  Discard the unused (or shunt values/deltas to long-term off-memory storage, if you want to keep some changed information).

If I was just wanting each value once, then if generating the huge array is no more complicated than "for p[v,w,x,y,z] I want fn(v,w,x,y,z)", then generating the entire set to storage and then randomly accessing it may give more overhead than merely doing the fn(v,w,x,y,z) as required.

But I'm absolutely not certain what requirements the OP to this issue is looking to fulfil, I'm just talking in general.  And possibly also out of the top of my hat. 


[1] Either the original ones or ones recalculated with reference to neighbours...  Reminds me of something I once did, only that was just in three dimensions (excluding 'time', but that was fully deterministic to the initial three dimensions of randomness, so it wasn't even a fractal, technically).

[2] Depending on data size and overheads needed for such a hash-type storage, plus whatever 'age' data is needed to maintain the oldest-out mechanism once it hits the top limit.  This way, a fairly quick and low cost re-accessibility of previously calculated data, on the understanding that stagnant data might well have shifted out of the short term storage if it takes a while to re-query it all.  B-Tree, R-Tree and related methods might also be useful culling alternatives to the age one, and probably better with space-related arrays.  You could even maintain a relatively small dynamic array that (through a jumping offset associated with each axis, plus a value to indicate where the nominally 'wrap-around' data's real 'edges' are, in the array (a mere two extra chunks (words?) of data per axis!), to save on excessive shuffling if you wander over a point-step or two) covers say 100^5 points surrounding your particular area of interest, and lets you handly a lot of data in bulk in short-term memory and fish out/throw back data from/to long term storage (if applicable) in much more efficient larger quantities at a time.  Again, probably no relevance to OP, but a general idea.  Probably badly/insufficiently/excessively[*delete as inapplicable] explained.

[Siquo]

But accessing this data would be fastest if you used your noise function to fill out an array first, unless you need to dynamically get new values.

If I was to be repeatedly accessing the values of various points[1], then I think I'd have a scratch-storage for the most recent thousand-or-million points[2].  Discard the unused (or shunt values/deltas to long-term off-memory storage, if you want to keep some changed information).

Yes. A few points will be revisited during one run, so I'll have a small cache for those.
Re-seeding the Mersenne is expensive, that's why that won't work.

Shades got it spot on, that's what I was looking for. Implementation commencing.

Usage: ALL The Things!
Terrain, cloud shapes, textures, shaders, mesh randomisation, ore-veins, tree shape, vascular structure in a leaf, fur patterns, limb movement, wind & weather patterns, ALL THE THINGS

[Valid_Dark]

Color me interested,  can you go into a little more detail as to how you're going to use said values?

[Max White]

These structures that you describe, most exist in either 3d, or 4d. Fuck, you could debate that a landscape starts as a 2d height map! What do you need 5 for?

[Shades]

These structures that you describe, most exist in either 3d, or 4d. Fuck, you could debate that a landscape starts as a 2d height map! What do you need 5 for?

I generally find my use of noise is all in 2d. I'd also use fractals for any natural plant forms rather than pure noise as you tend to get nicer visuals (but this of course depends what you use is)
What kind of limb movements are you using this for?

[Siquo]

What kind of limb movements are you using this for?

Random "noise" movement. A creature that stands completely still is unnatural. There's always a bit of swaying back and forth. Tree-limbs as well, with more swaying in high winds (doing that with physics is too heavy).

These structures that you describe, most exist in either 3d, or 4d. Fuck, you could debate that a landscape starts as a 2d height map! What do you need 5 for?

Landscapes are not 2D  . I had to build my own terrain-paging-engine for that as except for Minecraft and DF there's hardly a game out there with 3D terrain.

I'm not going to need 5... probably. I thought the extra one might come in handy for actual weather patterns (instead of just morphing clouds, which is 4D).

Color me interested,  can you go into a little more detail as to how you're going to use said values?

NOISE ALL THE THINGS!

I'd also use fractals for any natural plant forms rather than pure noise as you tend to get nicer visuals (but this of course depends what you use is)

True dat, but too slow, this is going to be on-the-fly generation.

[Shades]

Landscapes are not 2D  . I had to build my own terrain-paging-engine for that as except for Minecraft and DF there's hardly a game out there with 3D terrain.

This is true but I always found 3d noise generated landscapes didn't really work and multiple layers of input data from 2d noise (height maps, water tables, wind/erroision graphs and the like) seemed to work better. Although it should be possible to do it with 3d noise as well. If you find a nice technique I'd love to hear about it.

[Siquo]

Yeah, I'm still thinking on how to balance those two, and on how to prevent floating islands. Might be that I'll use a height map anyway, and then spice it up later with erosion features. Found a nice and fast noise implementation for up to 4 dimensions that'll work fine for now. 3d noise is nice for the "finishing touch", roughening the edges. Right now my engine just draws clean geometry which looks as natural as... Cher.

[Max White]

Well you have three values to work with in a 2d array. X and y, and the value of x and y that makes height. That is sort of how height maps work, and they are a good jump off point for level gen. 1d noise would be good for a 2d level because you would have x, and a function for x to make y.

[Siquo]

My gripe with heightmaps is that it creates terrain that looks like a sheet draped over some objects, but it's still a sheet, and the sheet itself is still 2-dimensional. It doesn't allow for overhangs, caves, ridges, arches, etc. I think I might use a heightmap to start with, and then erode awesome features into that landscape in a second pass.

[Max White]

Right, I keep thinking you have the luxury of a finite sized map. In that case a height map to start with, and then from there you can add more depth would be ideal. However, the need to extract block data from a three coordinate function is rather limiting in that regard.

Unless you do what I believe dwarf fortress does, and that is to build large blocks, starting from a height map, and treat these blocks as maps of finite size, but stitch them together and load up a new one in the background when you get close to the edge of a block... Sort of a middle ground.

[Siquo]

Unless you do what I believe dwarf fortress does, and that is to build large blocks, starting from a height map, and treat these blocks as maps of finite size, but stitch them together and load up a new one in the background when you get close to the edge of a block... Sort of a middle ground.

Both. Right now it uses paging like that (load up 3D blocks of map once you get closer), but it also subdivides that block (octreestyle yo) once you get closer, generating/loading 8 more blocks of greater detail, and that process can be repeated an X number of times. In essence I want to be able to get small mole-hills and huge mountain ranges, in the same view. This requires some extra stitching at the edges, and will give some popping of features while loading, but that can't be avoided.

As my intended release date is somewhere in 2030, I believe computers will be fast enough by then to render this in real time

[Nadaka]

It sounds like you need a terrain algorithm with a variable depth of resolution, so you can draw the distant lands in low detail, but close ones in high detail.

I know you hate it, but diamond square has this property. I would also note that diamond square doesn't just have to be for height maps. You could convert it to romboid cube algorithm easily enough where the values generated produce a "density" that maps to solid or empty space. That would allow for much more "3d" terrain, but it might be difficult to make it look normal.