The main selling point of Gaussian Splatting over NeRF-based methods is rendering (and training) speed and efficiency.
This does come at the cost of physical correctness as it uses splatting instead of a real radiance field.
This method tries to move back to radiance fields, but with a primitive-based representation instead of neural nets.
Rendering performance seems to be quite poor (30fps on a 4090), and rendering quality improvements seem to be marginal.
I'm not quite sure I understand where this fits in when NeRFs and 3DGS already exist at the opposite ends of the correctness-speed tradeoff spectrum.
Maybe somewhere in the middle?
I’m using Zed on macOS and like it so far. Only thing I wish they add is remote development like VSCode has. Zed seems to be focusing on collaborative development and the integrated AI assistant, but feels like remote programming is something closer to a lot more people’s use cases. I’d be willing to pay for a seamless remote experience with Zed.
It's mostly an ecosystem thing, being unable to use existing methods.
In my experience, research goes something like
1. Milestone paper introducing novel method is published with green-field implementation
2. Bunch of papers extend milestone paper with brown-field implementation
3. Goto 1
Most things in 1 are written in PyTorch, meaning 2 also has to be in PyTorch.
I know this isn't JAX's fault, but I don't think JAX's philosophy to stay unopinionated and low-level is helping. Seems like the community agreeing on a single set of DL libraries around JAX will help it gain some momentum.
I like JAX, and find most of the core functionality as an "accelerated NumPy" great.
Ecosystem fragmentation and difficulties in interop make adopting JAX hard though.
There's too much fragmentation within the JAX NN library space, which penzai isn't helping with. I wish everyone using JAX could agree on a single set of libraries for NN, optimization, and data loading.
PyTorch code can't be called, meaning a lot of reimplementation in JAX is needed when extending and iterating on prior works, which is the case for most of research. Custom CUDA kernels are a bit fiddly too, I haven't been able to bring Gaussian Splatting to JAX yet.
I've recently started using fountain pens, the Pilot Capless (Vanishing Point) Decimo with Pilot Iroshizuku Shin-kai ink in particular. The Decimo is retractable, making it great for everyday use. My paper of choice is Rhodia R 90gsm.
It's refreshing to write with something as tactile and manual as a fountain pen when I'm surrounded by screens all day.
I find that taking notes on paper helps me with programming (debugging, code structure, etc.), and the writing experience of a fountain pen encourages me to take more notes.
CPP needs to run after lexing, and integer constant expressions need to be parsed and interpreted for #if.
So I'm trying to implement my own since I'm already doing lexing/parsing/interpreting.
Implementing everything end-to-end also seems like the only way to output decent error messages.
I've been working on a C compiler with the goal of ANSI C compliance, and most of the projects described as a "C compiler" seem to only support an arbitrary subset of C. This project seems to support more than most educational/toy CCs, but I still believe there’s value in implementing full standard C.
I’m stuck with PVS-7s and 14s. The nerd part of me is amazed looking at the stars with them, but the soldier part of me is frustrated having to move with them. I can’t imagine having I^2 and thermal imaging in a single NOD.
Korean versions of the article have more details. He was from a robot maintenance company visiting the factory to perform a software update. He was working on the robot alone and checking the sensors when the incident happened.
I wrote a short blog post[1] on this method a while ago. I do think running WASM in embedded runtimes is a pretty good option, but overhead remains high, and WASI remains somewhat fragmented between compilers and runtimes.
I think this method really shines in Go as not having CGo simplifies a lot of things, and as a decently performant JITed runtime exists in the form of wazero.
Mine’s a bit different from the actual one as I had to reverse engineer the animation. It’s more complex to implement than I imagined, it’s hard to get the motions to feel “right”. I used a logistic function where the inflection point is at the middle of the screen to calculate the amount of translation/rotation.
I’d love to see a breakdown of the actual animations used.
I’ve tried out some work on generating vector fonts too, in the format of Bezier curves and a seq2seq model. The problem was that fonts outputted by ML models were imprecise. Lines were not perfectly parallel, corners were at 89°, and curves were kinked. It’s not too difficult to get fonts that look good enough, but the imperfections are glaring as fonts are normally perfectly precise. These imperfections are evident in OP’s output too, and in my opinion make these types of models unusable for actual typesetting.
A 1% error in a raster output would be pixel colors being slightly off, but a 89° corner in a vector image is immediately noticeable, making this a hard problem to solve. I haven’t looked into this problem too much since, but I’m interested to hear about possible solutions and reading material.
Using WASM for things requiring low IO and high compute that are traditionally written in C/C++ makes a lot of sense to me. Image codecs are an example and native implementations for things like JPEG encoders are hard to come by. So, I used wazero to implement a few image codecs in Go^1. Codecs were compiled to WASM, and wazero works great for running them (albeit with overhead).
For this use case, wazero appears to be the cleanest solution as it's the only runtime that doesn't need CGo. The biggest appeal to me embedding WASM in Go is avoiding CGo to allow cross compilation. If my dependency is using CGo anyway, I might as well as link against a C library. I think native WASM runtimes like wazero are currently the best options for porting code language-agnostically.
Since this is an npmjs problem, I wonder if a CAPTCHA requiring the uploader to solve a JS programming problem could work. Something hard for spammers to solve just by googling – writing a function, filling in blank code, etc.
This would require the uploader to have at least basic (or intermediate, depending on the difficulty) knowledge in JS. Maybe the generated data could be used to fine tune LLMs.
This method tries to move back to radiance fields, but with a primitive-based representation instead of neural nets. Rendering performance seems to be quite poor (30fps on a 4090), and rendering quality improvements seem to be marginal.
I'm not quite sure I understand where this fits in when NeRFs and 3DGS already exist at the opposite ends of the correctness-speed tradeoff spectrum. Maybe somewhere in the middle?