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?
Primitive-based representations are a lot easier to manipulate (e.g. animate) than NeRFs. Also they can be a lot more efficient/scalable when there's a lot of e.g. empty space.
I think they're suggesting that their method is still faster than most NeRF based methods? They have slightly worse image quality compared to ZipNeRF while getting 72x the frame rate. Or perhaps I'm misunderstanding...
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.
those give you access to modify remote files - vscode gives you remote search, debugging, building, testing, port forwarding, reproducable self-contained disposable environments, ...
Having used both sshfs and vscode-remote for many years, I can assure you that vscode has a lot more features, with better integration; and even the features that sshfs does have, vscode-remote does the same thing better :)
(You can kiiiind of get the same features with sshfs + mosh + ssh + docker + a bunch of custom scripts + a suite of not-integrated command line tools... but that’s very much a “Why would anybody want to use dropbox when we already have rsync?” situation)
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'm curious what interop difficulties you've run into in JAX? In my experience, the JAX ecosystem is quite modular and most JAX libraries work pretty well together. Penzai's core visualization tooling should work for most JAX NN libraries out of the box, and Penzai's neural net components are compatible with existing JAX optimization libraries (like Optax) and data loaders (like tfds/seqio or grain).
(Interop with PyTorch seems more difficult, of course!)
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.
That's my experience as well. PyTorch dominates the ecosystem.
Which is a shame, because JAX's approach is superior.[a]
---
[a] In my experience, anytime I've have to do anything in PyTorch that isn't well supported out-of-the-box, I've quickly found myself tinkering with Triton, which usually becomes... very frustrating. Meanwhile, JAX offers decent parallelization of anything I write in plain Python, plus really nice primitives like jax.lax.while_loop, jax.lax.associative_scan, jax.lax.select, etc. And yet, I keep using PyTorch... because of the ecosystem.
Another issue I've personally faced is debugging - although I am saying this from my experience from more than a yr ago, and maybe things are better now. I have used it mostly for optimization and the error messages aren't helpful.
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.
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 am a faculty member at a university, and the main reason I initiated this project was to create a practical learning environment for my students. I have noticed that many tools labeled as 'C compilers' only partially implement the C language, which has been a source of frustration for me. My goal is to demonstrate how to build a basic C compiler and enhance it to include some key features of the C99 standard, as well as optimization strategies commonly found in contemporary optimizing compilers. Despite its modest size, this project is robust and capable of self-hosting, meaning that students have the opportunity to develop an optimizing compiler that can compile its own code, progressively refining it for improved instruction per cycle (IPC) and better code density. Unable to find an existing one that met these expectations, I wrote a new one with my students.
To me, a useful cutoff would be to define "C compiler" as anything that can compile TCC (the tiny c compiler, that can more-or-less compile the old C versions of GCC).
Maybe it's legitimate to say "TCC must be a single-file amalgam first and you have to use an external preprocessor".
What're you thinking of doing with the preprocessor? Accept the complexity and build that too, run a pre-existing one, implement a subset of it, other...
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.
The C preprocessor is hilariously underspecified in the standard, so implementing the standard doesn't guarantee that you'll be able to handle real-world C programs (even ones that don't use GNU or clang extensions).
K&R preprocessor was indeed underspecified and allowed lots of variations---much of those issues can be seen in the GCC manual [1]---, but the current ISO C is much better at that job AFAIK. I think `## __VA_ARGS__` is the only popular preprocessor extension [2] at this moment, as the standard replacement (`__VA_OPT__`) is still very new.
Yes, consider the case of shecc. It requires just a handful of C code lines to interpret directives set in the C preprocessor. Unlike relying on existing tools like cpp, as, or ld, shecc stands alone as a minimalist cross-compiler. This design could be particularly beneficial for students delving into the study of compiler construction. See https://github.com/sysprog21/shecc/blob/master/src/lexer.c#L...
I largely meant a standard-complaint implementation though, which shecc doesn't claim to be. ;-) In comparison I can easily see that this lexer is not suitable for preprocessor because C requires a superset of numeral tokens [1] during the preprocessing phase.
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.
Hmm, that would suggest that he both had better training about the robots (compared to a random food-packing-plant worker) but was also more comfortable around them (which is a huge risk with any powerful equipment, including automobiles.)
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.
That's a very nice implementation, not even janky on my old Mac. Great.
I recently found out that the web is in the process of getting Scroll-Driven-Animations, which enabled a CSS-only CoverFlow, among other things. Here is an example:
Seeing Mezzanine then flipping through I thought somehow it’s reading my actual music library on my phone and was both impressed and worried at once. Good job.
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?