GitXplorerGitXplorer
b

chinoxel

public
1 stars
1 forks
0 issues

Commits

List of commits on branch main.
Unverified
05e34d97992e08300d50363e19f90365634eb5eb

WIP, corrections are still off

bblefaudeux committed 3 years ago
Unverified
903060eb31432c430fda6efd2e878bd6fa4312e5

grid field clamping, some better formulations, grads still in need for some corrections

bblefaudeux committed 3 years ago
Unverified
54e4f8797dd8f2cec94de08cde6bb153f14fca5a

grad formulas are probably a bit broken still, opacity is plain wrong, but this is learning :)

bblefaudeux committed 3 years ago
Unverified
5e06246696587f99136132e21026c6ac83506e4d

some improvement on the grad descent, still looking a bit nuts

bblefaudeux committed 3 years ago
Unverified
be828f7bc787af8288860d6c2ac2bbe288245ceb

rewrite the UI for the optim, random corrections to check the affected areas

bblefaudeux committed 3 years ago
Unverified
d5f07b68905a741a14cebe481004e80107c3d7b7

walk back the grad logs, apply dummy corrections

bblefaudeux committed 3 years ago

README

The README file for this repository.

chinoxel

Trying to implement Plenoxels using Taichi. Reimplementing from scratch as a comprehension exercise, not looking at the original code. First project with Taichi so a lot of parts may not be very idiomatic..

TODOs:

  • [x] General framework (grid/render/compare with views/optimize)

  • [x] Handle camera extrinsics

  • [x] Interpolate node contributions

  • [x] Color buffers

  • [x] Propagate rays over depth

  • [ ] Manual backward pass implementation (store gradients). Taichi's autodiff dies on the color interpolation scheme, and on the interestection, which is sparse by nature. May be a better idea to compute the gradients by hand, and store them in a dedicated buffer as the rendering is being done. One possible issue is that the same node can contribute to multiple pixels. Their gradient would differ, and would then need to be traced back to the right node contribution. A naive take is to consider [pixels]x[nodes] gradients, but this would be very sparse and waste tons of memory. Maybe that per-node gradient storage (per pixel) is the better take, at most 4 pixels would be stored there.

  • [ ] Add some unit tests

  • [ ] Handle spherical harmonics in the nodes (or just move to spheres altogether)

  • [ ] General speedup (sparsity for instance)