Had some of your previous posts on this saved in tabs; really excited to see how this is developing! I can see these maps becoming quite large; do you have a size limit currently, and how do you avoid floating point errors? Excited to see what comes next!
I’m limiting maps to around 8000x8000. Characters smaller than 1 stud start to jitter faintly but are still playable at around 4000 studs from the origin.
Here’s how object location accuracy is maintained while remaining compact:
- Because the map objects are automatically generated copies of template models, they don’t suffer from matrix creep when moving them around.
- Map object positions are stored using three 32 bit unsigned integers that specify the object’s location relative to its enclosing chunk. For comparison, parts are stored using three floats, which only have 24 bits of fraction precision that gets worse the further out you go. I can adjust the position format too depending on the format type, for example terrain triangles can use fewer bits because their position is derived from vertices.
- The custom transform tools all use double arithmetic (64 bit instead of 32 bit Vector3s) to reduce rounding errors and increase overall accuracy.
- Objects are placed into chunk octaves (2^n) based on their size, so an apple might have slightly more position precision than a building. This is negligible but still interesting.
- Object rotations (X and Y matrix vectors) are stored in 6 floats. Roblox normally stores using 9 floats, but I just get the Z vector via cross product. It’s possible to design a rotation format that can express more rotation steps using less space than this, but this is simple to implement, fast to decode, and seemed like a good compromise. Using double arithmetic during rotation transformations likely makes up for the negligible precision lost by omitting Z.
When the map converts to the server format (for publishing/testing), it takes the high precision positions/rotations and compresses them into formats more suitable for streaming. Currently most objects convert to 3 floats for position, 1 float for scale, and 6 bytes for rotation using smallest three quaternion compression. Some objects have their own special formats that replicate full chunks or other special data, like triangle terrain and axis-aligned water regions. It all replicates over remote events as packed strings using a custom streaming system.
I also have a PBR texture processing workflow that automates downsampling and exporting to 1024x1024 images. It supports .exr and 16 bit .png files, and does downsampling / color correcion using 32 bit floats before casting to 8 bit in the appropriate color space and applying dilation that compresses nicely. I had a photoshop script to do this originally but it was slow and messed up the color space; Photoshop would also take my 16 bit images [0, 65535] and convert them to [-16384, 16384] or some nonsense. It started as a C++ project but is now written in Rust.
I believe it’s really important for development tools to be precise so that the data can be downsampled for streaming and still have great quality.
11 Likes
These look really good. Can you notify me if it ever becomes a model, also is it good for performance?
3 Likes
I technically worked on this earlier today but whatever, it counts.
In my experience/game, VR users can do at least one thing that “normal” players can’t: Grabbing and dropping stuff, in both hands. It seems I haven’t shown a video of it before on the DevForums, but here’s how it looks as of today.
Before today, letting go of something made it freeze in the air before falling, probably due to network ownership switching. If you’re wondering, this is the same game that has the custom drinks and drink machine.
13 Likes
Amazing! Love the details on this.
3 Likes
I make a horror story game. But currently there was a problem.
is it the train from the film “The pollar express”
Wow, this looks realistic! Good Job!
1 Like
Lookin’ cool! Left behind is actually a book about the end times funnily enough 
3 Likes
10 Likes
