Update
This commit is contained in:
parent
3bef179616
commit
561ddf8822
20 changed files with 309 additions and 19 deletions
|
@ -14,11 +14,13 @@ Using [fractals](fractal.md) is a popular technique in procgen because they basi
|
|||
|
||||
A good example to think of is generating procedural [textures](texture.md). This is generally done by first generating a basis image or multiple images, e.g. with [noise](noise.md) functions such as [Perlin noise](perlin_noise.md) (it gives us a grayscale image that looks a bit like clouds). We then further process this base image(s) and combine the results in various ways, for example we may use different transformations, modulations, shaders, blending, adding color using [color ramps](color_ramp.md) etc. The whole texture is therefore described by a [graph](graph.md) in which nodes represent the operations we apply; this can literally be done visually in software like [Blender](blender.md) (see its [shader](shader.md) editor). The nice things are that we can now for example generalize the texture to 3 dimensions, i.e. not only have a flat image, but have a whole volume of a texture that can extremely easily be mapped to 3D objects simply by intersecting it with their surfaces which will yield a completely smooth texturing without any seams (this is quite often used along with [raytracing](raytracing.md)). Or we can animate a 2D texture by doing a moving cross section of 3D texture. We can also write the algorithm so that the generates texture has no seams if repeated side-by-side (by using modular "wrap-around" coordinates). We can also generate the texture at any arbitrary resolution as we have a continuous mathematical description of it; we may perform an infinite zoom into it if we want. As if that's not enough, we can also generate almost infinitely many slightly different versions of this texture by simply changing the [seed](seed.md) of [pseudorandom](pseudorandom.md) generators.
|
||||
|
||||
We use procedural generation in two ways:
|
||||
We use procedural generation mainly in two ways:
|
||||
|
||||
- **offline/explicit**: We pre-generate the data before we run the program, i.e. we let the algorithm create our art, save it to a file and then use it as we would use traditionally created art.
|
||||
- **realtime/implicit**: We generate the data on the fly and only parts of it that we currently need. For example with a procedural texture mapped onto a 3D model, we would compute the texture pixels ([texels](texel.md)) when we're actually drawing them: this has the advantage of giving an infinite resolution of the texture because no matter how close-up we view the model, we can always compute exactly the pixels we need. This would typically be implemented inside a fragment/pixel [shader](shader.md) program. This is also used in the voxel games that generate the world only in the area the player currently occupies.
|
||||
|
||||
Indeed we may also do something "in between", e.g. generate procedural assets into temporary files or RAM [caches](cache.md) at run time and depending on the situation, for example when purely realtime generation of such assets would be too slow.
|
||||
|
||||
## Example
|
||||
|
||||
TODO
|
Loading…
Add table
Add a link
Reference in a new issue