The map now assumes that the connected server at load is the same as the client host.
This needs to be changed to not assume any server at load and instead update the current server when the onInit event happens.
This was introduced by #26

• Position/Orientation: Change the camera to target the hand holding the camera instead of the player's head.
• Realtime Visor: Display & update the photo texture in realtime while the X button is pressed
• Zoom control: Adjust the camera fov with some user input

• Render the player/peer head with a textured skin.
• Store/Load the skin texture to/from the users localStorage
• Broadcast the skin texture to peers over the webrtc data channel.
• Let the user edit the texture (Spawn bust from menu + raycast painting)

For storing/restoring their nickname, skin, marked locations (for insant teleport), and other things to come.

A small node service with:

• A mongoose model to store the user data and their skin
• Email/Password registration
• A set of endpoints to generate/refresh JWTs
• A mongoose model to store user marked locations scoped per server

This centralization allows for a single account for every server.
It could also allow for a central friend list so you can teleport directly to your friend's location even if it's on another server.
All the data will just be downloaded once by the user and then streamed to the peers via the webrtc data channel just like it does now with what is stored on LocalStorage.
Also, when the servers need to validate the user for future features (like chunk claiming or something like that), they could validate this JWTs sent at connection by checking with the global auth service.

This would be built as a separate docker image: blocks-auth

The first version of the centralized auth service is deployed at:
https://blocks.gatunes.com/auth/

For now all the data is public and has cors fully enabled so it would work even from localhost.
Origin restrictions/validations may be added in the future.

I need to add this things to the client to start using it:

• Register dialog UI (This will also upload the current skin)
• Login dialog UI (This will also download and replace the current skin)
• Restore and refresh the previous stored session when loading
• Upload skin when saving it to localStorage after the user closes the skin editor

Display the location photos taken by players on a web UI scoped by:

• Latest
• User
• Server

Add a new tab to the menu with a photos UI.
If not logged in, it will propmt the user to log in. (and teach how to do photos?)
If logged in and not have any photos, it will teach you how to do photos.
if logged in and have photos, it will show a UI with:

• the photo
• a teleport button that takes you to the server/location where the current photo was taken
• prev/next buttons to navigate to other photos

This is all mostly server side in the Chunk class.

• Add tall grass block type
• Add grass geometry to the mesher (ground plane + 4-5 fibers)
• Modify world generators to spawn tall grass at the heightmap level and within altitude range.
• Double check the raycasting on the client also works for removing tall grass blocks

Repro:

1. Open Browser on the Meta Quest
2. Navigate to blocks.gatunes.com
3. Try to enter VR

The button is visible, and the debug info on the bottom left says that WebXR should be available, but clicking Enter VR does nothing.

Opening the console, there is an error message:
Uncaught (in promise) DOMException: If you see this error we have a bug. Please report this bug to chromium.

However this seems to be an anonymous error message (there's no way to view where in the code it originated) without any stack trace attached, so it seems less than helpful.

Let me know if there's anything I can do to retrieve more helpful debug information.

• Endpoint to export arbitrary world volumes into a raw format for #11 Structures
• Mesh and export to gltf (This will require decoupling/refactoring the mesher)

I assume the green round thing I've seen in the sky is the Moon, it really got me thinking before I realised what it is ! Maybe just make it grey ?

When picking a color with the A button. It should also pick the block type.

• Permalink on the auth service that serves the opengraph meta and redirects to the client
• Client support to load a location from the auth service and connect to that server at the photo location
• Web UI to display the location photo and meta on the client on top of the current world render

Once "Add UVs to mesh generator #35" is done:

• Add an optional env to the server to pass a .png texture atlas.
• Create an endpoint to download the atlas from the client
• On the client onInit load the server atlas and update the voxels material.

The servers need to be able to identify a logged-in user for future server-side features.
In order not to send the whole session token to a third party server this will require:

• An endpoint for a user to get a session token scoped by server
• An endpoint for the severs to verify a scoped session token signature
• Implement support on the servers for this auth workflow and the storage of their session token and status
• Implement fetching a scoped token and sending it while while conecting to a server on the client.

Add an option to the menu to configure the render distance.
This should also update the fog density accordingly.

Modify color picker UI to have:

• A color palette that saves the last used colors on localStorage
• A button/mode to pick colors from the world

Benchmark if using a single Uint8Array and accesing it by index is faster than the current approach of using a 3D array of objects.

To mantain the clarity of the code I would like to have a class that stores the offset with methods to access and modify the raw data directly.

The mesher has gone to far too many patches and iterations.. it needs to be rewritten/refactored.
It should pre-allocate the memory for the 9 neighbours and fetch them at once regardless.
It should also support for blocks with multiple faces.
it should end up having way less duplicity.
I should be able to fix all culling/meshing errors once its more manageable

This should have prolly been done in #38... but it looked too cool not to push it and it was alredy an 800lines patch.
I really needed to push that and start again without the distraction of all the other parts.

• Define messages protocol
• Update server & client to use the new transport

• Give proper error feedback on the camera UI when the user is not logged in.
• React properly to changes in the session

Spawn a UI plane on the player room with the controls/help at start.

• Import and store arbitrary structures
• Spawn them on the map on the propagation stage

• Master server list in github pages or something that people can PR into.
• Fetch & merge server list with the client's host and show it on a paginated menu panel (prolly as a subpage of the map UI)
• Let the client connect to another server by selecting from the server list UI

By default, it will always connect to the client host first. Then you can connect to somewhere else from the server list UI.

Once #38 is done.. The current block selection UX is not gonna cut it.
I'm thinking to display the selected block type on the left hand instead of the word "Menu" and using the left-right stick to change between block types. Have to do some testing.. but I think something like that could scale to a larger number of block types.

• Send blocktypes from servers to the clients on the INIT event.
• Move atlas loading out of voxels class into the world class so it can be also used by this UI
• Implement block selection UI in the client

Again, nice project, this is promising !
The teleportation is very nicely done.

I think it would be a good thing to let the player pick a cube type, and a tool type (eraser, brush for painting existing block.. etc.. ). Also you might want an in-game menu to look for a game server for instance, or basic game parameters like sound.

I actually made a tool for VR user interfaces, check out the examples : https://three-mesh-ui.herokuapp.com/#keyboard
It's got some cool features like MSDF text, CSS-like syntax, a virtual keyboard...
If you're interested, I'm willing to help you code the user interface using this tool. (if you take contributions)

Implement a feature that let's the users claim ownership of a set of chunks for a time period.
There should be a limit on the radius of chunks a claim can have (prolly like 4).
There should also be a limit of claims a user can do per server (prolly 3).

This requires #29 to be done first.

It will need to implement:

• server storage/loading of claimed chunks
• server-side claiming (and renewal) of a set of chunks
• server world editing should enforce chunk claims and only allow editing to the owner.
• client UI for claiming a set of chunks
• client Mesh/UI to give feedback of the readonly status of already claimed chunks

Instead of hardcoded block types. Let each server define it's own block types and textures.
This will require to rethink the meshing, the atlas packing and prolly extending the client upscaler to chunk it onto multiple textures.

This is all mostly server side in the Chunk class.

• Add tree sapling block type
• Add tree growth algorithm similar to flood lighting
• Run tree growth algorithm on the light propagation stage

Maybe rename the stage just to "propagation".
When growing a tree, it should replace the sapling block for the tree root. and start growing from there.
Trees will only be generated at the world generation stage for now.
Tree planting will be disabled since I don't have a way to render the saplings until I modify the mesher and this feature will prolly come when I implement the tall grass.
So.. Once Tall grass #6 is in, I will revisit tree planting.

• Ambient sounds preloader
• Ambient sound player/mixer. Mix ambient loops by player height.
• Allow extra channels/tracks for weather ambient (like rain)

• Create a heightmap in the client. After vertexNormals computation, get and max the height of the top faces.
• Trigger rain based on date offset (so all clients are sync) just like the daylight but less frequent
• Instance rain particles on the sky on a radius around the player, deswpawn them when they hit the heigtmap so they don't appear on interiors or caves.

• Generate UVs on the mesher
• Adapt the network protocol

Use block type as horizontal offset:

block:         glass:
1,0 - 2,0      2,0 - 3,0
1,1 - 2,1      2,1 - 3,1

This will allow the client to detect the block type by just sampling the UVs on the raycasting phase.

Display proper error feedback when a login/register fails.

This is incomplete:

I'm a fan of playing seated, and I know some people prefer it as well.
Can I suggest using the joystick for moving the camera manually ? As an option of course.
This way you can U-turn... Otherwise you're stuck in the forward direction !

On the server:

• Implement teleport request that receives X and Z and responds back with a teleport event with the world height at that block.

On the client:

• When the user taps on the map: Project the position and send a teleport request to the server.
• React to the teleport event and move the player into position

Add a fake "Enter VR" button on the bottom center of the page like they do on other threejs and webxr experiences to avoid confusion about how to enter immersive mode.

Load the nearby peers skin and draw it on the map to display their position

Two triangles. Instanced.

• Spawn birds on a radius around the player
• Animate the birds

I have many many worlds created from scans available as quantized point clouds as well as in CSV based SVOs. Any thought s on how we might create a loader for non-image type worlds?

Allow passing an absolute path to a js file to the GENERATOR server env and use that code as the world generator.
This will allow for quick and easy worldgen experimentation on the glitch servers and such.

Once #19 is done.. I want to implement the location saving/recalling with some sort of photo camera mode.

• Tapping X, the user can take a photo. This gets rendered to a texture the user can see in it's hand.
• Save and cancel buttons on top of the photo frame. If the user taps save, it uploads the photo to the auth service with the server id and the X-Y-Z location.