[MUD-Dev] Rooms, 3D arrays, etc.

[Miroslav Silovic]

> >It occurs to me now that the *order* in which points are computed is
> >very important. The goal is to minimize the number of seeds that must
> >be stored, but still be able to compute down to some point without
> >having to compute hundreds of other points on the way. The problem is
> >the random number generator requiring that each generated number be
> >used in exactly the same way in order to reproduce the terrain
> >correctly.
> 
> Not only that, but you will get into side effect problems where
> generating the sequence to derive from A from B results in a certain
> value at B, but conversely generating the sequence from C to get B
> gets a different value.  This can get *really* hairy to track down and
> provably ensure will not happen.

Well, if you use some form of pseudorandom field, you can just add extra
dimension and then use it to tell the generator the component you want.
For instance, [x,y,1] turns into elevation, [x,y,2] gives the ground
growth, etc.

Pick my renderer from maja.zesoi.fer.hr/pub/tools/graphics/sart, then
look into mathutils.c - you'll find fractal generator, and smootherd
pseudonoise in there.

> >To clarify a bit, I don't think you can do this by using *just* the
> >co-ordinates as the seed, else you will get patterns in your terrain.
> >Hmm, is that what Miro's code example is doing - working hard to
> >remove any patterns that would show up, so that just the coordinates
> >can be used?
> 
> I haven't looked at his code in enough detail to say, tho I suspect
> so.  Miro?  

Right. It's not particularily good at it, either, it simply runs the
coordinates through standard modular random number generator,
cumulatively. I.e. it's little better than linear. Except that in final
pass, I use the result to look up in to a table of 10^4 pre-generated
random numbers, which completely disperses the pattern. You don't really
need more than 4 significant digits for pseudorandom noise, at least not
in 3D graphics, so this approach looks well (i.e. generates good-looking
fractal textures).

> >A conceptual problem I have is that if each level of the hierarchy
> >is, say, 16 x 16, then you only have 8 bits as your seed. That would
> >seem to restrict you to 256 possible outcomes, which is not random
> >enough. Hmm (thinking on the fly here), possibly the top level could
> >have fully stored seeds (that's only 256 of them), and all other
> >levels could use all bits at their level and all higher levels. That
> >gives 16 bits as the seed for each square in the second hierarchy
> >level. Oh yes, and you can merge in the stored seed, too - that ought
> >to be satisfactory.
> 
> Bingo.  For each coordinate, however far down the tree it is, take the
> entire set of key values from that location on up to the rood node and
> from that assemble one very large and detailed key value (ie longer
> bit streams).  Look at it this way:
> 
>   At the highest level the height variation is minimal.  When you are
> dealing with (say) 512x512 kilometer squares, the average height
> difference of any sqare as compared to another other adjacent square
> is likely to be minimal and easily quantifiable in a small ranged
> value.
> 
>   Conversely when you get down much smaller, say down to meters, the
> averge height variation can be *huge*.  cf The top and bottom of the
> Grand Canyon.  

Err, uhhhh... Note that you don't ever need to see the key. Just write
a cumulative random loop and feed bits of the key to it in each iteration.
Remember, you only need 32 bits on the output, and it'd be bad idea to
use bigger intermediate results.

Also, to generate good-looking terrain, you could combine two noise
functions, one used to determine the local fractal dimension of the
other. Resulting terrain (if you do it right) will look smooth at most
places, with *VERY* rocky and nasty parts where the noise function
decides to bump up the fractal dimension.

	Miro