madblade / spix Goto Github PK

(To whomever it matters to)

Possible future milestones:

• Add user-controlled graphical settings (mouse sensitivity, water reflection, shadow maps, etc.)

• Add help menu

• Locale detection

• Raycast helper (wireframe box showing to indicate the user where a block addition would occur)

• Put the camera closer to the head, and perform a reversed-raycast to adjust the camera position (prevent the camera from going inside the terrain geometry). Perf: only raycast on the closest 4 chunks.

• Camera lock / camera switch target (important for ease of use on mobile devices)

• Chat (prototypes in client/app/modules/chat)

• Console to send commands to the server

• Wire in and expose random seed / flymode / op state

• Sun position synchronization

• Node.js CLI commands(?) (really not a priority)

• WebAudio module (prototypes in client/engine/audio)

• Inventory and crafting system(?) Not entirely sure where this would belong. Probably in modules. This should be done together with entity life/death depending on user needs.

(To me)

Write to a folder / read from a folder:

• list of modified chunks
• list of entities with positions and states
• (later) world seed, inventory
  One folder per world, inside a game folder. (?)

Also interesting:

• save disconnected users with states
• reconnection mechanism

Portals

Two different portal guns should be available:
One that opens a window that is automatically linked to another world (implemented).
One that links two portal ends (p1p2) on-demand (like in Valve’s game, not yet implemented).

Needed to make the system robust and usable

A rendering system that solves some level of portal recursion, and also that uses stencil masks for performance, is already available, but the following bricks are still missing.
These are somewhat long-term bricks:

• two portals linking in the same scene/world

• on-demand portals (p1p2)

• portal camera rotation, when p1’s rotation differs form p2’s

• compute the chain transformation for recursive rendering: position (trivial) + rotation (less trivial)

• compatibility with scene shadows (this will be tough to get working)

Needed first

These are the more "pressing" issues:

• Performance: (This is a bug!) combining self-model interpolation + world switch. The self-model position is updated every server tick, and smoothly interpolated client-wise. But when a world-switch update is received client-wise, the world switch happens at the next render (so no interpolation takes place, and there will be a small jump!) The client should instead continue interpolating, for a few frames (~48ms), until the portal collision is detected client-wise and the scene switch can take place, at the exact right frame.

Therefore we need client-wise portal collision detection (just copy the code from the server), and to check for portal collision in the interpolation routine, when a flag needsToSwitchScene is set.

• Performance: pre-allocate scenes, render target and composers to avoid lag when crossing a portal for the first time.

• Make a portal helper (with the raycaster on close chunks).

Some enhancements I’d like to test out:

• rectarealight next to portals (compute the sun intensity delta)

• god rays

• a system to adjust the bloom level / radius object-wise

• trails / afterimages

Shadow volume

Shadow volume is a shadow rendering technique proposed by F. Crow in 1977. It makes use of the stencil and depth buffers to perform boolean operations on the extruded silhouette of a given mesh, and extracts shadows with little rendering effort.

Depth (z-) pass

The advantage of the z-pass approach is that it does not need back or front caps. It is, however, unsuitable as it does not handle properly the case where the camera dwells inside a shadow volume (it then inverts the shadows).

Depth (z-) fail

The z-fail approach proposed by Bilodeau, Songy and Carmack is more suitable as it correctly handles such cases (although it still yields a very crisp sort of shadow).

Issue

The problem with the z-fail approach is that it needs front- and back- caps for the volume mesh, which are not trivial to extract. This is the part that is missing here.

Code

(This is an experimental feature!)

In client/app/engine/graphics/render/renderer.js, shadow volumes may be turned on by setting the flag this.shadowVolumes = true;. (Note: it is only visible when the sun is sufficiently high.)

The mesh that needs its shadow volume computed is the terrain mesh. It is in the form of a strip of faces (2 tris each) which are (xz), (yz) or (xy)-aligned, and of edge length 1 (and sqrt(2) for the diagonal).

In client/app/engine/graphics/terrain/shadow.js, the getDynamicShadowVolumeGeometry function generates an incomplete shadow volume. It is (almost) real-time for the default Perlin-generated strip of faces, so performance should be kept almost-real time. It simply clones the original strip and closes non-diagonal edges with a quad; the back-facing side of this mesh is later projected with a vertex shader (graphics/shaders/shadow) to produce the final shadow volume.

So the mesh has front caps but it needs back caps.
At the end of this getDynamicShadowVolumeGeometry function, the edgeHash map has all the boundary edges.
Proposal: for each boundary edge (v1v2), add two vertices v3 and v4, with normals facing downward, and form a quad (v1v2v3v4). Then the vertex shader should project (v3v4) to infinity and emulate a back cap.

Other enhancements

Fine-tune the vertex shader to reduce possible precision artifacts (blinking faces) due to the volume shadow front-cap overlapping with the actual terrain geometry.

Voronoi-based map generation

M. O'Leary proposed an interesting take on generating fantasy maps. This approach is based on voronoi diagrams. (See his repo for more information).

The code in engine_generaton/terrain does the same as O'Leary’s approach, but then renders it into a raster that is used to query chunk height in the voxel model, in a streaming fashion. Tiles are computed progessively (see my other repo).

Enhance gerenation

• Use the voronoi model to generate tiles and city walls in engine_generaton/terrain/tile. It should be rendered to the surface buffer (not the height! height is used for chunk voxel heights). Work this out in tile/biomes and tile/cities.

• Properly rasterize rivers tile/pixel, (and compute river water levels in chunks, the part that translates the height and surface buffers into actual blocks is located in engine_consistency/generator/generator_fantasy).

• A tileable noise pass can be fine-tuned to add local, higher-frequency hills. See tile/noise.

Proposal: generate villages / cities, biomes and forests!

Performance bottlenecks

The whole approach is not real-time so it was made progressive.

The voronoi generation is a bottleneck, but it can be generated just once, when the server starts (this is what is done).

The erosion pass is the other main bottleneck. It uses Planchon and Darboux’s algorithm for filling sinks, but could be made faster with one or two iterations of Tierny and Pascucci’s algorithm. This involves a BFS which is not real-time either, but could complete faster.

Proposal: make the topological pass in engine_generation/terrain/tile/erosion progressive and use it as a default approach.

(To myself)

• IO compression: SZ-like algorithm where I send the first face + the face delta index. Or make it into a byte format: log2(3 * 32^3) * 32^2 + 8 * 32^2 bits

• IO bundle: bundle events, don’t call socket.emit(x) more than once a frame per client.

• Allocate Amandites-Woo nets per entity: don’t reallocate at every terrain pass. Refactor the hitbox model.

• Reload chunks: add a client command to clear its consisitency model.

• Remove jQuery

• Don’t send empty chunk flags (do I? check)

Some features that would be nice to have:

• 3D pathfinding (progressive a* or annealing-based)

• Arrow trajectories (Magnus-like effect!

• Entity collaboration (adding blocks, protecting other entities, teaming up)

• Entity communication (using the O'Leary language generator)