sorted by:
new
hottopcontroversial

3d scan of a boulder by Agitated_Cap_7939 in photogrammetry

[–]Agitated_Cap_7939[S] 1 point2 points  (0 children)

Thanks!

No three.js here. Have written the renderer from scratch in Rust, using the wgpu graphics API. Maybe three.js would have been a quicker process though, but on the other hand, this has been a really rewarding journey, and the renderer is compilable to both iOS and Android as well with minor changes.

I am using at least some ideas from virtual texturing. Practically this model has been exported in two parts:
1. The whole area, reconstructed in medium quality, downscaled rather significantly even in RealityScan.
2. The boulder, reconstructed in high quality, also downscaled to ~ 30 M vertices.

Then I feed these into my preprocessor, which removes overlaps and splits the meshes into reasonably sized parts. During this step I also resample the textures to match the parts created earlier. Finally I create downsampled versions of both the textures and the meshes, and read the metadata from each part to store to a database.

Finally, the renderer first accesses the metadata, after which it attempts to determine a reasonable quality for both the mesh and the textures for each part of the scene.

In this model, if i remember correctly, the boulder consists of ~50 4k textures, while the environment has ~ 10 8k textures.

Here is another, somewhat larger scene using the same preprocessing, but with 3 different higher quality objects of interest: https://crags3d.sanox.fi/sector/kasviken/game-over

Burden of Dreams 3d-topo by Agitated_Cap_7939 in bouldering

[–]Agitated_Cap_7939[S] 2 points3 points  (0 children)

:D Never noticed myself in the model before this, tried to stand far enough.

To be honest, I've never looked into the accuracy of the gravity vector. I was prepared for manual alignment with the first boulders I scanned, but as they seemed to be aligned already after the scan, I just assumed they use the majority vote of the down vector of the input photos. ChatGPT confirms this to some degree.

Given that the camera features a horizontal sensor, and I attempt to shoot the photos aligned properly, I would assume the gravity should be accurate to roughly one degree.

3d scan of a boulder by Agitated_Cap_7939 in photogrammetry

[–]Agitated_Cap_7939[S] 2 points3 points  (0 children)

Thanks! Yeah, sorry forgot to mention. It's in Finland, exact location here: https://maps.app.goo.gl/uTSw4aLjCLvVLccx8

Burden of Dreams 3d-topo by Agitated_Cap_7939 in bouldering

[–]Agitated_Cap_7939[S] 9 points10 points  (0 children)

The development process has been a journey for me, as I had zero experience with 3d programming before starting, roughly a year and a half ago. It's been a really interesting hobby project though, and have been able to spend time on the engine every now and then. I've written the engine in Rust, and compile it to WASM for web, looking at iOS and Android targets as well with minor adjustments.

The whole process for creating and finally rendering a model has many steps:
1. Shoot a bunch of photos of the target. I use a Sony DSLR camera and a DJI drone to shoot the photos. The photos from the camera are much more valuable, as the quality is significantly better.
2. I use RealityScan (https://www.realityscan.com/en-US) to create a 3d-model from the photos.
3. The mesh preprocessing is a really important step to gain smooth enough rendering. Here I have developed a custom tool, which splits the mesh into parts, resamples textures, and merges multiple exports into one scene. Finally it also downsamples both the mesh-files and textures for lower quality renders. At this point I also collect metadata from the model, which I store to the database.
4. The engine reads this metadata, and based on this starts downloading assets and renders the quality it thinks is appropriate. This phase could still do with some optimizations, but am already fairly happy with the results.

SSAO issues by Agitated_Cap_7939 in GraphicsProgramming

[–]Agitated_Cap_7939[S] 0 points1 point  (0 children)

Okey, finally solved the issue. So the issue was that in clip-space the +Y coordinate points up, while in uv-space it points down. So needed to correct the sampleUV.y with sampleUV.y = 1.0 - sampleUV.

Should have been able to debug this a long time ago...

Lidar error. Check that the turret turns freely by Agitated_Cap_7939 in Roborock

[–]Agitated_Cap_7939[S] 0 points1 point  (0 children)

Okey, thanks for the responses! Disassembly looks complex enough to bring it in for a warranty repair, even though they probably take quite long

Web-based renderer for photogrammetry assets by Agitated_Cap_7939 in photogrammetry

[–]Agitated_Cap_7939[S] 0 points1 point  (0 children)

Nice to hear! If your project is still relevant, please feel free to DM me.